Ich fahre gleich bei einem Kumpel vorbei und leihen mir sein Multimeter aus. Dann werde ich ein paar Experimente machen und anschließend kann ich dir auch sagen was wir genau messen wollen.
Was wäre komplizierter, wenn die Gameports normgerecht wären? Wenn die Sache wirklich zu heftig wird, kaufe ich mir lieber doch zwei alte Joysticks und löte in denen rum. Was muss ich dann beachten, was müssen die Geräte bieten bzw. wie müssen sie aufgebaut sein?

Also wenn die Sache jetzt zu abgefahren wird, sollten wir es vllt doch mit der RS232 (com-) Schnittstelle machen, oder?
Aus meinen bisherigen Erkenntnissen heraus arbeiten die meisten Tools ja mit der COM. Zum steuern möchte ich mir sowieso ein eigenes Tool schreiben. Die Signale sollten also möglichst einfach aufgebaut sein, damit dieses Zusatzprojekt nicht unmöglich wird.

Ich melde mich wieder, bis Donnerstag dann... Schöne Reise!

vg

EDIT:
Ich habe mich durch das Forum/Google gelesen, sowie ein paar Tests gemacht und folgendes festgestellt:
Den genauen Ladezustand eines Akkus (nicht LiIon oder LiPo) zu ermitteln ist quasi unmöglich. Man kann zwar ungefähr aus der Spannung, die der Akku liefert, ermitteln wie "voll" er ist, aber das ist sehr ungenau und extrem verbracherabhängig. Jedesmal wenn ein Motor dazugeschaltet wird, müssten man neu kalibrieren.
Hier noch eine sehr aussagekräftige Quelle:
https://www.roboternetz.de/phpBB2/ze...ag.php?t=23055

Mein Fazit aus diesem Problem:
Wir verkleinern den Umfang des Projekts nochmal und lassen das Display auch gleich weg. Ich wüsste nicht welche Ausgaben noch wirklich wichtig wären.
Ebenfalls wäre ich jetzt auch für die Version mit dem modifizierten Gameport.Ich würde vorschlagen, das wir einen Gameports auf die Platine setzen und dabei alle Joystick-Achsen benutzen.
Ich beziehe mich mal auf diese Beschreibung:
http://de.wikipedia.org/wiki/Gameport

Die Achsen müssen entsprechend belegt werden:
Pin 3 - Joystick 1 X-Achse - Head-Pan (Schwenken)
Pin 6 - Joystick 1 Y-Achse - Head-Tilt (Neigen)

Pin 11 - Joystick 2 X-Achse - Kran-Pan (Schwenken)
Pin 13 - Joystick 2 Y-Achse - Kran-Tilt (Neigen)

Wenn dann irgendwann später die Kran- bzw. Hauptachsen motorengesteuert wird, will ich das über einen zweiten Joystick machen.Diesen würde ich dann, zusammen dem dem Head-Joystick, per Gameport Y-Kabel an den Gameport anschließen. Alternativ hätte ich aber dennoch die Möglichkeit nur den Head zu steuern oder beides mit einem 4-Achsen Joystick.
Y-Kabel: http://cgi.ebay.de/ws/eBayISAPI.dll?...m=280119546192

Hier als die neue Funktionsliste:
-355° Schwenken links / rechts
- 10° Neigen hoch / 60° Schwenken runter
-Geschwindigkeitsreglung der Motoren per PWM (quasi stufenlos)
-Stoppen am Ende jeden Achse (per Schließer-Endschalter)

-Vorbereitung (zweiter Motortreiber) für zwei weitere Motoren um die Hauptachsen des Krans (am Kranfuß) zu steuern

-Manuelle Steuerung (von bis zu 4 Achsen) über Gameport-Schnittstelle und Joystick(s)

-Pegelwandler zur direkten Verkabelung mit PC
-Steuerung der Motoren über PC-Schnittstelle
-In-System-Programmierbarkeit (ISP) - Programmierung direkt mit dem Controller per RS-232 (Com-Port)

Durch das Wegfallen des Displays, sowie sämtlicher Spannungs- Stromüberwachungen und das Minimieren auf nur einen Gameport wurde das Platinen-Layout sehr verkleinert.

Jetzt bleibt nur die Frage offen, ob wir nun den Com-Port oder den LPT-Port benutzen. Ich favorisiere ja den LPT, da mein Notebook einen solchen beseitzt, ich vermute aber das die Programmierung und Steuerung per Com doch einfach ist. Ich mache mich diesbezüglich noch einmal schlau.

Ich hab geguckt welche Kommunikations-Vorgaben es in JAVA (damit will ich die Steuerungs-Software schreiben) bereits bereits gibt.
http://java.sun.com/products/javacomm/
Hieraus kann man lesen, dass RS-232 voll unterstütz wird, LPT jedoch nur teilweise. Ich würde daher sagen: Lass uns den Controller mit eine RS-232 Schnittstelle bauen. Mein PC zu Hause hat noch ein Com-Schnittstelle (für ISP) und ich denke, dass ich mit einem USB-Adapter am Laptop zumindest die Steuerung auch hinkriege.

EDIT2:
Mit der originalen JAVA-API von Sun hat es nicht geklappt, aber mit RXTX (Erweiterung) klappt die Kommunikation per RS232 super. Meinetwegen also RS232...

vg,
offtake