NetBot Projekt

Hallo liebe Roboter Gemeinde,

ich möchte Euch unser Roboter Projekt vorstellen, dass in den letzten 3 Monaten im Rahmen eines Schulprojekts entstanden ist.
Es handelt sich um ein modular aufgebautes Windows Programm in C# zur Simulation und Steuerung von Robotern auf Basis eines ATmega8 Mikrocontroller.
Die Firmware für den ATmega8 ist ebenfalls im Rahmen des Projektes entstanden.
Zusätzlich haben wir noch ein Controllerboard und Motorboard entwickelt.

Das Windows Programm hat außerdem die 3D Engine Irrlicht eingebunden zur Visualisierung und Simulation. Es basiert auf einer modularen und gut durchdachten Klassenbibliothek. (dll)

Das Windows Setup, die Firmware und Dokumentationen liegen bereits als Download bei Sourceforge. http://sourceforge.net/projects/netbotproject/

Wir werden in den nächsten Tagen den kompletten Sourcecode veröffentlichen, sowie die Schaltungspläne für die beiden Boards.

Neben der Software und Hardware haben wir auch ein Protokoll entwickelt, dass insgesamt 14 Befehle implementiert, sowie ein Datenpaket für die Kommunikation zwischen Mikrocontroller und externem Gerät definiert. Dadurch versuchen wir einen Standard zu schaffen, so dass in Zukunft auch Firmware für andere Mikrocontroller folgen sollen, sowie alternative Steuerungssoftware für z.B. Android, IPhone oder in Java.

Diese Befehle decken alle Grundfunktionen eines Mikrocontrollers ab.
Pins als Input/Output setzen, Pins LOW/HIGH setzen, Digitale/Analoge Pins auslesen, PWM, Sound, Servos, Srf05 Ultraschall Modul lesen usw.

Für die Kommunikation haben wir aus Performancegründen ein bytebasiertes Datenpaket benutzt mit Bytestuffing.
http://www.rn-wissen.de/index.php/Ne...ller/PC_Praxis

In der Firmware wurde eine Interrupt getriebene UART Verbindung mit FIFO genutzt.
http://www.rn-wissen.de/index.php/UART_mit_avr-gcc
http://www.rn-wissen.de/index.php/FIFO_mit_avr-gcc

Vielleicht ist dieses Projekt für den einen oder anderen interessant und hilfreich und wir hoffen auch, daß sich eine kleine Community bildet und uns bei der Weiterentwicklung hilft.

Wir werden bald auch eine Internetseite für dieses Projekt aufsetzen mit Codebeispielen und Codereferenz. Bis dahin könnt Ihr die Handbücher lesen und euch einen noch besseren Eindruck von der Software machen.
http://sourceforge.net/projects/netb...ect%20Manuals/

Anhang 18559


Viele Grüße

redreggae

Schön, dass hier mal mit C# entwickelt wurde.
Habe die beiden Handbücher gelesen und das Projekt sieht sehr vielversprechend aus. Die Beschreibung der bestehenden Roboterbetriebssysteme (MSRDS, Player etc. ) ist knapp und anschaulich. Vielleicht hätte man noch ROS betrachten können, das mittlerweile auch AVR-"Treiber" bietet. Aber ROS hat die gleiche "steile Lernkurve", die Ihr bei MSRDS richtig beschrieben habt.
Auf meinem Roboter benutze ich zwar keine ATmegas, aber ich erhoffe mir von eurem Sourcecode in C# doch einige Anregungen und Hilfestellungen, da ich nur ein sehr mäßiger C#-Programmierer bin. Irgendwie bin ich halt in der VB6-Welt verblieben.

Es freut sich auf Eure Internetseite

Günter

Gratulation erstmal zu diesem Projekt!
Sehr schön, dass ihr auch mit C# gearbeitet habt. .NET wird immer so stiefmütterlich behandelt, da freut mich das besonders.

Ich habe mir mal euer Entwicklerhandbuch zu Gemüte geführt. Allerdings hab ich mich auf das Protokoll und die Lowlevel-Sachen beschränkt.

Dazu habe ich auch ein paar Anmerkungen:

Protokoll

Ihr schreibt, dass das Protokoll 256 Befehle unterstützt. Das klingt erstmal sehr viel, mit der Zeit wird das aber ganz schön knapp werden.
Es ist bei Protokollen immer gut, Platz für Erweiterungen zu lassen.
Mein Vorschlag: 127 statt 256 Befehle. Warum? So bleibt ein Bit für zukünftige Erweiterungen reserviert. Dafür kann man z.B. das MSB verwenden.
Ist es null, bedeutet es, dass es sich um einen 7-Bit Befehl handelt. Ist es eins, würde ein 15-Bit Befehl folgen.

Ihr habt eine "senderID", warum habt ihr keine Empfänger ID vorgesehen? So könnten mehrere Bots über einen Kanal kontrolliert werden.

