INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.

Antwort schreiben 
 
Themabewertung:
  • 0 Bewertungen - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Roborterauto
30.06.2015, 19:26
Beitrag #1
Roborterauto
Hi@all Arduinos,

ich und meine Freundin wollen zusammen ein weites gehendes autarkes outdoor Auto bauen. Ja, mir ist klar das das mega groß ist, aber immer ein Schritt vor den
anderen. Wer und ernsthaft helfen möchte, möge das bitte tun!

Das Auto soll vom Start aus selbstständig zu einer bestimmten Koordinate fahren und selbstständig Hindernisse ausweichen.

Auto wird aus Lego gebaut. Fahren, lenken, Hindernisse erkennen und erst mal stoppen, kein Problem.

Nächste Schritte -> selbstständig den Hindernis ausweichen und Kurs wieder aufnehmen
Meiner -> schauen wo er ist, wo er hin muss, befehle umsetzen (Beschleunigen und lenken)

Ein Schritt nach den anderen.

Welches GPS-Modul schlagt ihr vor?
Brauche ich zusätzlich noch einen Kompass um zu wissen wie er gerade steht bzw stehen muss?
Ist das über das GPS abgedeckt?
Was sagt mir alles das Modul (was gibt er alles aus)?

Danke für eure Hilfe !!!!!!!!
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
30.06.2015, 20:06 (Dieser Beitrag wurde zuletzt bearbeitet: 30.06.2015 21:18 von HaWe.)
Beitrag #2
RE: Roborterauto
GPS ist nicht notwendig, aber im Freien sehr hilfreich.
GPS ist aber nur auf etwa 5-10m genau, reicht also nicht zum exakten Fahren auf Wegen oder Fahrspuren auf der Straße.
Genauere Positionsbestimmung ist per Sensorfusion mit Odometrie und Gyro und Kompass möglich.
Das habe ich vor vielen Jahren bereits mit Tetrix, Matrix und Lego gebaut und programmiert:

http://www.mindstormsforum.de/viewtopic....46&p=56850

Nach meiner heutigen Erfahrung würde ich sagen:
Ein GPS könnte man per Lowpass-Filter implementieren,
Gyro per Highpass-Filter
Kompass per Lowpass-Filter
und Accelerometer per Lowpass- oder Kalmanfilter sowie
Odometrie per Highpass- oder Kalmanfilter.

Es gibt aber einen IMU-Sensor, der bereits Gyro, Kompass und Accelerometer on-board integriert und fusioniert:
http://de.manu-systems.com/CMPS11.shtml

Dann blieben nur noch Odometrie und GPS, die man zusätzlich fusionieren müsste. So werde ich es auch machen - es sei denn, ich verwende ein Neuronales Netz dafür. Wink

ps,
für GPS gibt es theoretisch eine Genauigkeits-Verbesserung (Sensitivität und Präzision) auf weniger als 10cm:
mit einem 2., stationären GPS-System in der Nähe, das mit der MCU des Fahr-Roboters kommuniziert.
Beide GPS-Systeme empfangen nämlich Signale, die ähnlich oszillieren, und per Differential-Auswertung beider GPS-Empfänger lässt sich per Lowpass- oder Kalmanfilter die Position des mobilen Gerätes deutlich besser identifizieren. Beide Modul-Signale müssten also auf demselben Prozessor (d.h. des Fahr-Roboters) ausgewertet werden.

Die ganze Sache ist aber sehr rechen-, cpu-Zakt- und speicherintensiv und schreit geradezu nach Multitasking (am besten pre-emptiv) wegen teilw. sehr langwieriger Rechentasks und sehr zeitkritischer Mess-Tasks: unter einem ARM Prozessor (Due=ARM Cortex M3, eher noch besser) läuft da IMO nichts!
HTH!
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
12.07.2015, 12:38
Beitrag #3
RE: Roborterauto
Hallo HaWe,

erst mal vielen dank für die schnelle Antwort!
Ich habe die letzten Tage genutzt um deine Antworten zu recherchieren und mein Versuchsauto zu basteln.
Ein 12v /5A Gleichstrom-Motor ist jetzt drin. Nun möchte ich den etwas eleganter vor-/rückwärts fahren lassen
als nur mit einem TIP120 und einem Relai.
Als MOSFET könnte ich mir den IRLZ34N vorstellen !? Kann man mit dem den Motor relativ Linear "hoch fahren" lassen?
Wie kann ich das Auto dann rückwärts fahren lassen? Wieder ein Relai? Aber wie mache ich das dann mit einer Freilaufdiode(Schottky Dioden!?)?
oder eine H-Brücke? Dann benötige ich doch noch ein p-FET !? Welchen?

Danke
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
13.07.2015, 10:28
Beitrag #4
RE: Roborterauto
Ich würde das nicht über Relais machen, sondern nur über ein Motor Modul / H-Brücke. Dies hier ist bis 5A belastbar http://www.ebay.de/itm/191474438196
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
14.07.2015, 18:39
Beitrag #5
RE: Roborterauto
danke dani,

