- LiFePO4 Speicher Test         
Seite 3 von 5 ErsteErste 12345 LetzteLetzte
Ergebnis 21 bis 30 von 43

Thema: Asuro Simulieren

  1. #21
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    25.03.2006
    Ort
    Darmstadt
    Alter
    33
    Beiträge
    522
    Anzeige

    Powerstation Test
    OK, sleepMS habe ich jetzt in Msleep umbenannt, danke für den Hinweis.

    Könntest Du bitte die Fehlermeldungen posten, die entstehen, wenn Du versuchst, das Projekt zu compilieren? Normaleweise müsste es sich problemlos importieren lassen. In der Version, die ich angehängt habe, fehlt allerdings der Ordner "Editor", da dieser sowieso noch nicht einmal annähernd benutzbar ist. Eventuell muss man den Ordner aus den Projekteinstellungen entfernen.

    Eclipse wird von den meisten Java-Programmierern verwendet, deshalb hab ich es genommen. Vielleicht bin ich auch mittlerweile zu verwöhnt von Code Completion, automatischer Einrückung usw, aber ich kann mir nicht vorstellen, für so ein Projekt keine IDE zu benutzen. Außerdem müssten die meisten sowieso erstmal das JDK installieren, und da kann man auch gleich Eclipse mit dazu nehmen.

    Ein virtueller Roboterwettbewerb wäre sehr interessant, zudem man da auch ganz neue Sachen ausprobieren könnte, die in der realen Welt garnicht möglich wären.

    MfG Mark

  2. #22
    Benutzer Stammmitglied
    Registriert seit
    09.05.2007
    Beiträge
    99
    Hallo,

    finde ich superspannend.

    Auch ich habe mir phys2d und Eure Erweiterungen dazu runter geladen. Versuche mich gerade daran. Es sollte doch möglich sein das orginal C-Programm für den Asuro mit der Simulation zu verbinden (über Sockets).

  3. #23
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    12.02.2006
    Beiträge
    459
    Es sollte doch möglich sein das orginal C-Programm für den Asuro mit der Simulation zu verbinden (über Sockets).
    Nur zu, es wäre schön, wenn es klappt.
    Eine andere Möglichkeit könnte das Java JNI Interface zu nutzen. Ist eventuell einfacher zu programmieren.

  4. #24
    Benutzer Stammmitglied
    Registriert seit
    09.05.2007
    Beiträge
    99
    Habe ich jetzt gemacht (nicht JNI sondern via Sockets). D.h. es geht jetzt auch mit einem C-Programm AsuroSumoClient.exe (VisualStudio).

    Dazu habe ich das JAVA Projekt etwas umgestellt (auf Packages verteilt). Auch hauptsächlich deswegen weil ich zwischen dem HardwareRoboter und seiner Software trennen musste (damit letztere auch in C programmiert werden kann).

    Simulator.java habe ich nach Simulation1.java umgenannt -> (wie gehabt) zwei lokale Clients.
    Simulation2.java -> ein lokaler Client und ein remote Client.
    Simulation3.java -> zwei remote Clients.

    Startet man Simulation2 oder Simulation3 muss man natürlich noch die remote Clients starten. Am besten vorher. Die warten dann auf den Start der Simulation.
    Einen Client gibt es für JAVA -> AsuroSumoClient.java
    Und einen zweiten Client gibt es für C -> AsuroSumoClient.exe

    Der remote Client wird jeweils in blau angezeigt.

    edit: Es heißt AsuroSumoClient und der blaue Asuro war nicht zu sehen.
    Angehängte Dateien Angehängte Dateien

  5. #25
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    12.02.2006
    Beiträge
    459
    Hi rossir,

    schön, dass Du so weit gekommen bist. Ich habe ja schon gedacht, Du hättest das Projekt schon aufgegeben.
    Beim Durchsehen scheint mir, dass Du Dein Copyright in den entsprechenden Routinen nicht eingetragen hast. Das ist meiner Meinung nach bei Open-Source Projekten wichtig, damit man weiß, was von wem kommt. Es reicht ein Nickname aus.

    Die Asuro Source könnte man noch aus dem C-Programm als eigenständiges Programmfile herauslösen, so dass der Code wirklich Asuro-kompatible wird ( allle Funktionen bis auf "main" antürlich )

    Ich persöhnlich verwende den GCC, deshalb wird's schwierig für mich, den VCC Code zu kompilieren.

    Ansonsten: Gratulation zu Deiner Arbeit,

    robo

  6. #26
    Benutzer Stammmitglied
    Registriert seit
    09.05.2007
    Beiträge
    99
    Hallo robo,

    Copyright? Wofür? Eigentlich habe ich ja nur den von Euch geschriebenen Code mit cut&past umgestellt und die ASURO Lib Funktionen in schreibweise und Parameterverwendung näher an die Orginal Asuro Lib 2.9.1 gebracht. Dann ein bisschen Socketzucker dazu getan.

    Selbst beim C-Code bin ich so vorgegangen. Ich habe den vorhandenen JAVA Code genommen und reingepastet und noch C-mäßige Microanpassungen vorgenommen. Auch hier dann noch ein bisschen Socketzucker in MSWINSocket.cpp. (Und selbst das meist via cut&past aus dem Netz.)

    Also nichts Besonderes und vor allem nur dort MSWIN-spezifisch wo es um Sockets geht. Deswegen ist meine Hoffnung, dass man es leicht nach GCC umstellen kann. (Dort kenn' ich mich aber nicht aus.) Wahrscheinlich braucht man nur ein neues/eigenes GCCSocket.cpp.

    Ich glaube schon (bin optimistisch), dass man das Ziel erreicht und Simulator C-Code 1:1 in den Asuro übertragen kann. Könnte das nicht ein schönes (Zwischen-)Ziel sein?

  7. #27
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    12.02.2010
    Beiträge
    167
    Jup, sieht gut aus.

    Ich steuere meinen Roboter auf dem Bildschirm mit dem Board, welches ich an der Seriellen Schnittstelle angeschlossen habe.
    Der Screenroboter fährt mit den Anweisungen, welche vom Atmegaboard kommen. Das Board wertet die laufenden Daten aus, die vom Screenroboter über die Schnittstelle gesendet werden. Ich programmiere in GFA32 (ist jetzt Freeware).

    Nebenbei mein Board :
    Ich mache es mit einer Ex-Platine, wo 3 Atmega drauf sind mit 16mhz, 2x Atmega32 und 1x Atmega8, dazu habe ich vorn quer ein Steckbrett gesetzt.
    Darauf sind zur zeit 2x PCF8574, 1x 27c256, 2x 8ter Leuchtdiodenbänke, 1x Irdiode ,1x Tsop.
    Die Platine selber hat noch 1xFBas-Buchse , 1x Stecker für PC-Tastatur, 1x LCD-Display, 1x Seriell(Max), 1x SD-Karte.

    Mit diesem Ding kann man unendliche weiten des Atmegas und den Sensoren entdecken.

    Alle Anschlüsse sind Steckbar , also keine Festverdrahtung der Sensoren.
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken img_0945.jpg  

  8. #28
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    12.02.2006
    Beiträge
    459
    Der Screenroboter fährt mit den Anweisungen, welche vom Atmegaboard kommen. Das Board wertet die laufenden Daten aus, die vom Screenroboter über die Schnittstelle gesendet werden. Ich programmiere in GFA32
    Hallo funkheld,

    das ist eine interressante Anwendung: eine echte "hardware in the loop" simulation. Das entspricht dem Vorgehen in der Industrie.
    Du verwendest also den Simulator, um Deine reale Prozessorhardware zu testen

  9. #29
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    12.02.2010
    Beiträge
    167
    um Deine reale Prozessorhardware zu testen...
    Mein Radius für Versuche ist dadurch grösser und Kostengünstiger.
    Es macht mir mehr spass damit , als mit einem realen Robotor zu spielen.

    Das Wichtigste ist ja eigentlich immer der Atmega.

    Man lernt dadurch sehr viel, Pc und Atmega zu proggen.

  10. #30
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    12.02.2006
    Beiträge
    459
    OK, der try and error zyklus ist mit der Simulation kürzer. Aber nicht vergessen: Eine Simulation ist nur eine Annäherung an die Realität. Da wird sicher noch etwas Nacharbeit nötig sein, wenn Du Dein Programm auf dem realen Roboter laufen lässt.

Seite 3 von 5 ErsteErste 12345 LetzteLetzte

Berechtigungen

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

Solar Speicher und Akkus Tests