XProfan

- Seite 2 -

Stefan
M.
Caillet

Hallo iF, ja Variante b) ist Ok. Da wir pro Motor nur 1 8-Bit Wort benötigen, sollten eigentlich 16 8-Bit Worte in einem eigenen Thread problemlos möglich sein. Ich stelle es mir so vor: ein Motoren Wort Besteht aus: Bit 0-5 für die Drehzahl-Info (entspr 64 Stufen 0-100%), Bit 6 für die Dreh-Richtung, Bit 7 könnte Benutzt werden, um Anstelle von Motoren, Servos, sowie um das Synchronisations-Byte zu definieren. Das Interface speichert die Drehzal-Info als Spannungswert in einem kleinen Kondensator. Wird dieser nicht regelmässig aufgefrischt (nachgeladen, od. mit einem neuen Spannungswert versorgt), fällt die Spannung im Kondensator auf Null Volt, was Motor Stop bedeutet. Dabei Stoppen die Motoren allerdings nicht abruppt, sondern werden innerhalb z.B. einer halben Sekunde immer langsamer, und bleiben schliesslich stehen. Dies wirkt sich sicher positiv auf die Lebensdauer der Getriebe, sowie der gesamten Antriebsmechanik aus.

Die Programmierung der Ports wird kein Problem sein, da ich eine kleine Xprofan-Prozc erstellen werde, die Dir einen neuen Befehl zur Verfügung stellt um Daten-Sets an die das Interface zu übertragen. Als schnittstelle werden wir den USB nutzen.Das Interface wird sich als USB-Device am PC anmelden.
Die Skizze kannst Du erstellen, womit Du willst, selbst ne eingescante Bleistiftzeichnung reicht, sofern sie einige Grössenangaben enthält, und die Proportionen stimmen, so dass die Grössen-Verhältnisse ersichtlich sind. Momentan bin ich dabei, die USB-Anbindung zu entwerfen.
Gruss Stefan

Ich habe grosses Glück, weil ich Mitmenschen helfen darf.
Entwicklungsumgebung:
XProfan11 , Win XP Pro 32Bit , Win XP Home ,Win7 HomePremium 64Bit
PC: P4/3GHz , 2GB RAM , 1700GB HD
Laptop: Intel Core 2 Duo /2,2GHz , 4GB RAM , 500GB HD

Hehe klasse, gibt es eine Mgl. für das Programm zu ermitteln, wie schnell ein Motor grade dreht oder welche Position er hat oder wie stark ein Widerstand ist dem er ausgesetzt ist?

(...muss schon wieder längst sowas von ins Bett...

)

Stefan
M.
Caillet

Hallo iF, Es besteht durchaus die Möglichkeit, Werte vom Interface an den PC zurückzugeben, wir müssen dabei einfach eine Anzahl von Eingängen festlegen, an die die entsprechenden Sensoren angeschlossen werden. Diese können wir dann entweder direkt abfragen, oder ebenfals kontunierlich als Daten-Set an den PC senden. Ich vermute, dass Du da evt. an einen Robot-Arm denkst, bei dem du wissen willst, ob er da ist, wo er sein soll?
Stefan

Nein kein Arm, eher wissen zu können, wenn z.B. 100% Schub auf Motor A angewiesen ist, dass nur 89% umgesetzt werden z.B. weil es "bergauf" geht oder 50% Schub / 200% Geschwindigeit bei Bergab. Also etwas wie "Widerstand", gerne auch für jedes gesendete Set eine Rückantwort - oder wie auch immer. Dummerweise - so ich glaube - wird das wohl schwierig zu unterscheiden sein davon, dass wenn z.B. die Batt. fast leer ist - ausgenommen der Batt.-Status wäre abfragbar sodass mit einer Batt.-Status/Effiz-Tabelle verglichen werden könnte.

Eine Kalibrierung durch das Gerät muss nicht erfolgen, ich denke an eine ("Permanente") durch das Programme

Stefan
M.
Caillet

