Druckbare Version
Moin,
eine "außerparlamentarische" Frage: Diese Bleche mit den Löchern drin, die sich so gut biegen lassen. Wie heißen die und wo kriegt man die? ich habe zwei "linke Hände" und die Bleche scheinen DIE Lösung für viele meiner Probleme zu sein.
Viele Grüße
Red Baron
Das Aluminium hatte die Abmaßen 1m x 0,5m glaub ich. Ich habe es von Bauhaus, dort gibt es eine Abteilung, wo verschiedene Bleche (mit Löchern, ohne Löcher, Alu, Kupfer usw.) einsortiert sind.
Ich beschreibe es so weil es so komische Größen sind, die man "als richtiger Handwerker" wohl eher als Verschnitt einstufen würde. Der Preis ist mit rund 10 - 15€ auch wahrscheinlich unverhältnismäßig hoch.
Bild hier Bild hier
Für eine kleine Bastelei am Rande ist es super zu bearbeiten.
Hallo,
das "Problem" so denke ich, ist halt diese Update Rate. Wenn ich das richtig interpretiere wird die Kommunikation PC <-> AdvancedServoBoard nur mit ~31Hz realisiert. So kannst du halt "nur" 31 mal in der Sekunde den Motor nach regeln was nach meinem Gefühl zu träge wird (Die Regeleinheit müsste halt sehr schnell sein) . Das kann man aber sicher mit Matlab oder Scilab Simulieren wie das aussehen wird.
Ich bin an so einem Motor Controller dran, was mir nur gerade sorgen bereitet sind die 6 Timer für 2 Motoren die man Idealerweise bräuchte. Kann dich ja auf dem Laufenden halten, Platinen könnte ich dir dann zuschicken wenn es mal soweit ist ;).
Ich hab mal mein (scheinbar recht altes) Oszilloskop aus dem Keller geholt und die PWMs fotografiert. Die Schalterstellungen habe ich absichtlich auf den Bildern gelassen weil ich so ein Teil vor über 8 Jahren das letzte Mal benutzt hab und nicht sicher bin, ob die Einstellungen so optimal sind.Zitat:
Zitat von the_muck
Verglichen habe ich das Phidget ServoController Signal mit deinem (auch sehr alten) Empfänger den ich noch im Schrank hatte. Das ist ein 4-Kanal Robbe Empfänger. Die Oszilloskopeinstellungen habe ich nicht verändert.
Bild hier
Bild hier
Du entwickelst selbst einen Treiber? - So hat jeder seine Laster. ;)Zitat:
Zitat von the_muck
Solang mir hier nichts abbrennt, freue ich mich über jedes Stück Hardware, dass mir keine weiteren Steine (beim Entwickeln der Software) in den Weg legt.
Mein RN-VN2 DuaMotor Board ist gestern angekommen. Soweit macht das einen guten Eindruck. Die Steuerung per Phidget Interface ist damit auch machbar. Irgendwo steckt aber leider noch der Wurm drin.
Ich habe wegen der Eletrotechnik-Nähe einen eigenen Thread aufgemacht.
https://www.roboternetz.de/phpBB2/vi...=500771#500771
Vielleicht fällt dir dazu ja etwas ein.
Hallo,
ach her je, ich glaube du verwechselst da etwas :(, was du aufgezeichnet hast sind die PWM Signale für die Servos, diese werden auf deinem Board durch Controller erstellt, dieser Controller wird, wenn ich das richtig sehe, nur 31 mal in der Sekunde aktualisiert. Die Signale müssen gleich sein, da beide Servos ansteuern die ein recht "Genormtes" Signal haben.
Für die Motoren brauchst du aber ein PWM Signal welches z.b immer eine Logische 0 hat (Motor Speed =0) und immer eine Logische 1 (Motor Speed = Max).
Man Pulst einfach die Spannung mit einer recht hohen Frequenz am Motor...Code:
| = PWM Start, Flanke positiv
--- = High, ___ = Low
Motoer Speed = 0
|0000|0000|0000|0000...
|____|____|____|____...
Motor Speed = Max
|1111|1111|1111|1111...
|------|------|------|-----....
Motoer Speed = 50%
|1100|1100|1100|1100...
|--__|--__|--__|--__...
Moter Speed ~75%
|1110|1110|1110|1110...
|---_|---_|---_|---_.....
Das sind nun aber zwei Paar Schuhe da du mit deinem Servo PWM diese Zustände nicht erreichst...
Ideal wäre, was ich meinte, einen Treiber Baustein zu basteln der dein Servo PWM in ein Motor PWM wandelt, die Endstufe (H-Brücke) anspricht aber gleichzeitig auch die Regelung der Motoren übernimmt...
http://www.shop.robotikhardware.de/s...roducts_id=128
Den Zusammenhang zwischen PWM und Motoransteuerung durch das takten der Batteriespannung hatte ich verstanden.
Meine Vermutung war, dass das PWM-Signal so "selten" gesendet wird, dass es der Motortreiber als 100%, 0%, 100%, 0% Schaltdauer interpretiert also überabtastet und damit an die Motoren nur 50% der Schaltdauer weiterreicht.
Ich habe mit einem größeren High-Anteil auf der PWM Leitung gerechnet. Das Oszilloskop habe ich wieder in den Keller gebracht weil ich aus dem Motorsignal auch nicht schlauer geworden bin.
Da mein Fokus ja auf der Software liegt, habe ich mich nun entschieden ebenfalls ein Phidget-Board zur Motoransteuerung zu verwenden. Es sind leider wieder hohe Kosten im Vergleich zum RN-Treiber aber ich will vorankommen. :(
Das Phidget zur Motorsteuerung hat sich definitiv gelohnt.
Mittlerweile ist es seit über einem Monat verbaut und arbeitet tadellos. Die Beschaltung ist denkbar einfach. USB dran, Energieversorgung dran und beide Motoren anschließen. Zusätzlich hat man noch 4 digitale Eingänge, die ich aber nicht nutze. Die Steuerung per Software lässt sich von -100% bis +100% pro Motor festlegen. Dazu gibt es die Möglichkeit, die Drehzahlsteigerung zu drosseln. Damit kann ich langsamer beschleunigen um Schlupf zu verringern und beim Bremsen die Motoren aber sofort stoppen.
Bild hier
Ich habe mich bemüht, die Aufnahme der Raddrehzahl zuverlässiger zu gestalten. Meine Konstruktion besteht aus zwei Gabellichtschranken, die die Raddrehzahl direkt von den Antriebsachsen abgreifen. Dafür habe ich die bereits erwähnten Maussensoren gestutzt und in eine legofreundliche Bauform gepackt. Das Ergebnis ist nicht mehr allzu kompakt dafür aber 100% bausteinkompatibel.
Bild hier Bild hier
Eine Radumdrehung erzeugt mit den 32 Zähnen (ich hatte vorher manuell 40 gezählt..) nun 74 Flanken, die sich auswerten ließen. "Ließen" weil sich durch die hohe Anzahl der Zähne bzw. die kleine Bauweise Probleme ergaben, die sich natürlich erst nach zwei Tagen experimentieren ergeben hatten.
Meine PhidgetBoards sind ältere Versionen und können digital rund 125 Schaltvorgänge pro Sekunde verarbeiten, analog liegt das Board laut Doku bei 65 pro Sekunde.
Da die Gabellichtschranken digital angeschlossen sind, sollte ich mit knapp zwei Radumdrehungen pro Sekunde noch grade hinkommen. Im Notfall wird halt langsam gefahren. Es stellte sich raus, dass aber bereits bei knapp 40 Ticks/Sekunde also 20 Zähnen pro Sekunde Schluss war. Sobald ich die Drehzahl erhöhe, erkennt der Phototransistor die Lücken nicht mehr ordentlich. Nach einigen Versuchen mit Sonnenlicht, im Dunkeln usw. habe ich die Lichtschranken mit etwas Pappe abgedeckt.
Ich vermute, dass die Phototransistoren bei Tageslicht soviel IR-Licht antreffen, dass sie ständig gesättigt sind und das ankommende Licht der IR-LED bei Dunkelheit nicht mehr ausreicht, die Phototransistoren durchzuschalten. Ich habe ein paar Schaltpläne zum Aufbau gefunden und diese auch mit einigen Widerständen nachgebaut aber irgendwie will das Ganze nicht so recht.
Zuletzt hatte ich noch mit ausgedruckten Encoderscheiben und meinem 5mm IR Sensor Versuche gemacht. Das Bauteil nutzt ein moduliertes IR Signal, was es wesentlich störunempfindlicher macht. Da mein analoger Eingang aber nur die 65 Schaltvorgänge pro Sekunde schafft, wäre meine Raddrehzahlauflösung nicht höher als meine bisherige Microschalter-Konstruktion. Die Gabellichtschranken lasse ich am Roboter montiert und verwende aber nun weiterhin die mit 6mm pro Tick recht grob auflösenden Microschalter.
Bild hier Bild hier
Ich hatte mich schon eine Weile umgeschaut, wie ich erhältliche Gyroskope und Bauteile wie einen Kompass unkompliziert per Software abfragen bzw. überhaupt erstmal an das Netbook anschließen könnte. Meine Wahl wäre ein Android Hand gewesen wenn nicht zufällig vor einigen Wochen das Spatial Board mit eingebautem 3-Achsen Beschleunigungssensor, 3-Achsen Gyroskop und 3-Achsen Magnetfeldsensor (sprich Kompass) erschienen wäre.
Die Hardware wird wie gewohnt über die Phidget-API angesprochen wodurch ich keine weiteren Abhängigkeiten oder Frickelei in Kauf nehmen muss. Die Platine ist recht kompakt und wird per USB verbunden. Unter dem Holzbrett habe ich einen USB-Hub verbaut womit eine kurze Leitung USB-A zu Mini-USB ausreicht. Der Sensor ist ungefähr mittig zwischen den Sensortürmen befestigt.
Bild hier Bild hier
Die Sensortasten zu verwerten ist nicht so leicht, wie ich mir das vorgestellt hatte. Die "Anschließen und Staunen"-Beispielanwendung zeigt die Werte der Sensoren und macht Bock auf mehr. Der Quelltext liegt bisher nur in C# vor. Den Punkt hatte ich überlesen und es erstmal zu Fuß versucht. 8)
Aktuell nutze ich den Giro um meine Rotation auf der Stelle zu erfassen. Ich kenne meinen Drehpunkt ungefähr und habe den Bauteilen entsprechend Matrizen zugewiesen, die die Pose des Roboters speichern sollen. An der Software hat sich auch einiges geändert, ein paar neue Threads sind zuschaltbar, die Sensorwerte, Drehwinkel usw. ausgeben.
Vorgestern habe ich den Roboter etwas herumfahren lassen und vom Rechner aus beobachtet, was er so an Punktwolken sammelt..
Das Ergebnis ist unten zu sehen. Ich verlasse mich bei dem Scan allein auf die Microschalter-Odometrie in der translatorischen Bewegung. Beim Rotieren werden Kompass usw. zwar abgefragt, aktuell aber nur eine Achse des Gyroskops verwertet. (Der Bot fährt übrigens noch immer nicht geradeaus. Das schiebe ich noch etwas vor mir her.)
Die Punkte auf den Ständern sind erfasste Hindernisse. Die Linien, die von den Punkten wegführen, zeigen die Position des Sensors. Auf dem Untergrund ist in rot die Fahrstrecke markiert. Stellen, die vor Linien kaum noch zu erkennen sind wurden häufiger abgetastet. Eine GUI muss an der Stelle unbedingt mal her damit das übersichtlicher wird..
Bild hier
Der Roboter ist von meinem Arbeitszimmer (links oben) in den Flur (rechts oben) in die Küche gefahren (rechts unten). Die aufgenommenen Punkte werden einfach in die Karte aufgenommen, also weder geprüft, gematcht oder ähnliches.
Ich habe einen Bildexport für die Kartierung begonnen. Es erlaubt auf Klientseite das Abfragen der aktuellen Roboterkarte, die dann lokal auf dem Rechner gespeichert wird.
Man kann die Auflösung des Bildes durch den Parameter "MillimeterProPixel" bestimmen. Idee dahinter ist, die flexible Auflösung der Karte ebenfalls auf dem Roboter zu haben damit dieser verschiedene Ansätze zur Selbstlokalisiation durchführen kann.
Bild hier
Auf der Karte lässt sich direkt der klassische Odometriefehler erkennen. Ich hatte bei der Kartierung keine Wegstreckensynchronisation gestartet wodurch der Roboter bei der Geradeausfahren nach rechts tendiert.
Auf der (theoretisch) abgefahrenen Route werden bei jedem Stopp zwei Nadeln dargestellt. Zu jeder Pose werden Ticks, Beschleunigungswerte, Magnetfeld und die berechneten Gyrowinkel gespeichert. Die grün/rote Nadel zeigt Nord und Süd an, die dunkelblaue Nadel zeigt die Orientierung der Gyroskop z-Achse.
Das untere Bild lässt vermuten, dass sich das Erdmagnetfeld offenbar schlagartig neu ausgerichtet haben muss. ;) - Der herausstehende USB-Stecker hatte sich am Tischbein verkantet und eine Drehbewegung des Roboters bewirkt. Eine kontinuierliche Aktualisierung der Roboterpose per Giro und/oder Kompass sollte die Fehlerquelle einschränken können..
Bild hier
Nächste Woche werde ich mich mit der präzisieren Kartenerstellung und einfachen Möglichkeiten der Lokalisation beschäftigen.
Euch ein schönes Wochenende!