Tx Controller, Spurensensor, Motoren und Akku

[rabo]

Hallo,

habe Robo TX Training Lab und mir sind einige dinge aufgefallen. (Modell Gabelstabler)

- Lade ich den Akku Schalte danach den TX Explorer und lasse das Programm über die Software laufen (BT verbindung), hängt es nach dem ersten Einschalten nach kurzer Zeit. Muss den TX Explorer aus und wieder einschalten und das Programm erneut laden (BT Verbindung) funktioniert es. Gibt es hierzu bekannte Probleme, die ich vermeiden kann?

- Gibt es eine einfache möglichkeit die Geschwindigkeit bzw. Kraft bei den Encoder Motoren zum Ladestand des Akkus anzupassen? Wenn ich mir die Robopro Software so ansehe, müsste ich dann vor jedem Motorlauf die Spannung des Akkus abfragen und dann eine entsprechenden Motorlauf aussuchen. Währe es nicht besser, wenn man das bei der Motorsteuerung mit abfragen könnte. Ansonsten laufen Sie mir entweder zu schnell oder zu langsam.

- Beim Schrittweisen lauf ruckelt es immer so. Kann ich den auch so hinbekommen, dass dies nicht der Fall ist?

- Habe festgestellt, dass ich die Encoder Motoren immer stoppen muss, obwohl beim Schrittweisen Synchronlauf doch auch ein Stopp mit drinnen ist! Warten auf ....1 Habe ich schon mit eingebaut. Macht aber dennoch Probleme, da beim nächsten Warten auf...1 ohne vorheriges Synchronstopp (Programmablauf: - Synchronstopp -> Motorschrittweises laufen -> Warten auf...1 -> Synchronstopp) das Programm beim Warten auf...1 hängen bleibt.

- Es anscheinend unterschiede bzgl. des Programmlaufes gibt, wenn das Programm vom Computer aus gestartet wird oder auf dem TX Controller ausgeführt wird.

- Bis jetzt habe ich es noch nicht geschafft, dass der Gabelstabler die Palette 10 - 20 mal am stück ohne Probleme von A nach B bringen kann ohne irgendwann aus der Spur zu kommen, oder die Palette nicht mehr aufladen kann, da sie verschoben ist. (Die Palette macht da mehr Probleme als die Spur) Wenn ich das Modell zu schnell fahren lasse kommt es komplett aus der Spur zu langsam bleibt es schnell mal hängen (Könnte aber auch das Problem von oben sein, teilweise höre ich aber den Motor, dass er gerade zu wenig Kraft hat und muss ihn anschubsen). Durch Korrekturen kurz vorher kann das aufladen der Palette verschoben sein und irgendwann kann er sie nicht mehr aufnehmen. Wenn er unterwegs komplett aus der Spur fällt, kann ich keine Korrektur fahren, da ja das Ende der Strecke laut Programm signalisiert wird und dann auf oder abgeladen wird. Kann man das ganze auch entsprechend absichern, dass es quasi narrensicher wird?
(Der Akku reicht schon gut einen Tag bei den Testläufen jetzt)

Grüße
Ralf

[hwrobel]

Hi,

ich beschäftige mich wohl mit ähnlichen Problemen.

Das Ruckeln beobachte ich auch, und habe momentan den Verdacht, daß es am Programm in Zusammenhang mit der Geschwindigkeit meines PCs liegt. Bei "Kurvenfahrt" in der Spurensuche hat man ja eine wiederholte Kette von erweitertem Stopp beider Motoren und Einschalten nur eines Motors, bis die Spur gefunden wurde. Stopp/Start/Stopp/Start/etc. Das muß ja eigentlich ruckeln, je nachdem wie flott der PC die Kommandos zum TXC schicken kann, oder?

Vielleicht kann ich das heute abend mal genauer testen ...

Heinz

[FischerPapa]