Hallo if, das Problem ist folgendes: die Variante B, die wir gewählt hatten, ziehlt auf schnelle Datenkommunikation in einer Richtung ab. Natürlich kann ich die (kurze!) Pause zwischen 2 Sets benutzen, um vlt. 4 Bytes zurückzusenden, aber: das 1. Prob. ist, es ist im Moment auf dem Markt kein USB i/o interface zu finden, dessen Reaktionszeit schnell genug ist. Wir kommen auf Max. 12 Sets/Sec. bei kontuniirlicher Übertragung. Und wenn Du zusätzlich noch mehrere Status-Beytes umd Meswerte zurücksenden willst, müssen wir die Sache etwas anders angehen, da dann ein vollständiges Input/Output Interface mit mehreren Analog Eingängen, Analog/Digitalwandlern und Zwischenspeicherung der Daten, bis sie vom PC abgerufen werden, benötigt wird. Dies bedeutet: Es ist nicht mehr Möglich, ohne ein Microcontroler im Mondauto auszukommen. und Umstellung auf Variante C.
Variante C) Eine Mischung aus A) und B):
1.Die Motor-Daten werden nur gesendet, wenn eine Statusänderung nötig ist.
2. Der Motorstatus werden adressiert in 2 Bytes gesendet: Byte1 Schreiben/Lesen und Adresse, Byte2 Motorstatus
Wenn Byte 1 auf Lesen werden die Messwerte an den Analogeingängen zum PC gesendet.
3. Der PC sendet regelmässig (5x/Sec) ein Control-Byte an den Microcontroler der diesem sagt, das der PC noch "lebt" - fällt dieses Byte aus, werden alle Motoren auf Null gefahren. Auseerdem antwortet der Microcontroler auf das Control-Byte um der Steuersoftware im PC ein Lebenszeichen zu geben.
4. Wenn mehrere Motoren den Status gleichzeitig ändern müssen, werden die Daten als Set Durch ein Control-Bit definiert) gesendet, und als Abschluss ein StartByte gesendet.

Ich denke, wenn Du mehr Kontrolle über das Mondauto brauchst, kommst du um einen (Micro)-Controler nicht herum. Du brauchst davor jedoch keine Angst haben, da ich den mit der benötigten SteuerSoftware ausstatten werde, sodass er ein Komplettes I/O-System bildet. Was die erfassung des IST-Status der Motoren anbelangt (Mot-Drehzahl, Mot,Last) wird bei der Inbetriebname eine kalibrierung unumgänglich sein! Ich kann jedoch eine Kalibrirungs-Routine in die Steuersoftware einbauen. Kalibrierung geht recht einfach, da die SteuerSoftware nur wissen muss, welche Drehzahl (rückgabe als Spannungswert) 100% Leistung entspricht. -> Mondauto auf ebenen! Platz stellen, Kalib aufrufen , Motoren werden auf 100% gestellt, und nach 2-3 Sec. (wenn volle Vorwärtsbewegung. ereicht, werden die Drehzalsensoren abgefragt und die Werte als 100% gespeichert. Den Batterie-Status zu ermitteln, und aun die Software Weiter zu leiten finde ich eine sehr gute Idee, da Kannst Du dan im Controllpanel Gleich den Status auch anzeigen, und selbstverständlich den Wert auch zu Analyse-zwecken heranziehen.

Was das USB anbelangt, muss ich noch einige Tests machen, ob die reaktionszeit von 4ms/Befel bei Anwenduung von Variante C) ausreicht. ansonsten muss ich auf eine schnelle RS232 (ComPort) anbindung direkt durch den Microcontroler zurückgreifen.
So, ich denke Du hast damit wieder ein par Infos mehr. Ich warte jetzt noch auf Deine Skizze.
Gruss Stefan

...Pause zwischen 2 Sets benutzen, um vlt. 4 Bytes zurückzusenden, aber: das 1. Prob. ist, es ist im Moment auf dem Markt kein USB i/o interface zu finden, dessen Reaktionszeit schnell genug ist. Wir kommen auf Max. 12 Sets/Sec. bei kontuniirlicher Übertragung.

Ein "normaler" RS232 ist kein Problem statt USB und wenn dann die Verbindung sogar besser: Natürlich!

Zum anderen, einfach mal "dumm" gefragt: Was wäre Dir denn lieber bzw. was wäre weniger quälend oder was würde Dir mehr Spass machen und was würdest Du damit empfehlen?

