Pic Compiler Odometrie

hy.

ich habe schon unter sensoren mein problemchen gepostet, aber da kennt sich anscheinend niemand mit aus bzw. fühlt sich keiner angesprochen.

deswegen hier mein problem: ich will odometriedaten (also die radimpulse) von zeit zu zeit in ein array schreiben. Bisher nutze ich MPLAB mit CC5X-compiler. Leider macht dieser compiler bei 256bit die schleusen zu und ich bin auf der suche nach was anderem.

hat jemand überhaupt mal so was ähnliches gemacht und mit welcher software arbeitet ihr? weiß jemand zufällig welcher compiler da mehr bietet?

ich hoffe ihr habt ahnung. viele grüße.

kennt jemand zufällig den HI-TECH Compiler? Den gibts nämlich auch als kostenlose Lite-Version und kann ihn in MPLAB einbinden. Will nämlich nicht auf MPLAB verzichten, genauso wenig wie ich mehrere hundert euro für nen compiler ausgeben will.

Zitat:

---

Zitat von sensemann

hy.

... ich will odometriedaten (also die radimpulse) von zeit zu zeit in ein array schreiben. Bisher nutze ich MPLAB mit CC5X-compiler. Leider macht dieser compiler bei 256bit die schleusen...

---

Hallo.

Also was für einen Prozessor nutzt Du denn, gab es nicht für die 18er Reihe eine freie „S-Version“ von Microchip als C-Compiler.
Welche Datenmengen (Anzahl Datenreihen und Radencoder) in welcher Größe (8/16/32… Bit) willst Du denn, gegebenenfalls auch wohin (bei größeren Datenmengen) speichern. Wie sieht denn Dein geplantes Array aus, was hast Du im Endeffekt vor und wenn es Dein Compiler nicht bietet, kannst Du die Struktur nicht gegebenenfalls anpassen bzw. aufteilen oder geg. mit Übertrag arbeiten?
Zu den von Dir genannten C-Compilern kann ich allerdings nichts sagen, da ich prinzipiell bisher nur MPLAB mit Assembler genutzt habe, aber da wird Dir sicher noch jemand anderes weiterhelfen.


Gruß André

hy André

ich hatte eigentlich vor den 16F877 zu nutzen (nur zur odometrie).

Zu der größe der Datenmenge kann ich noch nichts genaues sagen, weil noch nicht hundertprozentig feststeht wie groß die räder werden und welche genauigkeit ich letztenends brauche. gewiss ist aber schon mal dass es nicht wenige sein werden.

deshalb habe ich versucht mal ein kleines programm zu schreiben welches den unten beschriebenen ablauf simulieren soll, habe dabei aber gemerkt dass die ressoucen nicht mal ansatzweise ausreichen.

Im prinzip habe ich folgendes damit vor:
Ich will dass die maschine nachher lernen kann d.h. ich sage ihm vor beginn der fahrt "lernen" und er zeichnet die odometriedaten auf, die erzeugt werden während ich die maschine per joystick fahren lasse.

dabei sollen alle X µs (oder ms -je nach dem was er mal für ne endgeschwindigkeit haben wird) die odometriedaten in das Array schreiben.

Eine möglichst große Abtastfrequenz ist hierbei natürlich unerlässlich, damit er den vorher aufgezeichneten weg möglichst genau nachfahren kann.

noch was: der roboter bekommt zwei antriebsräder (daran die odometriesensoren - keine angst, schlupf wird nicht auftreten) und ein drittes, zwangsgelenktes pendelrad.

an eine art übertrag habe ich auch schon gedacht, allerdings ist das so ne sache weil die odometriewerte einem zeitfenster zugeordnet sind und somit schlecht summiert werden können...

wohin bei größeren datenmengen? gute frage. wenn der interne flash nicht reicht (was je nach anwengung warscheinlich ist) werde ich um eine CF-erweiterung nicht herumkommen...)

naja, ich hoffe mal du weißt jetzt ungefähr was ich vorhabe. ich werde gleich mal nach dieser s-version schauen. aber vielleicht gibts ja noch ein paar möglichkeiten wie ich das mit dem 877 hinbekomme.

viele grüße

Hallo,

wenn Du per Joysticks steuern möchtest, dann gehe ich davon aus, dass Du den Joystick sicher nicht auf dem Bot installierst. Also wirst Du sicher eine Funk, Bluethooth, WLan oder andere Verbindung herstellen. Wenn dem so ist, wirst Du da sicher auch externe Rechenkapazität zum Anschluss des Joysticks benötigen, wäre es in dem Falle nicht einfacher die MC’s auf dem Bot nur für die „vor Ort“ Funktionen zu integrieren und die Hauptrechenarbeit auszulagern. Dann wäre die Datenmenge auch nicht mehr so relevant, da Du sie extern ablegen könntest.
Ansonsten solltest Du dies schon ungefähr abschätzen, wenn ich annehme, dass Deine Radantriebe PWM gesteuert sind, wirst Du schon (je nach Radgröße und Infosequenz) recht häufig zwischenspeichern müssen um den genauen Verlauf annähernd zu erhalten. Wobei Schlupf und andere „Fehler“ schon eine Rolle spielen werden.
Ich habe dies bei meinem Kettenfahrzeug etwas einfacher, da dieses pro Kette nur begrenzt verschiedene Geschwindigkeiten hat und damit erst bei Änderung der Richtung, Stopp oder der Geschwindigkeit die Summe der Encoderimpulse gesichert werden muss. Das ganze habe ich auch über WLan gelöst und der 18F442 + Servokontroller dient mir vor Ort „nur“ um die Befehle auszuführen, die größeren Datenmengen der Encoder und Sensoren laufen in der Zentrale auf.
Siehe hier…
https://www.roboternetz.de/phpBB2/ze...ht=asm5#326685

