- LiTime Speicher und Akkus         
Ergebnis 1 bis 5 von 5

Thema: Automationssoftware - Aufbau und Programmieren von Robotern

  1. #1
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.643

    Automationssoftware - Aufbau und Programmieren von Robotern

    Anzeige

    Praxistest und DIY Projekte
    Guten Morgen,

    vielleicht bekomme ich hier im Thread ein paar nützliche Hinweise, wie weit man zum heutigen Zeitpunkt im Thema ist, was sich
    außerhalb meiner jetzigen Sicht bewegt.

    Ich will mich Beispielen anfangen (um das Kopfkino etwas anzukurbeln), die an anderer Stelle schon mal geschrieben wurden: Fischertechnik, Lego

    Im Roboternetz habe ich aus vergangenen Zeiten Ansätze gefunden, wo was mit Hochsprachen unter Windows versucht wurde.
    Allerdings enden alle angefangenen Sachen diesbezüglich immer unvollendet. Mal von der Strukturierung der Sachen abgesehen.

    Heute habe ich einen Thread aus der Vergangenheit gefunden, wie es so ist, schon wieder weggeklickt
    Der geht in die Richtung. Hirarchischer Aufbau und Programmierung, war aber nur angerissen, mit wenigen Beiträgen.

    Immer wieder mal kam dann ROS auf, habe ich kurz gelesen, damit bin ich aber nicht weit genug vorgedrungen, weil mir das
    etwas unbrauchbar für Mikrokontroller erscheint, ich kenne aber auch den Umfang nicht, also was man damit genau alles machen könnte.

    Als ich hier im Forum einstieg, hatte HaWe mir tatkräftig die Arduinos nahe gebracht. Da bin ich noch hängen geblieben, weil die ATmegas
    viel Potential haben, von dem ich überzeugt bin, dass es für die meisten Problemstellungen ausreichend ist. Ich beobachte, dass die meisten Leute,
    wenn sie irgendwo an eine Grenze stoßen, zu einem größeren "System" - Kontroller mit mehr Leistung und mehr Anschlüssen - greifen.
    ATmega2560, Raspberry Pi, ESP32 usw. Man versucht mit einem System alles zu erschlagen.
    Programmiert wird immer beispielsweise in C oder viel auch mit der Arduino IDE.

    Wenn ich Robotik größer betrachte, als nur einen Mikrokontroller einzusetzen, komme ich zwangsläufig zu hirarchischen Systemen.
    Das halte ich auch für die beste Struktur generell. Auch in anderen Bereichen bewähren sich modulare Strukturen. Ich habe aber hier im Roboternetz
    so etwas bis jetzt noch nicht gefunden. Programmierung, Elektronik etc. - sonst alles vorhanden.

    Aufgabenteilung, zerlegen in Teilprobleme, diese miteinander verknüpfen und an der Oberfläche mit einer von außen programmierbaren Struktur versehen:
    halte ich für die sinnvollste Strategie und wird im Industrieroboterbereich sicher so gemacht (auch wenn ich darüber noch nicht all zu viel gelesen habe).
    Software für Industrierobotik ist wohl aber etwas oversized für kleinere Projekte, mal von Preisen abgesehen und von benötigten Platformen, wie Linux bspw.


    Was mache ich zurzeit?
    Selber arbeite ich mich zurzeit voran, einen voll funktionsfähigen Roboter zu bauen. Wobei für mich der Weg das Ziel ist. Also Ende offen. Mich interessieren realisierbare Strukturen.
    Dabei bin ich immer noch von regelbasierten Lernstrukturen überzeugt. Sie liefern eine genaue planbare Reproduktion von "Verhalten". Diese kann man mit anderen
    Sachen aus der KI kombinieren. Also komme ich vom Konzept mit einem Kontroller, zu einem mit mehreren, ich komme zu einem modularen Aufbau, wo man
    am Ende eine Programmierung draufsetzen kann. Die Module werden als geschlossene Einheiten betrachtet, sie werden in sich vollendet und bieten einen Funktionsumfang
    der weiter genutzt werden kann. Dadurch wird ein Kontroller mit einer Firmware versehen, die praktisch dann unverändert bleibt. Die eigentliche Problemlösung, also
    die Programmierung findet dann übergeordnet statt.


    Um es mit der Maus zu sagen:
    Das war: Ungarisch

    Nein! - Brainstorming, mehr oder weniger und zur Diskussion freigegeben




    Freundlichen Gruß
    Moppi

  2. #2
    HaWe
    Gast
    Wenn man hinreichend leistungsstarke Prozessorboards hat, reicht durchaus ein einziges Board.
    Und letztlich muss ja 1 die Zügel in der Hand haben, um die Daten aus den untergeordneten "Modulen" zu sichten, zu ordnen und auszuwerten, und das sollte dann eigentlich schon auch eines der leitungsfähigsten sein (Takt, Speicher, Multithreading-fähig).
    Man kann ntl jederzeit überall mit weiteren Boards oder ICs über verschiedenste Bussysteme (UART, i2c, SPI, CAN) kommunizieren:
    aber z.B. einem Programm-"Modul" in einem pthread oder subsumption-Behaviour ist es egal, ob es die Sensordaten direkt von onboard-Sensoren oder von vorprogrammierten remote-Clients erhält.

    Aber je mehr Clients (Multi-Boards), mit denen kommuniziert werden muss, desto komplizierter wird es im Vergleich zum Single-Board.

    Ich sehe für modulare Architekturen 3 praktikable Wege, Multithreading ist dabei essentiell ("Modul" verstanden als funktionelle Einheit, z.B. ein Sensor-Modul, ein Kalkulationsmodul oder ein Motorsteuerungsmodul):

    a) Subsumption-Architektur: hier verdrängen Funktionen ("Behaviours") mit hoher Prio solche mit hierarchisch niedriger Prio (googeln!). Prinzipiell beruht es auf (zumindest kooperativem) Multithreading.
    Vorteile: es können jederzeit neue Sensor- oder Behaviour-"Module" eingefügt werden, und es läuft auch auf sehr einfachen, langsamen Systemen wie Interpreter-Frameworks (zB. NQC oder Java etc. auf Lego Mindstorms RCX oder NXT). Auch auf dem Arduino Due mit dem kooperativen Scheduler MT geht das natürlich.
    Nachteil: läuft auf langsamen Systemen ein wenig holprig und ist so nicht echtzeitfähig.
    Beispiel: https://github.com/dsyleixa/Mindstor...enmaeher-6.nqc
    https://www.youtube.com/watch?v=lNLPejeS-_Y
    http://www.youtube.com/watch?v=z7mqnaU_9A8
    hier sieht man, welche Behaviours (z.B. "Ausweichen" oder "Wenden") welche anderen (z.B."Cruise" oder "Ausweichen") hierarchisch verdrängen:
    Code:
    int MotorCommand;
    task arbitrate ()
    {         // Hier werden die Behaviour-Prioritäten festgelegt!
        while(true) {
           if (vCruise != CommNone)       MotorCommand = vCruise;    // niedrigste Prio
           if (vAusweichen != CommNone)   MotorCommand = vAusweichen;
           if (vWenden != CommNone)       MotorCommand = vWenden;
           if (vRueckAbbr != CommNone)    MotorCommand = vRueckAbbr;
           if (vNotStop != CommNone)      MotorCommand = vNotStop;   // höchste Prio
           MotorControl ();     // MotorCommand erhält seinen Wert Event-gesteuert vom entsprechenden Task
       }                        // MotorControl übernimmt dann die einfachsten Motorbefehle
    }
    b) preemptives (!) Multithreading auf schnellen single- (SAMD51, Rpi Zero) - oder multicores (ESP32, Rpi ab 2B), mit pthreads, thread prios und mutexes.
    Wie bei der Subsumption mit kooperativem MT können dann aus den parallel ermittelten Daten optional die hierarchisch organisierten Verhaltensweisen generiert werden, wieder in einer unabhängig laufenden pthread Funktion. Anderes als bei kooperativem MT können jetzt einzelne threads keine anderen blockieren, dadurch kann das Programm in Echtzeit reagieren.
    Es können auch hier jederzeit neue "Module" in Form zusätzlicher pthreads hinzugefügt werden.
    Vorteile: schnell, parallelisierbar, priorisierbar und skalierbar, kompatibel auch zu C++ GUI Frameworks wie z.B. qt oder openCV.

    c) modulare Systeme z.B. wie ROS auf rechenstarken Computern (Windows-PC, Rpi 3B+, 4). Hier übernimmt das ROS die Verwaltung und das threading aller Module.
    Vorteile: viele fertige Module verfügbar.
    Nachteil: IMO großer Installations- und Programmier-Overhead.
    Geändert von HaWe (20.06.2020 um 16:42 Uhr) Grund: noch'n typo entdeckt

  3. #3
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.04.2015
    Beiträge
    865
    Keine Ahnung, wie andere das machen.
    Ich habe mir einen kleinen 3€-ATXMega mit 5xUART und 2xI2C genommen und ein serielles HC-06 BT-Modul (kleinster gemeinsamer Nenner für PC, Tablet, Smartphone, Raspberry) draufgebaut.
    Odometrie, Motorregelung und Posenberechnung laufen direkt auf dem ATXMega. Der Rest der Daten (Power, Sensoren) kommt von anderen Platinen oder Bausteinen über UART oder I2C und wird entweder direkt ans BT-Modul weitergereicht oder z.B. mit der aktuellen Pose verknüpft und dann ausgegeben.

    Letztlich braucht es dann auf dem Rechner nur noch eine Bluetoothschnittstelle und eine an die Firmware angepasste API. Welcher Rechner früher oder später dann auf dem Vehikel selber landet, so dass der Roboter auch ohne externe Datenanbindung agieren kann, ist schlussendlich nur noch eine Frage des Powermanagement. Ein RPI ZeroW nimmt headless etwa 250mA, ein BPI M2 Zero mit 4 Kernen, aber noch im gleichen Formfaktor, liegt bei 400mA (das sind bei mir schon 40% des Gesamtverbrauches).
    Alternativ könnte man sich auch mit einem Teensy herumquälen, wenn man aber auf den Einsatz von Kamera, Bildschirmein/-ausgabe (Remotedesktop über Wifi) und Web-Interface spekuliert, lohnt sich wohl der Einsatz von 50% teurerer Hardware mit nominal weniger Ressourcen nicht wirklich.
    Geändert von Holomino (21.06.2020 um 17:33 Uhr) Grund: Koma-Kommas

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.643
    Ich hatte nun eine lange Pause, um drüber nachzudenken. Dabei habe ich meine alten Lösungen überdacht und geschaut, ob ich ähnliche Strukturen auch gerade für ATmegas mit wenig Speicher und geringer Geschwindigkeit (bis 20MHz) umsetzen kann. Angefangen habe ich bereits, allerdings nur als Gerüst. Die Idee ist eine Klasse, die das abhandeln soll. Die Programmsteuerung soll dann über eine Art Microcode geschehen, der zur Laufzeit von einem schnellen Host verteilt wird, was bei mir jetzt aktuell ein ESP-12E wäre. Der hätte auch ordentlich Speicher, um jede Menge Microcode-Pakete zu speichern, evtl. auch auf SD-Karte.
    Insofern das brauchbar funktioniert, ist der Vorteil, dass meine ATmegas und auch der ESP nur noch per Arduino-IDE programmiert werden müssen, wenn sich die meine Firmware ändert. Die eigentliche Programmierung, der Datenauswertung und daraus folgende Aktionen, könnten per WLAN im laufenden Betrieb erfolgen. Austauschbarer Code zur Laufzeit gäbe jede Menge Flexibilität.
    Allerdings glaube ich, dass die im System verfügbare Datenübertragungsrate zu gering sein wird, um was Brauchbares zu realisieren. Aber das muss ich erst einmal sehen.

    MfG

  5. #5
    Neuer Benutzer Öfters hier
    Registriert seit
    17.09.2020
    Beiträge
    11
    Danke HaWe für deine Lösung!

Ähnliche Themen

  1. FPGAs in Robotern
    Von technick im Forum VHDL/FPGA Programmierung
    Antworten: 0
    Letzter Beitrag: 14.02.2018, 20:00
  2. CAD Planung von Robotern
    Von skullmonkee im Forum Konstruktion/CAD/3D-Druck/Sketchup und Platinenlayout Eagle & Fritzing u.a.
    Antworten: 12
    Letzter Beitrag: 20.01.2018, 13:41
  3. Begriffe von Robotern
    Von senmeis im Forum Allgemeines zum Thema Roboter / Modellbau
    Antworten: 3
    Letzter Beitrag: 30.08.2016, 21:21
  4. modularer Aufbau der Steuerung von Robotern
    Von lemmings im Forum Allgemeines zum Thema Roboter / Modellbau
    Antworten: 23
    Letzter Beitrag: 29.06.2009, 21:22
  5. Laufzeiten von Robotern
    Von HannoHupmann im Forum Offtopic und Community Tratsch
    Antworten: 11
    Letzter Beitrag: 19.07.2006, 00:38

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test