- fchao-Sinus-Wechselrichter AliExpress         
Ergebnis 1 bis 9 von 9

Thema: NetBot Projekt

  1. #1
    Neuer Benutzer Öfters hier
    Registriert seit
    23.12.2007
    Ort
    Köln
    Beiträge
    7

    NetBot Projekt

    Anzeige

    Powerstation Test
    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/

    Klicke auf die Grafik für eine größere Ansicht

Name:	Runtime2.jpg
Hits:	88
Größe:	42,2 KB
ID:	18559


    Viele Grüße

    redreggae

  2. #2
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    17.03.2004
    Alter
    75
    Beiträge
    487
    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

  3. #3
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    19.05.2005
    Ort
    Berlin
    Beiträge
    316
    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

  4. #4
    Neuer Benutzer Öfters hier
    Registriert seit
    23.12.2007
    Ort
    Köln
    Beiträge
    7
    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

  5. #5
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    19.05.2005
    Ort
    Berlin
    Beiträge
    316
    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

  6. #6
    Neuer Benutzer Öfters hier
    Registriert seit
    23.12.2007
    Ort
    Köln
    Beiträge
    7
    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

    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

  7. #7
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    19.05.2005
    Ort
    Berlin
    Beiträge
    316
    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.

  8. #8
    Neuer Benutzer Öfters hier
    Registriert seit
    23.12.2007
    Ort
    Köln
    Beiträge
    7
    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.

  9. #9
    Neuer Benutzer Öfters hier
    Registriert seit
    23.12.2007
    Ort
    Köln
    Beiträge
    7

    Code ist online

    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ß

Ähnliche Themen

  1. Xmega Eval board Projekt (Foren Projekt)
    Von Rasieel im Forum Vorstellung+Bilder+Ideen zu geplanten eigenen Projekten/Bots
    Antworten: 65
    Letzter Beitrag: 26.01.2010, 13:49
  2. ROV-Projekt „Ray“
    Von Tido im Forum Vorstellung+Bilder+Ideen zu geplanten eigenen Projekten/Bots
    Antworten: 10
    Letzter Beitrag: 05.07.2009, 20:05
  3. Projekt Arm V1
    Von topgunfb im Forum Robby RP6
    Antworten: 3
    Letzter Beitrag: 02.06.2009, 15:54
  4. Das Projekt II
    Von PhilippW im Forum Staubsaugerroboter / Reinigungs- und Rasenmähroboter
    Antworten: 93
    Letzter Beitrag: 26.07.2007, 12:50
  5. Projekt
    Von Terfagter im Forum Allgemeines zum Thema Roboter / Modellbau
    Antworten: 7
    Letzter Beitrag: 25.11.2004, 21:47

Berechtigungen

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

12V Akku bauen