Volksplattform für Roboter auf ROS

Der Artikel richtet sich nur an diejenigen, die Teil von ROS selbst sind und einen echten Roboter für das Training oder die Ausführung realer Aufgaben bauen müssen.







Wenn Sie mit dem Erlernen von ROS beginnen, möchten Sie normalerweise mit physischen Plattformen arbeiten und nicht mit Modellen in einem Simulator. In der Tat reicht Gazebo aus, um nur Bewegungsalgorithmen zu studieren oder ROS selbst zu lehren, aber die Arbeit mit einer realen Plattform ermöglicht es sofort, alle Probleme mit der Radbewegung in der Praxis zu verstehen. Nun, und oft wird die Plattform einfach als Voraussetzung für das Projekt benötigt.



Für die Zukunft ist es besser, mit einer Runde zu beginnen, weil Aus offensichtlichen Gründen kann sich eine solche Konfiguration um die Achse drehen, ohne die Größe des hervorstehenden Teils zu berücksichtigen. Das U-Turn-Rechteck ist zum Beispiel in engen Korridoren viel weniger praktisch - manchmal ist es notwendig, drei oder mehr Tricks zu entfalten, denke ich, dass Autofahrer verstehen werden.

Fertige Plattformen kaufen

Es gibt nicht viele vorgefertigte Plattformen auf dem Markt, sie sind auf der ROS-Website aufgeführt .



Gleichzeitig sind ihre Kosten in Russland hoch genug, um mit der Arbeit zu beginnen. Die billigste Option ist Turtlebot Burger 3 - 549 US-Dollar. Wir haben Wiederverkäufer direkt in Russland für etwa 90.000 Rubel gefunden.







In China können Sie für 45-50 tr ... In jedem Fall handelt es sich um Plattformen mit geringer Größe und Tragfähigkeit, die nicht in der Lage sind, echte Aufgaben auszuführen.



Sie können die Plattform selbst erstellen, es gibt viele verschiedene Anleitungen und Konfigurationen. Aber im Durchschnitt stellt sich heraus, dass:

• Lidar der Klasse Slamtech A1-A2
• Billige Räder basierend auf Kollektormotoren mit Getriebe
• , PWM , UART + rosserial.
• Single Board Computer — Raspberry, Jetson Nano
• 2
• gmapping + amcl/rosbot_ekf + move_base

Die Kollektormotoren haben uns nicht gefallen, weil sie laut sind, einen hohen Verbrauch haben und ein Getriebe benötigt wird. Hier muss ich sagen, dass die Plattformen als ziemlich schwer angesehen werden - d. H. Verriegelte Getriebe + Motoren, so etwas wie der Motor auf dem Foto, funktionieren nicht.



Dementsprechend wurden BLDC-Radmotoren als Beweger ausgewählt. Die derzeit günstigste Option sind die 6,5-Hoverboard-Räder. Es bleibt nur, sie von ROS aus zu verwalten.



Aber dann tauchte ein Problem auf: Selbst bei der Arbeit mit Golfrobotern wurde ein erhebliches Problem bei der Drehung einer solchen Plattform mit niedriger Geschwindigkeit festgestellt - der Roboter drehte sich ziemlich ruckartig um.



Die Gründe für dieses Verhalten sind einfach: Gleitreibungskräfte spielen eine wichtige Rolle für den Bewegungswiderstand in der Kurve. Und sie haben eine Besonderheit - der Widerstand hängt von der Masse und der Art der Oberflächen selbst ab - deshalb hält ein kleiner Bolzen bei den ersten 2-3 Umdrehungen große Strukturen.



Daher wird es ziemlich sinnlos, die Räder in der Mitte schmal zu machen, so dass sie sich drehen - der Widerstand ändert sich nur sehr wenig. Das Gummirad reibt an Gras und Boden, die überhaupt nicht gleichmäßig sind und die Kraft kann sich dramatisch ändern. Infolgedessen wurde so etwas wie ein Getriebe hergestellt - bei niedriger Geschwindigkeit steuern wir den Moment am Rad und bei direkter Bewegung die Geschwindigkeit selbst.





Es scheint, dass beim Fahren auf Parkett oder Linoleum die Situation besser sein sollte, aber leider ist der Reibungskoeffizient fast der gleiche (denken Sie daran, dass rutschfeste Schuhe ebenfalls aus Gummi bestehen).