Ich habe in der Dokumentation gar keine "Management" Befehle gefunden. Ein paar Beispiele für sehr nützliche Befehle:
-Auslesen einer Device Id / eines Device Namens => Identifizierung der Bots
-Abfragen der Firmware-Version => Kompatibilitätserkennung, Erkennung unterstützter Befehle
-Status Read => Unter Umständen ist es sinnvoll, den Status bestimmter Komponenten auslesen zu können (Ist der Pin als Ausgang gesetzt?, Läuft Timer x? etc)

Man kann das Protokoll schlank und viel flexibler gestalten, wenn man zusätzlich noch einige "generische" Befehle einbaut. Ich meine damit sowas wie
I²C-Read/I²C-Send, SPI-Read/SPI-Send. So kann ohne eine Protokollerweiterung eine große Menge an verschiedenster Hardware angesprochen werden.


Klassen und Methoden

Ich finde eure Eventnamen etwas unglücklich gewählt. Ihr bezeichnet eure Events mit OnIrgendwas. In der .NET-Welt werden damit üblicherweise die Methoden bezeichnet, die die entsprechenden Events auslösen.
Beispiel: Event: DataReceived => Trigger: OnDataReceived

Es ist also genau umgekehrt, was bei den Anwendern des Frameworks für Verwirrung sorgen dürfte.

Mir ist noch die Klasse "Micro" aufgefallen. Der Name ist ziemlich irreführend. Ich dachte zuerst an ein Mikrofon, als ich die Überschrift gesehen habe.
uController, MCU oder einfach MicroController wären aussagekräftiger.

Die Dokumentation eurer Klassenbibliothek habe ich nur überflogen. Mich würde die Kapselung der Klassen interessieren.

Mit wie vielen Klassen muss sich der Entwickler beschäftigen? Muss er alle Klassen nutzen oder kann er sich einfach
ein "Roboter-Objekt" erstellen und dieses mit Attributen versehen?


Ich wünsche euch viel Spaß und vor allem viel Erfolg bei der Weiterentwicklung und der Nutzung eures Frameworks!

Mfg

Danke erstmal für Eure Kommentare und das Interesse.
Nun zu Dir lokirobotics:

Protokoll:

Das mit dem MSB ist eine gute Idee. Das sollten wir in späteren Version implementieren.

Auch eine EmpfängerID einzuführen, wäre eine Überlegung. Im Moment liegt aber die Priorität darin, einen Roboter ordentlich Steuern und Simulieren
zu können. Natürlich ist eine Multirobot Umgebung interessant und da soll die Reise auch irgendwann mal hingehen.

Das ist richtig, dass es im Moment noch keine "Management" Befehle gibt. Da haben wir natürlich auch schon dran gedacht,
aber in dem kurzen Zeitraum konnten wir nur grundlegende Befehle implementieren, die wir brauchten, um unseren Roboter
erfolgreich präsentieren zu können. (Vielleicht hat der eine oder andere gemerkt, dass die Befehle sehr stark den Arduino Befehlen ähneln.)

Der nächste Befehl sollte ein Handshake Befehl werden zwischen externem Gerät und Mikrocontroller. Dafür war die BefehlsID 255 vorgesehen.
(Durch das MSB wird es dann wahrscheinlich die 127)
Der Mikrocontroller soll dabei seine Firmware Version senden, so dass das externe Gerät erkennen kann, welche Befehle überhaupt existieren.

Über I2C Befehle haben wir auch schon nachgedacht, nur macht es das Ganze auf der C# Seite doch recht kompliziert. Man muss ja dann wissen,
welche Mikrocontroller noch am Bus hängen und über welche Firmware diese verfügen etc.

C#

Die Eventnamen sollten wir vielleicht noch ändern, damit es keine Verwirrung gibt.
Zum "Micro" : Programmierer sind ein wenig faul, deshalb haben wir so kurze Namen wie möglich verwendet ;)
Aber wie Du richtig erkannt hast, repräsentiert das Micro Object einen Mikrocontroller.

Um einen Mikrocontroller steuern zu können braucht man im Moment mindestens 3 Objekte. (Robot, Micro, Connection)

Beispiel:

Code:

---


Robot robot = new Robot();

ConnectionSerial connection = new ConnectionSerial();
connection.Port = "COMX";

robot.Connection = connection; // Dem Roboter die Verbindung zuweisen

MicroAtmega8 micro = new MicroAtmega8();
robot.Micro = micro; // Dem Roboter den Mikro zuweisen

connection.Connect(); // Bei erfolgreicher Verbindung werden alle weiteren Objekte initialisiert (Stream, Command)

// Jetzt kann man Befehle an den Mikro senden, zum Beispiel PinMode
robot.Command.PinMode(0, 4, Constants.INPUT); // SenderId, PinNr, Input/Output (0/1)
robot.Command.OnPinMode += new EventHandler<EventArgs<PinModeData>>(Command_OnPinMode); // Für Antwort registrieren