Gruß André

Hy.

Auf die Idee die Daten auszulagern bin ich noch gar nicht gekommen, vor allem weil ich den Bot komplett per µC (natürlich mit mehreren) steuern wollte. Aber warum eigentlich nicht.
Vorteile neben der großen Speicherkapazität und der hohen Rechenleistung wäre beispielswese die Kartierung wie du sie schon beschrieben hast. Der Bedienkomfort ist sicherlich auch ne ecke besser. Leider gibts da noch ein paar Nachteile, weshalb ich mir das ganze noch mal bißchen überlegen muss. Darunter zählen erhöhter Stromverbrauch und die zunehmende Fehleranfälligkeit, ganz neben den finanziellen Aspekten, die hier aber natürlich nicht die entscheidende Rolle spielen sollen.

Wie hast du das bei dir gemacht? Dein Projekt mit dem Kettenfahrzeug hört sich interessant an. Kann ich mal ein Screenshot von deiner Kartierung sehen? Welches Betriebssystem hast du laufen und womit hast du die Sachen am Rechner programmiert?

besten Dank und viele Grüße

Hallo,

also Fehler durch die RS232 Datenübertrag auf Basis des WLAN habe ich keine. Verlust der Kommunikation ist nur bedingt ein Problem, da der Bot zwar in dem Falle nur noch den letzten empfangenen und bestätigten Befehl ausführt, aber sonst nichts passieren kann. Ein Fahrbefehl bedeutet aber auch nicht einfach "Vorwärts" etc., sondern wird grundsätzlich mit einer Streckenangabe in cm übermittelt, welche vorher durch die IR/US sensorig als frei in die Karte eingetragen wurde. usw. usw.
Stromverbrauch ist bei mir nicht relevant, da ein "kleiner" PC sowieso ständig zwecks Hausautomation (IP-Symcon) läuft. Fertige Programmabläufe werden dann einfach per Code über die Tastatur am Bot gestartet.
Das Programm ist in Delphi für den Host und Assembler für den MC geschrieben.
Die Karte wächst mit der Zeit, so wie die IR-Karte auf dem Foto (Infrarot Umgebung), welche in dem Falle aber nur einen einzigen Front IR Scan und einer anschließenden Fahrt von ca. 70cm darstellt. Hier waren die hinteren IR Sensoren nicht aktiv. Die Sonar-Karte ist durch die Scanreichweite auch zu Beginn entsprechend größer ausgeleuchtet, aber durch die Keule für eine gezielte Fahrt um Hindernisse zu ungenau.
So hat in der Karte jedes Feld (5x5cm ist zwar groß, aber der Bot ist ja 40x70cm) mehrere Bits hinterlegt, welches dann die entsprechende Informationen wie -unbekannt(noch kein Scan erfolg), IR-Frei, IR-Belegt, SO-Frei usw. beinhaltet. Visualisieren kann man das dann wie man lustig ist und die Botposition wird immer vom zentralen Botmittelpunkt inkl. der Frontrichtung entsprechend der Größe neu gezeichnet.

Mein Problem ist es, die Karteninhalte deckungsgleich zu bekommen, nachdem durch mehrere Bewegungen und dem damit verbundenen Schlupf, besonders beim Drehen, die Hindernisse nach wiederholten Scans etwas versetzt sind ohne das der Rauminhalt dann verzerrt. Das gleiche Problem bei Retour einer längeren Fahrt, da auch hier ein Versatz durch Addition der Ungenauigkeiten (Encoder+Kompass und Schlupf) entsteht. Ich müsste also auch hier noch doch erneute Scans die Position in der Karte oder die einzelnen "Rück"-Bewegungen korrigieren.


Gruß André

hy.

sorry erstmal dass ich mich so lange nicht mehr gemeldet habe, hatte in der letzten woche sehr viel zu tun.

besten dank für deine ausführliche beschreibung. allerdings glaube ich dass ich mir mit meinem entwurf noch mal gedanken machen muss. nur wegen den odometriewerten will ich die steuerungsprozesse nicht auslagern, weil ich mich dann in zu viele felder in zu kurzer zeit einarbeiten müsste. vielleicht wird das mal eine erweiterung. aber vorerst will ich den bot per µC zum laufen kriegen, muss mir also weiter gedanken um die arrayprogrammierung machen. aber besten dank für die mühe.

bis bald
-sensemann

Zitat:

---

Zitat von sensemann

...allerdings glaube ich dass ich mir mit meinem entwurf noch mal gedanken machen muss. nur wegen den odometriewerten will ich die steuerungsprozesse nicht auslagern...

---

Hallo,

nein,... nur deshalb wäre es sicherlich auch übertrieben...
Ich hatte es auch aus anderen Überlegungen getan, besonders aber wegen der externe Rechenkapazität, der geplanten WLAN Cam und der externen Verbindungsmöglichkeit,.. sprich Steuerungsmöglichkeit per Internet...


Gruß André