Infolgedessen beginnt sich ein Roboter mit einem Gewicht von 10 bis 15 Kilogramm bereits mit spürbaren Rucken zu entfalten.



Der zweite Teil des Problems wird durch das ROS diff_drive-Paket in Kombination mit eher schwachen SBC-Karten hinzugefügt.

Hier ist eine Liste von dem, was ich verstanden habe

Die Verwaltung erfolgt mithilfe einer Echtzeitimplementierung, berücksichtigt jedoch nicht, dass andere Pakete diesen Ansatz bei der Arbeit mit der Verwaltung erwarten sollten.



Hier müssen wir uns daran erinnern, dass Echtzeit keine sofortige Reaktion auf ein Ereignis ist, sondern eine Garantie dafür, dass das Ereignis in garantierten Intervallen physischer Zeit verarbeitet wird. Jene. Das bedingte Wasserkraftwerk, das jede Minute (notwendigerweise jede) geregelt wird, ist ebenfalls ein Echtzeitsystem.

Es besteht die Möglichkeit, dass Nachrichten die Themen des Routenplaners verstopfen. Bei Subsystemen zur Positionierung und Routenplanung führt dieses Verhalten normalerweise dazu, dass der Fluss entweder gestoppt und neu gestartet wird oder versucht wird, den Prozess im laufenden Betrieb anzupassen.







Infolgedessen tritt bei schwachen SBCs eine Situation mit einer kontinuierlichen Neuberechnung des Pfades aufoder die Suche nach Lokalisierung beansprucht eine ziemlich große Prozessorzeit - und je mehr Versuche unternommen werden, mit der RT-Komponente Schritt zu halten, desto mehr Zeit läuft an. In seiner reinen Form positives Feedback, das in diesem Fall überhaupt nicht benötigt wird.



Darüber hinaus funktioniert das Gmapping bei abrupten Änderungen der Plattformposition nicht sehr schnell, und es wurden schwache Lidar-Pausen von bis zu einer halben Sekunde beobachtet, was den Routenplaner ebenfalls sehr verwirrt.



Die Motoren werden separat gesteuert, sodass bei Verwendung von SBC und naiver Implementierung von Treibern die Räder mit einer gewissen Verzögerung gesteuert werden.



Hier ist das Problem noch einfacher - wir müssen 2-4 Räder über den Kommunikationskanal steuern, der. Dementsprechend richten sich Steuersignale aus und beginnen nacheinander zu übertragen - linkes Rad, rechtes Rad, linkes Rad, rechtes Rad.



Infolgedessen tragen die Räder selbst und noch schlimmer die Positionen der Räder von den Encodern zur Bildung des PIC zwischen der Planung des Pfades und der Steuerung der Motoren bei.

Die eingebaute Kilometerzähler sind sehr einfach.

Da wir nicht nach einer einfachen Möglichkeit suchten, den Befehl und die Rückkehr der Kilometerzähler zu synchronisieren, konnten wir ihn nicht finden. Die Synchronisierung ist immer mit dem Warten auf einige Befehle am Eingang verbunden, diese sind jedoch nicht regelmäßig und daher beginnt die Kilometerzähler am Ausgang zu verweilen. Vielleicht schlagen die Leser einen einfachen Weg vor - hier betrachten wir uns nicht als Guru in ROS.



Es ist uns nicht gelungen, sicherzustellen, dass sich eine solche Versammlung gut verhält. Genauer gesagt konnte die Beschleunigung der Verschiebung auf 0,05-0,1 m / s ^ 2 und die Winkelgeschwindigkeit auf 0,03 rad / s unterschätzt werden.



Ich dachte, es wäre schön zu haben:

• Günstige Plattform
• Synchrone Radlenkung
• Kilometerzählerberechnung basierend auf Radverhalten und Handling
• Drehbewegungsmodi mit verschiedenen Bedienelementen
• Unterschiedliche Einschränkungen in verschiedenen Modi

Was ist am Ende passiert

Die Steuerung wurde von den Kreisel-Roller-Brettern genommen und die Radsteuerung wurde so geschrieben, dass beim Starten der Bewegung und beim Drehen eine Drehmomentsteuerung verwendet wurde. Und wenn der Wagen geradeaus fährt und auf eine bestimmte Geschwindigkeit beschleunigt, wird der Geschwindigkeitsregelungsmodus aktiviert. In beiden Modi werden die Daten von den Codierern innerhalb der Steuerung unter Berücksichtigung der Geschwindigkeit und des Modus verarbeitet, und die Daten werden mit einer Vorhersage vor 10-15 ms ausgegeben.