Mir würde es dicke ausreichen nur jedes 2. Frame senden und jedes 2. empfangen zu können, vlt. kannst Du damit auch einfach Speicher statischer Grösse nutzen da klar ist, dass nur der letzte Wert gemerkt werden muss.

Was ich sagen will ist, dass es mir z.B. ausreichen würde, alle 1/8 Sec. alle Motoren gesendet und empfangen zu haben. (Welche Grössenordnungen meinst Du?)

Eine Kalibrierungsfahrt am Start darf aber nicht geschehen, ich denke da eher an ein dynamisches Kalibrieren wobei ich mich einfach mit dem genüge, was Du mir als Daten zur Verfügung stellen könntest. Du kannst auch davon ausgehen, dass mehere optische Sensoren am Gerät angebracht sind, nur für ein Accelerometer für Neigung habe ich noch keine Idee, aber vlt. kannst Du sowas mit in solch Gerät verbauen?

Hab grad mal nach Neigunssensoren... [...]

Stefan
M.
Caillet

Hallo iF, nur so auf die Schnelle, das mit der Kalibrierungsfahrt war nicht so gemeint, dass diese bei jedem Start des Mondfahrzeuges stattfinden soll, sondern nur 1x nachdem das Ding zusammengebaut und die Software auf dem PC Installiert wurde, damit die Software einen ReferenzWert für 100% in der Ebene hat. Ich weiss ja nicht genau, welche Motoren schlussendlich zum Einsatz kommen, wie leichtgängig die Mechanik (das Fahrwerk) ist, wie schwer das Ding wirklich wird. Deshalb soll die Software beim Erststart (oder kurz danach) kurz lernen, was für ne Drehzahl, und welche Last die Motoren in der Ebene, bei 100% Leistungsanforderung, wirklich Bilden, und diesen Wert dann speichern damit er in Zukunft zur Verfügung steht. Auf dieser Basis kannst Du ja dann die weiteren Werte ermitteln, und wenn nötig, Deiner Software mitteilen oder in einer Tablelle verarbeiten, oder was auch immer. Sollte irgendwann der Referenzwert stöprend abweichen, kannst Du jedoch jederzeit wieder neu kalibrieren.
Im Prinzipist es egal, wieviele Frames wir senden, das Problem liegt darin, dass wir, sobald wir mehr als einen messwert an den PC zurücksenden wollen, wir nicht mehr um einen Microcontroler herumkommen. Es ist nicht möglich z.B. 6-8 Analoge Eingänge zu digitalisieren und als Paket zum PC zu senden, ohne diese zwischenzuspeichern, es sei denn, ich baue für jeden Messeingang einen eigene A/D-Converter. Dann muss ich aber immernoch jeden converter auf den abfragebefehl des PCs einzeln Adressieren und zur herausgabe der Daten bewegen. Der Aufwand wird auf diese Weise imens, die Kosten übrigens auch.
So wie ich den Microcontroler einsetzen und programieren möchte, tut der nichts anderes, als in einer Schleife alle Messeingänge nacheinander abfragen, sie zu digitalisieren und im internen Variablenspeicher abzulegen, - und, nachzuschauen ob auf dem seriellen Port ein Befehl anliegt. Wenn ja, wird die dem Befehl entsprechende Subroutine aufgerufen. z.B. Motorstatus ändern, PC "lebt" beantworten, oder Messdaten an den PC senden.

vlt. kannst Du damit auch einfach Speicher statischer Grösse nutzen da klar ist, dass nur der letzte Wert gemerkt werden muss

Was die Anzahl der Messwerte/Sensor betrifft, möchte ich eh nur jeweils den aktuelsten im Mondauto speichern, d.h Pro Sensor 1 Byte. Das Problem ist wie oben beschrieben, dass ich nicht pro Sensor 1 A/D-Conv. einsetzen möchte, weil zu aufwändig, Eine églichkeit ist noch einen Multikanal (z.B. 8-Kanal) A/D-Converter einzusetzen, aber selbst der muss Softwaregesteuert werden, in diesem Fall würde ich die Steuerung ebenfalls dem Microcontroler überleassen, da die Steursoftware im PC wirklich genug zu tun hat, und zudem auch das Timing stimmen muss.
Das mit dem Neigungs-Sensor seh ich mir noch an, und melde mich dann wieder.
Gruss Stefan

