Asuro Simulieren

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

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).

Zitat:

---

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.

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.

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

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?

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.

Zitat:

---

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 :-)

Zitat:

---

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.

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.