Hallo,
ich denke dieses Ruckeln liegt eher nicht an der Geschwindigkeit des Computers, da er sowieso schneller ist als der TXC aber ich denke es liegt an der Verbindung. Bluetooth ist halt trotzdem noch langsamer als USB. Und im Downloadmodus besteht ja keine Verbindung also denke ich ist das für die Encodermotoren das Beste. Ich habe das auch schon bemerkt, dass wenn ich die Encodermotoren im Onlinemodus (USB-Anschluss) laufen lasse und sie eine Position anfahren lasse, sie immer an einer anderen Stelle stehen bleiben. Hingegen beim Downloadmodus fahren die Encodermotoren auch Reproduzierbar die genau gleiche Position an. Ich hoffe ich habe euch helfen können.

[vleeuwen]

About the sample speed for closed control loops:
USB, 10 ms => absolute max frequency for the switch 50 Hz (ideal situation, pulse must be symmetric=>10ms high, 10 ms low).
Practical 30 to 30 Hz as maximum counter frequency; Low or high >10ms
Bluetooth, is a streaming protocol, a rough rule of thumb (literature pag. 163 ISBN: 978-0-470-14107-6) advises to calculate with 50ms => max frequency for the switch 10 Hz (Low or high > 50 ms ).

[rabo]

Hallo,

habe schon festgestellt, dass die Programme besser funktionieren, wenn ich sie direkt auf dem TxController starte.
Scheint wirklich an den Laufzeiten der Übertragung zu liegen.

Währe WLAN dann nicht besser geeignet für den TX Controller anstatt Bluetooth?


Grüße
Ralf

[vleeuwen]

WLAN/WIFI IP/TCP), I don't think so.
Beside the transmission speed, there exists also a latency.
Control system (semi real time behavior) with closed control loops you will need special protocols without latency; like Zigbee.
BT is a streaming protocol with a variable latency.

However if you take care of these limits, there will no real problems.
In case you need more speed in the online mode, see what the professional market is offering, for example the interface and software form National Instruments.

I am using a trail sensor in the online mode BT connected (MS-RDS) with the complete implementation of the state machine
(5 states: sensors on the line, sensors off the line, left on the line, right on the line, disable).
The position of the trail sensor with respect to the drive wheels and the algorithm to get the sensor back on the line is more important than the refresh rate.
Advise: make a nice drawing of the position of the sensor and the wheels and calculate with some simple math the effect of your algorithm.

[schuessm]

Hallo,

ich kämpfe hier mit den gleichen Problemen. Der Stapler ruckelt beim Folgen der Spur viel zu stark. Beim langsamen Fahren etwas weniger als beim schnellen Fahren. Selbst die ausgelieferten Programme machen dies nicht besser. Arbeite nur im Downloadmodus, da ich auch festgestellt habe, dass alles Andere zu ungenau ist und komische Effekte mit sich bringt.

Habt Ihr hier schon eine Lösung gefunden?

Danke für alle Ansätze die zur Lösung führen können.

Beste Grüße

schuessm

[vleeuwen]

Hi,
Your basic problem is the stability of your "closed control loop"; the way you try to correct the transistions in the state machine and the speed of these corrections.

See here for the complete trail sensor state machine.
http://web.inter.nl.net/users/Ussel-Int ... Sensor.htm

First of all, your trail follow application needs to cover the most essential trail sensor transistions.
A transistion in the state machine needs to lead to a change in speed of both wheels.
This in away that the sensor turns back on the line and stay on the line.

The mechanisme listens to the name "closed control loop", a well known issues in the control engineering world.
The sample frequency of the sensor (online mode 10 ms usb, 10-40 ms BlueTooth) has a norrow relation with the stability of this "closed control loop". When the car speed is too high or the changes are coming fast, this system will be instable and does not work.

1) To start, when your car notice a state transistion, stop both wheels.
2) Start with finding back the line (execution of your algoritme).
3) After finding back, stop both wheels.
4) Start the car with going forwards.

If this is working, try to left out the stops and later try to speed up the wheel speeds.

The position of the sensor in relation with the centre of rotation of the car is also playing an importend role.
"centre of rotation" has a relation with/ depends on the left and right wheel speed (difference)!!!!