Hardwarefehler? / Softwarefehler?

[Patrick P.]

Hallo Ft- Freunde,

ich habe ein Problem mit einem Roboter, den ich bis zum 15.03.11 für Jugend forscht fertig haben muss.
Bei diesem Roboter handelt es sich um ein insektenähnliches Gerät, das auf sechs Beinen läuft (oder oder es zumindest sollte ).

Für den Roboter habe ich drei TX- Controller per Breitbandkabel miteinander verbunden, da ich insgesamt zwölf Motoren und 24 Tastsensoren daran anschließen musste.

Mein Problem ist nun das, dass ich ein Programm geschrieben habe, das eigentlich funktionieren sollte - jedoch passiert bei jedem Start des Programms etwas anderes, was, wie ich denke, an der Hardware liegen müsste.
Oft reagiert das Programm/ der TX- Controller auch einfach nicht auf die Tastbefehle. --> Stoppe Motor, sobald Taster berührt wird.

Ich habe auch schon mit einem ganz einfachen Programm versucht, alle Motoren anzusteuern, aber dabei hat der mittlere TX- Controller (Ext.1) nicht mitgemacht. (Aufbau: vorne Master, Mitte Ext. 1, hinten Ext. 2)
Daraufhin habe ich den Versuch gemacht, den mittleren TX- Controller zum Master zu machen un das Programm von dort aus zu steuern. Ergebnis: eine entweder/oder- Schaltung. Entweder der hintere TXC wurde angesteuert, oder, wenn man das Kabel des hinteren TXCs entfernt hat, der vordere TXC.

Bei meinem ersten Programmversuch habe ich zu viele Prozesse gleichzeitig laufen lassen (20 Stück), die ich aber mittlerweile auch schon auf acht verkleinert habe.

Es wäre echt super, wenn mal jemand über das Programm schauen könnte und mir Rückmeldung geben könnte, ob es kein Fehler im Programm ist.
Wichtig ist jedoch, dass die Beine sozusagen alleine "denken" und nur den Befehl zum nächsten Schritt weitergeben.

Das Programm sollte demnächst auf der Seite http://www.ftcommunity.de/downloads.php ... ie=RoboPro unter dem Namen Insektensteuerung von Patrick P. freigeschaltet werden.

Vielen Dank im Voraus

Patrick P.

[han]

Hi Patrick,

Always curious to see what can be done with RoboPro I have looked at your program. I think it contains the following sources of errors:

1. After initializing (Initialisierung) the six processes L1-R3 will continue immediately with the six subprograms L1-R3. These subprograms begin all with the subprogram Anfangsstellung. You can see that as if six copies (or instances) of this subprogram run at (about) the same time. They are however sending commands to the same output (M2 and M4-em1) and reading from the same inputs (I2 and I4-em1). The motors will get confused receiving so many commands.

2. The six subprograms L1-R3 read from and write to the same global variable Schritt. I think you mean a local variable.

3. In the beginning you test for Schritt=2. When it becomes 2?

4. Look also at the global variable Fertig. If it would work this way (which is doubtfull), it works only once. After a second loop it will become 12, after a third 18 and so on.

Well, it seems a difficult task to program.So be patient and go on! I hope these remarks will help you.

Good luck, Han.

[Patrick P.]

Hi Han,

thank you for answering so fast. I hope, you'll understand, if I write in German again (my English is not so good ).

1. Ich habe das Unterprogramm "Anfangsstellung" auf deinen Rat hin so eingebaut, dass es nur einmal geladen wird. Etwas besser klappt das Programm jetzt schon, aber noch nicht 100%-ig

2. Die Variable "Schritt" muss global sein, weil sie in allen Unterprogrammen außer "Initialisierung" benötigt wird.

3. Dabei ist mir ein kleiner Fehler unterlaufen..ich habe schon ein geändertes Programm, bei dem die Abfragen lauten:

L1: 0
L2: 2
L3: 4
R1: 4
R2: 0
R3: 2

Pro Schritt wird die Variable "Schritt" von jedem der sechs Beine nach Beendigung der Bewegung um 1 erhöht. Dadurch wird die Schrittart festgelegt (in diesem Fall "Tetrapod"-Gangart: vier Beine bleiben auf dem Boden, zwei werden bewegt).

4. Das habe ich auch gerade bei einem erneuten Laufversuch bemerkt. Ich lasse jetzt einfach die Variable gleichzeitig mit der Variable "Schritt" auf Null setzen.

Vielen herzlichen Dank für die Tipps!

Aber vielleicht könnten trotzdem noch ein paar andere Fischertechnikfreunde auf das Programm gucken, evtl. sind noch mehr Fehler darin enthalten, oder können mir noch ein paar Tipps geben, wie ich herausfinden kann, ob es sich nicht doch um einen Hardwarefehler handelt. Die Verzögerungen sind nämlich immernoch, genau so wie die nicht registrierten Tastbefehle, vorhanden.

Patrick P.

[han]

Hi Patrick.

You are right, the variable Schritt should be global in the concept of your program. Just judging too fast, but it isn't easy to debug someone else's program. And I was just wondering that the legs move forward two by two in your program, but move back all at the same time when Schritt=6.

I can't help you with possible hardware problems, since I have only one RoboTX. But there are many people, more knowledgeable than I am, here in this forum. I can only say that the communication between the RoboTX and the PC is rather slow (with USB and especially with Bluetooth). You can test your program in download modus.

And this hint may help you further with the tedious task of debugging: monitor in your main program the state of your inputs and variables Schritt and Fertig with the ('orange') input elements and panel displays. Then you can see what happens and test the switches.

Und: Ich lese gern Deutsch, aber schreiben: zu viel Fehler!.

Gruss, Han.

[vleeuwen]

Hi Han,
The FT-brick connection is not real slow but the user must take in account that in the online mode the sample rate is +/- 10 ms for USB and as rough rule of the thumb (pag 163 ISBN:978-0-470-14107-6) 50ms for Bluetooth. (Most of the time the TX-C is in the online mode with BT faster 15-30 ms but that is not a real (semi) real time specification.)

Based on the sample theorem:
This means that the TX-C can deal with symmetrical pulses with a theoretically maximum frequency of
50 Hz in USB online mode,
10-20 Hz in BT online mode.
The duration of the high and the low part of a pulse must be at least 10 (USB)/25 (BT) ms
With the normal ft-taster the pulse is most of the time not symmetrical, so the work frequency will be lower. (Use Fourier/Z transformation to go from the time domain to the frequency domain)