ich habe das bestellt
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
15.07.2015, 16:34
Beitrag #6
RE: Roborterauto
Habe ein ähnliches projekt vor. H Brücke ist erste wahl für die motoren.
Die Navigation geht bei mir über Drehencoder die den Weg messen. Theoretisch könnte man sich merken, wo man hingefahren ist. Leichte abweichungen werden sich dann nicht vermeiden lassen.
IR Dioden an allen Seiten erkennen dann Hindernisse.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
09.09.2015, 16:39
Beitrag #7
RE: Roborterauto
Hallo zusammen, ich bin die im ersten Beitrag erwähnte Freundin, die in ihren Semesterferien ihr Möglichstes tut, das Projekt voranzutreiben Wink

Die aktuelle Herausforderung:
Schrittzählung/Entfernungsmessung anhand der Reifendrehung des Autos, also Erkennung der bisher zurückgelegten Radstrecke (in dem Fall gleichbedeutend mit der Anzahl der Umdrehungen).

Ideen/bisherige Experimente:
-> Alle Ideen laufen darauf hinaus, dass das Rad in "Sektoren" eingeteilt wird, die gezählt werden können. Die Zählung muss über Interrupts erfolgen (stimmt das?) und die Information kann weiter verwertet werden.
-> Infrarot-Diode und Fotodiode: Wir haben das schwarze Rad mit weißen Streifen bemalt und mit einem Sensor kombiniert aus Infrarot-Sender und -Empfänger herumexperimentiert. Der Sensor ist mittlerweile gut abgeschirmt und könnte in geringer Entfernung zum Rad fixiert werden.
-> Lichtschranke oä: An sich eine vermutlich zuverlässigere Methode als mit Reflexion zu arbeiten (oder?), leider bei unserem Modell kaum zu realisieren.
-> Reed-Kontakt: Es wäre möglich, das Rad mit kleinen Magneten zu bekleben und einen Reedschalter in unmittelbarer Nähe zu fixieren.
-> Drehgeber/Drehencoder (wie bnjmn schon erwähnt hat): Noch nicht getestet und leider auch schwer zu integrieren.
-> Neueste Idee: Verwendung des Innenlebens einer optischen Computermaus (Lasermaus im Idealfall) - Erfahrungen??

Problematik:
Leider laufen alle bisherigen Experimente auf eine ähnliche Problematik hinaus: Schlechtes Signal und die Frage nach der Glättung. Bedeutet, es gibt nicht einmal annähernd ein Rechtecksignal, das schön via Interrupt auszuwerten wäre, sondern statt einer auch mal etwa 100 Flanken. Gerade die optischen Methoden machen da Probleme, wir haben Signalglättung mit Kondensatoren versucht (leichte Verbesserung). Softwareseitige Signalglättung ist ja meines Erachtens kaum möglich, weil wir zwingend über Interrupts gehen müssen und diese natürlich wenig Code enthalten dürfen - richtig?
Die mechanischen Methoden funktionieren zwar etwas besser, hier aber auch das Problem des Prellens, dem ich etwas hilflos gegenüberstehe.

Es wäre schön, wenn ihr unserem Projekt (und uns) weiterhin unter die Arme greifen könntet! Danke Smile
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
09.09.2015, 17:08
Beitrag #8
RE: Roborterauto
(09.09.2015 16:39)Brokie schrieb:  -> Alle Ideen laufen darauf hinaus, dass das Rad in "Sektoren" eingeteilt wird, die gezählt werden können. Die Zählung muss über Interrupts erfolgen (stimmt das?)
Nein, das stimmt nicht. Man kann es auch anders machen, so lange man den Zustand des entsprechenden Eingangs oft genug abfragen kann. Speziell in der Ausprobier-Phase koennte es ohne Interrupts einfacher sein.
Im Praxis-Einsatz duerfte es aber mit Interrupts besser funktionieren.

Zitat:-> Neueste Idee: Verwendung des Innenlebens einer optischen Computermaus (Lasermaus im Idealfall) - Erfahrungen??
Das koennte schwierig werden. Allerdings koennte es was werden mit den "wheel encodern" einer mechanischen Maus. Sucht mal nach "wheel encoder". Im Prinzip sind das Raeder mit einem transparentem Rand, der undurchlaessige Segmente hat. Das ganze bewegt sich durch eine Gabel-Lichtschranke. Das duerfte ein relativ sauberes Rechteck-Signal ergeben.

Zitat:Leider laufen alle bisherigen Experimente auf eine ähnliche Problematik hinaus: Schlechtes Signal und die Frage nach der Glättung. Bedeutet, es gibt nicht einmal annähernd ein Rechtecksignal, das schön via Interrupt auszuwerten wäre, sondern statt einer auch mal etwa 100 Flanken. Gerade die optischen Methoden machen da Probleme, wir haben Signalglättung mit Kondensatoren versucht (leichte Verbesserung). Softwareseitige Signalglättung ist ja meines Erachtens kaum möglich, weil wir zwingend über Interrupts gehen müssen und diese natürlich wenig Code enthalten dürfen - richtig?
Also wie schon gesagt muss man nicht unbedingt ueber Interrupts gehen. Ausserdem kann man auch in einer Interrupt-Routine eine Abfrage auf micros() machen und so ein Entprellen implementieren.

Gruss,
Thorsten

Falls ich mit einer Antwort helfen konnte, wuerde ich mich freuen, ein paar Fotos oder auch ein kleines Filmchen des zugehoerigen Projekts zu sehen.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
Antwort schreiben 


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste