Steuerungsprogramm für alle möglichen Roboter

[ACU]

Hallo!
Da ich zur Zeit für meinen eigenen Roboter ein Steuerungsprogramm schreibe (in Delphi 5), wollte ich fragen, was ihr davon haltet, wenn man sowas wie ein Standard Programm entwickelt.
Da viele nicht die nötige Ahnung von der PC Programmierung haben, wäre das doch eine gute Sache oder?
Als größtes Problem sehe ich, dass alle Roboter unterschiedlich sind.
Man müsste das Programm deshalb recht flexibel gestalten, so dass zum Beispiel die Oberfläche an die eigenen Bedürfnisse angepasst werden kann.
Eine gute Idee wäre, wenn man ein Button hat, wo man draufklickt, anschließend erscheint ein Dialogfemster, in dem man auswählen kann, in was für einer Darstellungsmöglichkeit dargestellt wird (Diaramm, Balken, analoges Instrument).

Als erstes müsste man eine Art Standard Protokoll festlegen, dass die Roboter sprechen. Bei diesem Punkt bräuchte ich sicherlich einige Hilfe, da ich bei diesen Dingen noch nicht so die große Erfahrung habe.

Die Kommunikation würde über die serielle Schnittstelle stattfinden.
Die Schnittstellenparameter kann man selber auswählen.
Bei Bedarf kann man statt Kabel ja auch Funkmodule (RNFunk, Bluetooth) benutzen.

Wäre ein ganz schönes Mammutprojekt, aber was haltet ihr davon?


MfG ACU

[Weja]

Hi ACU,
die Sache hört sich interessant an. Ich stelle mir eine Art Baukasten vor, mit dem ich Buttons beschriften und positionieren kann. Bei der Aktivierung wird dann eine frei definierbare Zeichenkette abgeschickt. Es ist dann Sache die Roboters diese richtig zu interpretieren, und den ensprechenden Befehl auszuführen.
In der umgekehrten Richtung tauchen schon mehr Probleme auf. Der Roboter liefert Ergebnisse als Zahl, Zeichenkette, Bitmap oder sonstwas.
Dein Programm muß das alles berücksichtigen, oder eine Möglichkeit haben Plugins einzubinden die die Darstellung ermögklichen.
Gruß
Weja

[vish]

Hallo!

Finde die Idee große Klasse! Hier ein paar Funktionen, die ich begrüßen würde:

• * RS232 Terminal mit Baudratenauswahl und Stoppbits usw
  * Anzeige von Videosignalen (Soll ja Bots mit Videokamera geben die das ganze auch noch per Funk übertragen)
  * Ausgabe von RC5 Codes (Entsprechendes Modul an der Seriellen Schnittstelle) zur Steuerung des Bots
  * Programmierung des Bots (.hex Datei auswählen und dann auf den Bot übertragen)
  * Fusebits setzen
  * Unterstützung des Parallelport zu I²C Bus Adapter von Robotikhardware.de

So, mehr fällt mir gerad nicht ein.
Was das Protokoll angeht: Du baust ein Protokoll und diejenigen, die dein Programm brauchen richten sich danach und die anderen eben nicht. So hast du am wenigsten Probleme und die Leute, die dein Programm nutzen wollen und meist sowieso noch am planen sind, können sich einfach danach richten.

Grüße,
Jonas

[ACU]

@Weja
Ja so ungefähr habe ich mir das vorgestellt.
Mit Input soll das auch so funktionieren.
Da macht man in der Art sowas wie:
Quelle von Label 3 = $Spannung()
Auf dem Label3 würde er dann den Inhalt der Klammern anzeigen.
Das sollte also kein Problem sein.

Allerdings würde ich schon ein paar Grundlegende Dinge vorprogrammieren. Zum Beispiel Motorsteuerung.

@vish
Punkt 1 ist kein Problem

Punkt 2 , da müssten die Videosignale ja digital kommen
(von einer CMU cam2 zum Beispiel, oder meinst du von TV Karte)

Punkt 3 Sollte nicht das Problem sein, wenn ihr mir sagt, was genau an die Serielle Schnittstelle übertragen werden soll

Punkt 4 + Punkt 5 das selbe wie bei Punkt 3
Punkt 6 dürfte auch kein Problem sein, wenn ich das Protokoll des Adapters kenne.

Das mit dem Protokoll will ich wie gesagt nicht so einfach festlegen.
Ich werde die Möglichkeit offen lassen das Protokoll zu ändern.
Aber das Standardprotokoll sollte nicht völliger Schwachsinn sein, deshalb bin ich auf ein bischen Hilfe angewiesen.

Vielleicht können wir mal zusammentragen, was das Programm leisten soll.
Mir fällt ein:

Motorsteuerung (Art Fernsteuerung)
Visualisierung von Meßwerten (Spannung, Strom)
Entfernungssensor Visualisierung (so wie SlyD es gemacht hat:

KLICK Ich meine dieses "Radar" unten links.

Bei Delphi kann man relativ einfach so eine Pascal Skriptsprache einbauen.
Da könnte man dann auch bedingt Programmieren.
Sowas wie.

if (Sensorlinksvorne=29)
then
MessageBox("HALLO","Entfernung zu klein")


MfG ACU

[vish]

Guten morgen!

Zu Punkt 2: Am besten beides! Ist aber glaube ich verdammt aufwendig und wohl eher als Sekundärziel anzusehen, da es bisher nicht viele gibt die eine Kamera auf dem Bot haben.

Zu Punkt 3: Ich hatte es so gedacht, dass Adresse und Befehl per Serielle Schnittstelle an einen angeschlossenen (kleinen) Mikrocontroller gesendet wird, der die Daten dann mittels IR-LED RC5 kodiert ausgibt.

Zu Punkt 4 & 5: Da dachte ich eher an die parallele Schnittstelle, aber was genau da übertragen werden muss und in welchem zeitlichem Timing, weiß ich nicht.

Zu Punkt 6: Schau mal hier

Grüße,
Jonas

[pebisoft]

hallo ich mache so etwas mit dem freewareprogramm "bcx-to-c" und dem grafikzusatz "bcxdx".
an dem robby schicke ich befehle (funkmodul) über ein button oder text, der robby setzt diese dann um in einer arbeit, die er ausführen soll.
ich lasse mir sämtliche daten des robby die er ermttielt zurücksenden zum pc.
mfg pebisoft

[ACU]

Hallo pebisoft.
Das klingt natürlich auch nicht schlecht.
Aber kann dieses Programm alle angesprochenen Anforderung (Visualisierung mit Diagrammen, Radar, Videobild) erfüllen?
Mach doch bitte mal einen Screenshot, ich möchte es mir nicht extra runterladen.


MfG ACU

[PicNick]

@ACU: sicher ein sinnvolles Projekt. Schau dir mal das OSI -Schichtenmodell der Kommunikation an und übersetze es dir für deine Zwecke. Das klingt hochtheoretisch, aber schließlich solltest du ein Konzept (Design) auf die Beine stellen, daß auch zukünftigen Entwicklungen der HW /SW gewachsen ist.
Ist leider ein harter Job, denn jeder Standard ist auch eine Restriktion, und du wirst mit einigem Widerspruch (und faulen Eiern) rechnen müssen.
Wenn dir an dem Schichten-Trara irgendwas unklar ist, frag' nur.
Tip: versuch dich so spät wie möglich in Details zu verstricken.

[NumberFive]

ACU befor du so viel arbeit machst

sieh dir mal die links in mein fussleiste an

Gruß

[ACU]

@Pic Nick
Ja das OSI Schichtenmodell kommt mir bekannt vor, mußte ich mal lernnen *grummel*.
Sowas in der Art habe ich mir auch gedacht.
Bei java ist ja die Grundidee, dass Java auf verschiedenen Systemen lauffähig.
Möglich wird das dadurch, dass ein speziell für die Plattform entwickelter Interpreter (der die Eigenheiten des Systems "kennt") den Code verarbeitetn. Dadurch wird es möglich, dass der Code vom Bladeserver bis zum Handy überall läuft.
So in der Art wollte ich es bei meinem Programm auch machen.
Das heißt: der Computer schickt nur eine Nachricht zum Beipspiel:
fahre nach vorne. Der Roboter muß sich dann selber darum kümmern, wie er nach vorne kommt. Das kann durch meine, Räder, Ketten etc. passieren.
Das ist dem Programm also egal.
Das Betriebsystems des Roboters hat demzufolge die Aufgabe den Roboter auf ein Niveau mit der Software auf dem PC zu bringen.
Ich werde besonders darauf achten den Roboterbastler nicht zu sehr einzuschränken und viele individuelle Anpassungen zu ermöglichen.


@NumberFive
Sieht auch ganz nett aus, aber da muß man ja einen Controller auf dem Roboter haben, der Java "versteht".
Bei der von mir verwendeten CC2 ist das nicht der Fall.
Außerdem ist Java nicht Jedermanns Sache.


MfG ACU