Encoder werden immer in der Steuerung eingelesen, sammeln sich in einem Puffer von 2-3 Elementen und werden verzögert übertragen. Die Quintessenz ist, dass beim Empfang der Steuerung die Antwort erst nach Ausführung des Befehls erfolgt - d. H. Der Puffer wird blockiert, bevor die geänderten Geberwerte eintreffen. Die Kilometerzähler werden jedoch ausgegeben, sie verwenden nur den zuletzt bereits übertragenen Wert.



weil Alle oben genannten Probleme waren darauf zurückzuführen, dass es auf jeden Fall erforderlich ist, die Steuerung beim synchronen Empfang und Senden vom UART-Port zu synchronisieren. Daher hielten wir es für unangemessen, einen erzwungenen Synchronisierer in das diff_drive-Paket einzuführen, und haben daher unser eigenes Steuerungspaket geschrieben.



Es befindet sich hier github.com/Shadowru/hoverboard_driver und wird derzeit aktiv finalisiert:



Das Paket ist in der Startdatei enthalten als:

<node name="hoverboard_driver" pkg="hoverboard_driver" type="node" output="screen">
        <param name="uart" value="{ }"/>
        <param name="baudrate" value="115200"/>
        <param name="wheel_radius" value="0.116"/>
        <param name="base_width”  value="0.43"/>
        <param name="odom_frame”  value="odom"/>
        <param name="base_frame”  value="base_link"/>
    </node>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Der uart-Port selbst muss über die entsprechenden Zugriffsrechte verfügen. Auf einigen Plattformen hat er nicht immer Zugriff für den Benutzer. Als Beispiel: Für den Jetson Nano im Verzeichnis hoverboard_driver / scripts / jetson_nano_serial.sh wird ein Skript angehängt, das die Rechte beim Start des Betriebssystems festlegt.



Das Paket selbst enthält das Lesen des Datenstroms von der Steuerung und das Ausgeben der relevanten Informationen zu den Themen:



hoverboard_driver / hoverboard_msg mit einem Paket wie hoverboard_msg.



Die Nachrichtenstruktur lautet wie folgt:



int16 state1 - interne Informationen zu Rad 1

int16 state2 - interne Informationen zu Rad 2

int16 speed1 - momentane Geschwindigkeit von Rad 1

int16 speed2 - momentane Geschwindigkeit von Rad 2

int16 batVoltage - Batteriespannung

int16 boardTemp - Reglertemperatur

int16 Fehler1 - Rad 1 Fehler

int16 Fehler2 - Rad 2 Fehler

int32 Impulszähler1 - Rad 1

Geberzähler int32 Impulszähler2 - Rad 2 Geberzähler



Zusätzlich erhält das Thema hoverboard_driver / odometry eine typische Meldung nav_msgs :: Odometry Die



Position wird wie folgt berechnet:



Basierend auf den Parametern Radradius - Radius Räder in Metern, base_width - Der Abstand zwischen den Radmitten. Wir berechnen, wie viel sich jedes Rad in der Zeit zwischen der vorherigen und der gelesenen Position bewegt hat.

double curr_wheel_L_ang_pos = getAngularPos((double) feedback.pulseCount1);
double curr_wheel_R_ang_pos = getAngularPos((double) feedback.pulseCount2);

double dtime = (current_time - last_time).toSec();

double delta_L_ang_pos = curr_wheel_L_ang_pos - raw_wheel_L_ang_pos;
double delta_R_ang_pos = -1.0 * (curr_wheel_R_ang_pos - raw_wheel_R_ang_pos);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Dann berechnen wir die Beschleunigung jedes der Räder

wheel_L_ang_vel = delta_L_ang_pos / (dtime);
wheel_R_ang_vel = delta_R_ang_pos / (dtime);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Als nächstes berechnen wir die lineare Beschleunigung des Roboters entlang jeder der Achsen

robot_angular_vel = (((wheel_R_ang_pos - wheel_L_ang_pos) * wheel_radius / base_width) - robot_angular_pos) / dtime;
robot_angular_pos = (wheel_R_ang_pos - wheel_L_ang_pos) * wheel_radius / base_width;

