|
 |
 |
 |
|
|
c't Projekte - c't-Bot und c't-Sim -
Mailinglisten
[Voriger (Datum)]
[Nächster (Datum)]
[Voriger (Thread)]
[Nächster (Thread)]
[Nach Datum][Nach Thread]
Absender: Timo Sandmann
Datum: So, 30.09.2007 19:30:07
In-reply-to:
<46FFC71F.4040600@xxxxxx>
References:
<46FA1ECB.4080301@xxxxxx> <B2A39AC5-0658-4706-983A-6F5DE8A47D60@xxxxxxxxxxxxxxx> <46FAC95D.8020704@xxxxxx> <DDBCDC14-8D0B-400D-AA79-623891355654@xxxxxxxxxxxxxxx> <46FC49CE.2060404@xxxxxx> <EE104263-B9AC-4F3C-AC39-947AE9E85CBA@xxxxxxxxxxxxxxx> <46FFC71F.4040600@xxxxxx>
Hallo,
Am 30.09.2007 um 17:56 schrieb Achim Pankalla:
vielleicht müsste die hw verändert werde (der spannungsteiler), um
den Spannungswert zu erhöhen, ab dem der akku als leer gilt, sprich
das error-bit gelöscht wird. das könnte die warnzeit erhöhen!?
ja das stimmt, die Widerstände müsste man auf jeden Fall ändern.
meine routine könnte noch verändert werden, so das sie beim ersten
gelöschten error-bit schon akku leer anzeigt. die vorwarnzeit
ändert das aber kaum.
allerdings bin ich nicht der meinung das das ganze nichts bringt,
besser spät gewarnt als gar nicht, wenn man es den auswerten
möchte. von der hw ist eben nicht mehr drin. aus irgendeinen grund
wurde diese schaltung ja eingebaut und wenn das ganze eh sinnlos
ist, kann man sich das auswerten des bits in der isr-routine der
sensoren ja sparen, denn dort zählt jeder befehl (taktzyklus), um
sie schneller zu machen oder?
Da habe ich mich wohl etwas missverständlich ausgedrückt. Ich meinte
nicht, dass die Fehlererkennung an sich sinnlos sei, sondern dass sie
so, wie sie derzeit (hard- und softwareseitig) realisiert ist, meiner
Meinung nach nicht viel bringt.
Ich denke, man müsste da als erstes mal die Hardware entsprechend
modifizieren, so dass der Eingang genau dann auf LOW geht, wenn
entweder der Servo blockiert und zu viel Strom zieht oder die
Akkuspannung so niedrig ist, dass der Bot beispielsweise nur noch 10
Minuten stabil arbeiten kann.
Anschließend sollte das Bit natürlich auch entsprechend ausgewertet
werden, wobei ich aber der Meinung bin, dass sich aus dem Bit nur
schließen lässt, dass entweder der Servo blockiert oder die Akkus ab
jetzt aufgeladen werden müssen.
Das Auswerten des Error-Eingangs kostet ganze 6 Taktzyklen, die
komplette Routine braucht (einfach mal grob geschätzt) so 15.000
Takte (für den Fall, dass nicht auch noch gerade die
Geschwindigkeitsberechnungen aus den Mausdaten erfolgen), die ~ 0,04
% für's Errorbit-Auswerten sind da ziemlich egal.
alternativ könnte das abfragen des bits über ein behaviour erfolgen
und wer es brauchen kann schaltet es ein. im devel zweig wird der
wert sowieso bisher nur für die anzeige der sensordaten genutzt.
Das Auswerten an sich würde ich nicht als Verhalten machen. Man
könnte aber eine Art Notfallverhalten implementieren, das im Fall von
leeren Akkus die aktuelle Position sichert, alle anderen Verhalten
anhält, zur Ladestation fährt, nach Abschluss des Ladevorgangs den
Bot wieder an die alte Position zurückbringt und die damals aktiven
Verhalten reanimiert. Das ist zwar ein bisschen aufwendig, muss aber
ja auch nicht sofort fertig und perfekt sein. ;-)
Ob die Auswertung im Servo-Bockiert-Fall wirklich Sinn macht, ist
aber auch fraglich, denn nach spätestens einer Sekunde wird der Servo
vom Verhalten sowieso abgeschaltet. Eine entsprechende Auswertung
könnte man allerdings benutzen, um zu überprüfen, ob das Fach auch
wirklich komplett aufging (also kein Servofehler passierte), so dass
catch_pillar() nicht die Dose umfährt. Vorausgesetzt man kann genau
genug zwischen Servo blockiert oder nicht blockiert unterscheiden.
So oder so braucht man IMHO aber erstmal saubere Sensordaten.
Gruß Timo
|
|
|