Habs verstanden, wir machen das genau so wie Du meinst dass es am Besten ist.

Und das mit dem Neigungssensor wäre wirklich eine tolle Sache! (GPS geht auch? Was gibts noch tolles?)

Es wäre ebenso super wenn Du irgendwie immer auch etwas einplanen könntest, dass noch manch anderer Sensor nachträglich von Dir eingerüstet werden kann.

Übrigens, gesteuert/bedient werden kann das Mondfahrzeug von jedem beliebigen Computer aus.

Auf dem System ist ein Webserver installiert, dieser ist entweder per WLAN oder (fallback) UMTS/GPRS erreichbar. Du bist dann herzlich eingeladen zu bedienen, ich gebe Dir dann einfach die IP.

Ich habe mir auch eine Aufgabe gestellt damit, denn ich möchte Bilder auswerten und ich möchte zuverlässig Steckdosen in relevanter Höhe erkennen.

Auf einer Platte an der rechten Seite muss es eine XY-Steuerung geben (dafür dachte ich 2 Motoren) und eine Z für "einstecken" (1 Motor). Wenn Gerät positioniert, dann möchte ich das genaue Finden und Einstecken über Bild auswerten und den 3 Motoren dafür Signale senden.

Das Erkennen von Dosen in der "Umgebung" ist sicherlich noch ein ganz anderes Thema, aber ebenso interessant. Wäre doch toll wenn es dem Gerät gelinge in friedlicher Umgebung sich selbst in ausreichender Menge mit Strom zu versorgen.

(und ggf. Autobatterien klaut...

)

Wieviele Auto(?)Batterien wären denn eigentlich D.M.n. optimal?

Stefan
M.
Caillet

Hallo iF, Neigungssensor: ich verneige mich. wäre kein Prob. son Ding anzuschliessen. Verwendbare Typen: DLS (bedingt, Signal muss agepasstwerden, braucht min. 12V). EL800 (+ - 45Grad) sehr gut geeignet! MRI (+ - 30Grad) gut geeignet, braucht jedoch kleine Signalanpassung da SignalSpannung etwas zu hoch für A/D-C, ist aber kein Prob. nur 2 Widerstände nötig (Spannungsteiler)
Gruss Stefan

Ist davon einer sehr genau, 0,Grad?

Ist das automatisch immer XY oder nur auf einer Linie?

Stefan
M.
Caillet

iF, ich denke, da wäre der EL800 ne gute Wahl. GPS weniger, es sei denn, wir finden ein GPS-Modul, das uns Die Daten sauber zum Abruf anbietet, auch dann aber nur im Freien, da GPS inerhalb von Gebäuden nicht geht. Kannst Du mit jedem Navi im Tunnel testen, und wir erhalten einfach Längen- und Breitenangaben. Falls wir das Ding doch über USB zum laufen kriegen, könnten wir ein USB-HUB ins Mondauto bauen, dann kannst Du die Kamera dort anschliessen, denn Mein Interface wird die Cam nit unterstützen können. Dazu bin ich schlichtweg zu blöd. Zusätzliche Sensoren: ich würde dem Ding noch einige Antikollisions-Sensoren verpassen. Ebenso würde ich die Antribsmotoren auf Überlast hin überwachen und im Fehlerfall die Steuersoftware Informieren.

Wieviele Auto(?)Batterien wären denn eigentlich D.M.n. optimal?

Kann ich Dir noch nicht genau sagen, Wenn ich mal Deine Skizze Habe, und das Konzept einigermassen steht, weiss ich mehr, da ich dan mal ne Stromverbrauchs-Schätzung machen kann.
Stefan

Um Bild & Co brauchst nicht kümmern, ich meine für das Gerät auch nur einfache Sensoren welche halt "einen" Wert zurückliefern. Ich glaube GPS gibts sogar als USB-Stick, da findet sich vlt. etwas wo man Anbindung erhält. Nachteil wäre nur leider, dass man solche Geräte schlecht nachkaufen kann, also vlt. nicht so optimal wie als Bauteil (dachte ich...).

Wie siehts mit Temperatur, Luftdruck und solch spielereien aus?