Bausatz für Hex-Bots

Soeben auf der Heise-Seite gelesen:

http://www.heise.de/newsticker/mel…er-1632615.html

-------------------------------------------------------------------

Quelle: http://www.heise.de / 05.07.2012
Autor: bsc => Ben Schwan
Titel: Startkapital für sechsbeinigen Open-Source-Roboter

Das US-Unternehmen ArcBotics hat einen kostengünstigen sechsbeinigen Roboter entwickelt und lässt die Serienproduktion nun von Nutzern der Crowd-Sourcing-Plattform Kickstarter finanzieren. Das Gerät namens Hexy liegt preislich bei einem Zehntel dessen, was solche Geräte bislang kosteten, berichtet Technology Review in seiner Online-Ausgabe.

Sofort einsatzbereit ist Hexy für 400 Dollar zu haben. Als Bausatz, den auch mittelmäßig handwerklich begabte Menschen zusammenschrauben können, werden 220 Dollar fällig. Neben der günstigen Hardware, die zu großen Teilen aus Acryl gefertigt ist, haben die Entwickler zudem die Software offengelegt: So lässt sich das Gerät auch von Einsteigern programmieren. Dazu reicht eine Textdatei mit einfachen Kommandos wie "Rotiere um 40 Grad nach rechts".

Über 850 Personen steckten bei Kickstarter fast 170.000 US-Dollar in das Vorhaben. Das war mehr als das Zwölffache der eigentlich erforderlichen Summe, die ArcBotics brauchte, um ausreichend Bauteile zu erwerben, die der Firma die Serienproduktion ermöglichen sollten. Nun, da das Geld zusammen ist, geht die Produktion los. ArcBotics wird allerdings noch eine ganze Weile brauchen, bis die Geräte lieferbereit sind – aktuell steht September 2012 als Verkaufsstart im Raum, wobei Teilnehmer des Kickstarter-Projekts bevorzugt werden.

Ist der erste Ansturm erst einmal bewältigt, wollen sich ArcBotics-Gründer Joseph Schlesinger und sein Team weiter der Hexy-Software widmen. So könnte man die Programmierung per Textdatei vereinfachen, indem die Oberfläche MiniBloq verwendet wird, bei der man Kommandos einfach nur zusammenklicken kann. Angedacht ist außerdem eine direkte Fernsteuerung von Hexy über ein Smartphone. Geplant sind Versionen für Android- und iOS-Geräte.

Zitat

"Das ist mir zu einfach!" ist eines der größten Elitärprobleme in Fachkreisen.

Ich denke, das stimmt so nicht ganz. Bei der Programmierung der Fahrtregler bin ich stellenweise auf "Timing-Probleme" gestossen. Heißt: Das Programm läuft zu langsam durch alle Stationen, um dann termingerecht bei irgendeinem Programmpunkt anzukommen. So ein Befehl "Drehe um 40° links, aber nur, wenn der linke Sensor kein Hindernis detektiert" dauert sehr lange zum Interpretieren im Prozessor. Darum wäre mir ein "kurz und knackiger" Befehlssatz auch viel lieber.

Diese Technik mit "Blöcken" statt einer sauberen Programmiersprache gab's übrigens schon zu meiner Praktikantenzeit. Da mußte man dann mit Drag&Drop aus einem Baukasten so Blöcke herüberziehen. Jeder Block stellte einen Basic-Befehl dar. Damit wurde so etwas ähnliches wie ein Flussdiagramm aufgebaut. Aber mit jedem Detail drin. Also total umfangreich in der Darstellung. Ein simples Progrämmchen, das ich in Basic in ein paar Zeilen hintippe, ging da über mehrere Seiten. Wobei das Meißte dann "Luft" und "Rahmen" war. Weil man ständig die Seiten umschalten musste, hatte man absolut keinen Überblick mehr, wo denn jetzt eine Abfrage und ihre Bedingungen anfangen bzw. enden, etc.

Was ich sagen will: Auch ich finde diese Syntax mit einer verbal umschriebenen Kommunikation etwas befremdlich und bin (ehrlich gesagt) auch etwas voreingenommen dagegen.
Aber wie heißts derzeit von unserer Bundeskanzlerin immer: Der Markt wird es schon richten.

Marten, ich kann Deine Sichtweise sehr gut verstehen.
Meine Erfahrung ist aber, dass bei "aufwändigerem Kommandosatz" die Reaktionszeit steigt. Heißt: Du schickst ein "langes" Kommando in Form einer Ziechenkette los. Das kostet Zeit, bis dieser lange String übertragen ist. Dann setzt sich der Prozessor in Bewegung und vergleicht das empfangene Kommando mit all den gespeicherten vorformulierten Floskeln. Irgenwann landet er einen Treffer und gibt dann das Kommando an seinen Taks-Skeduler. Und dann setzt sich die Möhre endlich in Bewegung.

Wie Du vielleicht weist, habe ich bei meinen Fahrtregler für die Schaltausgänge eine "Sicherung" gegen verstümmelte Funktelegramme eingebaut. Jedes Kommando muss viermal hintereinander empfangen werden, bis es als gültig eingestuft wird. Das sind, bei 20ms pro Telegrammsequenz für alle Kanäle, also 80ms. Sogar diese knappe Zehntelsekunde stört mich schon manchmal, wenn ich die Waffe auslöse und da ist eine Verzögerung mit drin.

Ein separater Prozessor (diese Technik läuft in meinem Job unter der Bezeichnung als "Zweiprozessorlösung") wird an der Geschwindikeit der Datenkommunikation wenig bringen. Was schneller gehen wird ist die Auswertung, denn die ganzen vorgegebenen Floskeln können mit einem Schluck durchgesehen werden. Bei der Standardlösung (Einprozessorlösung) muss das Durchsuchen immer mal unterbrochen werden, weil so nebenbei auch noch andere Aufgaben erledigt werden müssen.
Nachteil der Zweiprozessorlösung: Auch im Hauptprozessor muss ein separates Datenprotokoll abgearbeitet werden, um vom zweiten Prozessor die Infos abzuklappern. Geht aber wesentlich schneller, als wenn er sich auch noch als Dolmetscher abschinden muss.

Ich glaube, da reden wir jetzt an zwei verschiedenen Baustellen aneinander vorbei.

Du meinst die "Programmiersprache". Ich meine die Datenkommunikation, also die Befehle an den Bot. Das sind zwei verschiedene Möglichkeiten, einen Bot bzw. die Software zu behindern, zu beschleunigen oder - wie in Deinem Fall - lesbar zu machen.

Wobei auch mit einer (wie in Deinem Beispiel) umkompilierten "einfachen" Programmiersprache in die eigentliche Maschinensprache auch hier dann ein langes Datenkommando wirksam sein kann. Oder umgekehrt: Direkt in Maschinensprache programmiert, also ein recht flotter Programmablauf. Aber der wird durch das lange Datenkommando heruntergebremst. Gegenbeispiel: Mit dem von Dir beschriebenen Compiler wird über eine grafiknahe Programmiersprache der Code erzeugt. Der ist dann zwangsweise nicht ganz so "optimiert", die Arbeitsschleife läuft also länger durch. Da hilft dann auch ein zackiges Kommando "R-40" (anstatt "Rotiere um 40Grad entgegen dem Uhrzeigersinn") auch nicht mehr viel.

Verstehst Du was ich meine oder soll ich das noch etwas erläutern?