---

Wir sind grad dabei, den Sourcecode mit den Lizenzen zu versehen und alle kleinen Fehler auszumerzen. Er wird sehr bald bei SourceForge
zur Verfügung stehen.

Viele Grüße

redreggae

Das mit den faulen Programmierern kann ich nicht bestätigen.
Solch eine Faulheit bei der Benamsung kann/wird einem ganz dolle auf die Füße fallen. Spätestens, wenn die Programme umfangreicher werden.

Aber wenn ihr schon so faul seid, warum benutzt ihr dann explizite, statt implizite Deklaration?

Code:

---

var robot = new Robot();

---

Ist doch viel kürzer!

Wäre sogar noch kürzer:

Code:

---

var robot = new Robot
{
  Connection = new Connection
  {
      Port = "COMX"
  },
  Micro = new MicroAtmega8(),
};
robot.Connection.Connect

---

Eleganter wäre es natürlich, alles variable im Konstruktor zu übergeben und der Klasse die Erstellung der Objekte zu überlassen (Fassade Muster).

Edit: Klar, macht Sinn, unter Termindruck erstmal nur die wichtigsten Sachen zu machen ;-)

Das mit der impliziten Deklaration war mir ehrlich gesagt noch nicht geläufig. Aber dazu habe ich grad etwas hier gelesen.
http://msdn.microsoft.com/de-de/libr...=vs.80%29.aspx

Zitat:

---

Die Anwendung ist jedoch effizienter, wenn Sie alle Variablen explizit deklarieren und einen bestimmten Datentyp für sie festlegen. Dadurch verringern Sie die Wahrscheinlichkeit des Auftretens von Fehlern aufgrund von Namenskonflikten sowie Rechtschreibfehler. Darüber hinaus kann der Compiler potenzielle Laufzeitfehler, z. B. das Zuweisen von Integer zu Short feststellen

---

Die Sache mit dem Konstruktor ist nicht schlecht, nur finde ich Setter flexibler, weil man erstmal auf nichts angewiesen ist beim Initialisieren und auch im Nachhinein einfacher Veränderungen durchführen kann.

Aber genau aus diesem Grund veröffentlichen wir das Projekt als OpenSource, damit sich andere beteiligen können und Ihre Ideen mit einfließen können.
Wir lernen erst seit 2 Jahren C# in der Schule und haben mit Sicherheit noch nicht ausgelernt.

Ich hoffe, Du beteiligst Dich an der Programmierung, wenn wir das Ganze in SVN hochgeladen haben, denn Du scheinst ja ziemlich fit zu sein.

Viele Grüße

redreggae

Sry, mein Fehler. Ich meinte implizite Typisierung (it).
Implizite Deklaration gibt's ja nur bei VB und PHP und Konsorten. Das hasse ich wie die Pest.
Das Tolle bei der it ist ja, dass der Compiler alles weiterhin alle Fehler erkennen kann. Man muss den Typ halt immer nur noch einmal angeben.

Auf den leeren Konstruktor (den sollte man sowieso immer haben) und die Getter und Setter musst du ja nicht verzichten.
Du kannst den Konstruktor überladen und die Variablen dann von dort aus füllen ;-)

Ich würd jetzt mal ganz mutig behaupten, dass ich fit bin in C#, ich verdien nämlich mein Geld damit ;-)

Ich fürchte nur, ich werde in naher Zukunft keine Zeit finden, mich zu beteiligen. Hab grad selber ziemlich viele Projekte am laufen und neben der Arbeit bleibt immer nich so viel Zeit. Aber mal schauen.

Ja cool, wieder was dazu gelernt ;)

Eine Überladung des Konstruktors könnte man natürlich noch einfügen. Aber da das Initialisieren der Objekte eh von den Controls übernommen wird und man sich nicht
selber darum kümmern muss, wäre es für uns unerheblich. Praktisch wäre es natürlich für diejenigen, die nur die Klassenbibliothek ohne GUI benutzen wollen.
Aber ein Vorteil an der App ist ja genau der, dass wir eine GUI davor sitzen haben, mit der man alles bedienen kann was die Lib bietet und darüber hinaus noch eine 3D Visualisierung hat.

Ich hoffe trotzdem, dass Du Dir mal unseren SourceCode anguckst, wenn er denn mal online ist und nochmal Kritik abgibst.

Der Code ist jetzt endlich online. Im Moment nur im SVN Repository verfügbar: http://sourceforge.net/scm/?type=svn&group_id=532645

Außerdem gibt es jetzt auch eine Internetseite, die mit der Zeit mit Codebeispielen, Videos etc. gefüllt wird. Hier findet man aber bereits die Codedokus. http://www.netbotproject.org/

Viel Spaß