heise online · c't · iX · Technology Review · Telepolis · mobil · Security · Netze · heise open · heise resale · Autos · c't-TV · Jobs · Kiosk
Zum Inhalt
c't

c't Projekte - c't-Bot und c't-Sim - Mailinglisten

c't-Bot und c't-Sim


[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

Re: [ct-bot]: Auswertung ERROR Flag

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



Copyright © 2007 Heise Zeitschriften Verlag Kritik, Anregungen bitte an c't-WWW Datenschutzhinweis   Impressum