Kolisionsprogramm funktioniert nicht

[asuro_freak2]

Hi ich habe ein Programm geschrieben, dass wenn der ASURO mit einem Gegenstand kolidiert den ASURO ablenkt, allerdings funktioniert es nicht, der ASURO bleibt an Wänden hängen oder lenkt ab obwohl keine Kolision stattgefunden hat. Ich vermute das die Versorgungsspannung abfällt wenn der Motor gestartet wird. Daher habe ich mit einem TI-Voyage und eine Messinterface von Vernier an dem betreffenden Pin eine Messung durchgeführt. Das Ergebniss war eine relativ hohe Wechselspannung, die tatsächlich abviel wenn der Motor gestartet wurde. Leider funktioniert das speicher nicht und ich hatte das link-kabel auch nicht dabei(wir haben eine Robotik AG)
Hier der Quellcode


/*
d
################################################## #################
#-----------------------------------------------------------------#
# Sinnlos durch die Gegend #
#-----------------------------------------------------------------#
################################################## #################
Funktion : lässt den ASURO durch die gegend fahren wenn die taster eine kollision melden lenkt er ab
*/

#include "asuro.h"
/*################################################# ####################################
Funktionen*/
void sleep_s(int sek)//Erweiterung die sleep mit sekundenangabe ermöglicht
{
int n;
int t;
t=sek*250;
n=0;
while(n<t)
{
Sleep(76);
n++;
}
}

void schalter_akt(void) //ließt die schalter aus um den kondensator zu entladen
{
int zaehler ;
while (zaehler<5)
{PollSwitch();zaehler++;}
}


//################################################## ####################################
int main(void)
{
char taste;

Init();
MotorDir(FWD,FWD);
MotorSpeed(200,200);

/* ASURO soll vorwäts fahren
################################################## ######################################*/
while(1)
{ schalter_akt();
taste=PollSwitch();

switch(taste)
{
case(2)
:StatusLED(RED);
MotorSpeed(200,125);
sleep_s(1);
/*Wenn der der Taster neben dem Stromschalter gedrückt wird ablenken */
MotorSpeed(200,200);
StatusLED(GREEN);
break;
/*################################################# ######################################*/
case (4||8||10)
:
MotorDir(RWD,RWD);
StatusLED(YELLOW);
sleep_s(1);
MotorDir(FWD,BREAK);
StatusLED(GREEN);
sleep_s(1);
MotorDir(FWD,FWD);
//wenn die taster in der mitte bedinnt werden zurück und drehen
break;
/*################################################# ######################################*/
case (16)
:
MotorSpeed(125,200);
StatusLED(RED);
sleep_s(1);
StatusLED(GREEN);
/*Wenn der der Taster neben dem Stromschalter gedrückt wird ablenken */
MotorSpeed(200,20 0);
break;
default
:
BackLED(ON,ON);
break;
//################################################## #############################################
//ende switch
}
//ende fkt.block endlos schleife
}

//ende main
}

[damaltor]

ich glaube das problem ist die case-fallunterscheidung:

|| ist ein bitweises oder. also:

4||8||10 (warum eigentlich 10? es gibt keinen schalter der den wert 10 hat)
=
00000100||00001000||00001010
=
00001110 also 14. es wird also geprüft ob pollswitch gleich 14 ist.

leute bitte korrigiert mich wenn ich falsch liege, ansonsten ist das normale oder ein einzelnes |

[DGS]

Verbesserungsvorschläge:

1:
taste=PollSwitch() & PollSwitch();
Also zweimal auslesen. Verringert fehldiagnose.

2:
An Motoren zusätzliche Kondensatoren anlöten, um Schwankung zu verringern.

3:
Motoren vom Stromkreis trennen.

Oder hier nachlesen:
https://www.roboternetz.de/phpBB2/viewtopic.php?t=29263

@ damaltor
Was du meinst ist ein einfaches |
Im Fall case(4||8||10) wird wohl gefragt:
if (taster==4 || taster==8 || taster==10 )
Also ein Operator auf boolean.

[damaltor]

na gut dann hab ich mich getäuscht. allerdings sollte evtl wirklich so wie du geschrieben hast, mit einzelnen if abfragen geprüft werden.

mehrere abfragen sind bereits in verwendung durch die abfrage von schalter_akt()

[DGS]

Die if-abfrage ist ja bei ihm durch den switch implementiert.

Und meine gepostete IF-Abfrage ist das, was ich von dem swicth vermute, was der macht/ wie der übersetzt wird vom Compiler.

[damaltor]

hmm... und wenn man dann drei cases macht? also nur um die || zu sparen?

[DGS]

Dann hat man mehr Queltext.
Wenn der Compiler nicht selbst erkennt, dass es sich um redundaten Quelcode handelt, wird auch die resultierende HEX Datei größer.
Mit 7kb Speicherbegrenzung sollte man da schon auf die schlanke Figur achten und sich angewöhnen überflüssige Zeilen zu sparen wenn es geht.

Alternative wäre den redunaten Code in eine Hilfsfunktion auszulagern und die dann aufrufen.

[damaltor]

naja... ich meine ja nur um es zum funktionieren zu bringen. und das programm benötigt nicht die 7 kb. also an sich klar muss der code klein bleiben, aber wenns nicht geht is es doch einen versuch wert...

[DGS]

Ich bleib bei der Vermutung, dass das case richtig interpretiert wird. Könnte man natürlich mit nem kleinem C-Programm überprüfen.

Glaub eher, dass der Fehler entweder bei der von dir angesprochenen 10 zu suchen ist. Eine 12 ( 4+8 ) würde mehr Sinn ergeben. Oder es liegt an den Störreffekten der Motoren. Dazu hab ich ja schon entsprechendes Topic verlinkt.

[damaltor]

naja 10 ist 8+2. ich denke eher dass mit16 der nächste taster gemeint ist

[DGS]

2 und 16 sind die Taster, die nach vorne zeigen.
4 und 8 sind die Taster, die jeweils nach innen zeigen.

Ich bleib bei der Vermutung, dass er die inneren Zusammengefasst hat.
Und die 10 macht wirklich nicht viel Sinn. rechts vorne, links innen? Macht wirklich keinen Sinn.

Und die 16 wirds auch nicht sein, zu einem weil sie nicht dazu passt zu den inneren, zum anderen hat er eh einen case(16) drin.

Hier könnte also das Problem mit "an Wand hängen bleiben" liegen.
Er liest nur Sensoren, die nach vorne oder innen gerichtet sind.

Also richtig wäre dann:


case(1)
...
case(2 || 16 || 18)
...
case(32)
...

Also 1 und 32 sind die Seitensensoren. Bei 2, 16 und 18 erkennt der ASURO dann einen Frontalaufprall. Also so würde die Belegung Sinn machen, wenn man die Kommentare durchliest.