robot_x_vel = ((wheel_L_ang_vel * wheel_radius + robot_angular_vel * (base_width / 2.0)) * cos(robot_angular_pos));
robot_y_vel = ((wheel_L_ang_vel * wheel_radius + robot_angular_vel * (base_width / 2.0)) * sin(robot_angular_pos));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Als Ergebnis wird ein vollständiger Satz erhalten - Linearbeschleunigung, Winkelbeschleunigung und Multiplikation mit der Zeit - die Verschiebung der Position des Roboters.

robot_x_pos = robot_x_pos + robot_x_vel * dtime;
robot_y_pos = robot_y_pos + robot_y_vel * dtime;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Danach wird die Kilometerzähler-Nachricht sowie eine Übersetzung zwischen dem Kilometerzähler-Frame und der Basis gesendet.



Die Steuerung am Eingang wird von einem Paket mit 2 Parametern gesteuert - Geschwindigkeit und Drehung, das Paket wird fast nativ von der Verdrehung übertragen - die Geschwindigkeit wird durch den Umfang geteilt und es werden Windungen erhalten.

double v = vel.linear.x;
double rps = v / rpm_per_meter;
double rpm = rps * 60;
int16_t speed = static_cast(rpm);

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

und die Winkelbeschleunigung wird in Form der Multiplikation mit einem Koeffizienten in die Differenz der Raddrehzahlen umgewandelt, wobei eine weitere Neuberechnung unter Berücksichtigung des Radstandes hinzugefügt wird, dies ist jedoch in der Praxis nur für ausreichend große und schwere Roboter erforderlich.

double w = vel.angular.z;
int16_t steer = static_cast<int>(-1 * w * 30);

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Dadurch konnte mit billigen Bauteilen eine sehr stabile Wagensteuerung erreicht werden.







Wir schaffen Roboter, wie die große Mehrheit von Ihnen. Wir haben unser Hauptprodukt, das wir aktiv entwickeln. Pilot getestet und bereit für die Produktion. Dies ist ein Roboter zum Sammeln von Golfbällen.



Wir entwickeln kundenspezifische Roboter und abgeleitete Lösungen. Manchmal ist dies Arbeit von der technischen Aufgabe und Skizze bis zum fertigen Produkt, manchmal Teil der Arbeit.







In den meisten Fällen benötigt der Roboter Räder, um mit der Außenwelt zu interagieren. Meistens handelt es sich dabei um bürstenlose Motoren, da Geschwindigkeit und Position genau gesteuert werden können.



Bei kleinen Robotern werden häufig Hoverboard-Räder verwendet, was aufgrund der Massenproduktion und des Preises dieser Lösung gerechtfertigt ist. Jeder, der die Preisliste für russische Motoren gesehen hat, versteht die Bedeutung der Massenproduktion.







Bei der Steuerung handelt es sich meistens um Modelle esc, vesc, odrive, BLD-300B oder selbst erstellte Lösungen.



Für den einfachen Einstieg in die Herstellung echter Roboter und die Aufhebung des Gazebo-Fluches benötigen die meisten Entwickler einen Wal für den einfachen Einstieg. Vieles in der realen Welt unterscheidet sich vom Ideal.



Manchmal passieren unvorhersehbare Dinge, Sensoren sind verrauscht, Echtzeit, Pufferüberläufe. In diesem Video das Gerät, das wir zuvor mit einem Schütz und einem entfernten Kilswitch getestet haben.





Wir bieten etwas, das uns helfen würde, rechtzeitig Nerven zu sparen. Dies ist ein Kit für die Montage des Gehäuses (Parallelepiped und Zylinder), zwei Motorräder, eine Batterie, ein Ladegerät und eine blinkende Steuerung, die Kilometerzähler liefert und mit unserem ROS-Paket sofort funktioniert 19.000 reiben. Es ist billiger als das Fräsen, die Kosten für Verbundwerkstoffe, Befestigungselemente und ein gepolstertes Schwenkrad.







Rufen Sie uns an oder beantragen Sie eine Plattform für ROS online . Lassen Sie uns gemeinsam Roboter bauen. Wir werden Ihnen beim Treffen des Roboterbetriebssystems am 5. Dezember



mehr über die Plattform erzählen. Die Anmeldung für die Teilnehmer ist bereits offen.



→ Registrierung für Zuschauer