Das Arduino-Monster (temporäres Projekt, für diverse Tests)

Hallochen.
Bis neulich habe ich ja mit nem Arduinifizierten Spielzeugauto so bisschen rumgemacht.
Der wurde nun ausgemustert, da er den Anforderungen nicht genügte (zu klein, Antrieb schlecht steuerbar, da recht schwach, Lenkung närrisch gelöst usw.).

Da stand noch ein RC-Monstertruck rum, in 1:10, von Tamiya, so einer: http://www.tamiyausa.com/items/radio-control-kits-30/trucks-36500/rc-wild-dagger-58231

Deutlich grösser, wesentlich outdorfähiger, viel stärker&schneller, und eben: deutlich mehr Platz unter der Haube.
Natürlich ist sowas nicht mit nem Arduino Motorshield zu steuern, das macht nix, es ist ein richtiger RC-Car-Regler (Carson Truck irgendas) verbaut.
Und: ein anständiges Lenkservo.
Hauptvorteil: das Ungetüm kann auch recht langsam fahren (der Kleine brauchte mindestens Halbgas um sich gescheit zu bewegen, war somit für meine Bude schon kaum noch brauchbar), somit kann ich auch drinnen testen.
Kanten bis Bordsteinhöhe kann der Dagger überwinden, also für draussen dann auch zu gebrauchen.

Was solls werden: ein mehr oder weniger autonomes Roboterauto, was allerdings immer noch vernünftig aussieht, und nich nur wie ein fahrendes Experiment des verrückten Professors.
Auch das war ein Punkt, an dem der kleine Buggy nicht mehr meinen Ansprüchen genügte- hätte nicht mehr gut ausgesehn.
Weiter steht im Lastenheft, dass ich das Monster nicht verbasteln möchte- alles soll wieder zurückbaubar (spurlos, möglichst) sein, da ich das Ding zum einen auch so ganz gerne fahre, und zum anderen ist er eh nur eine weitere Vorstufe für nen richtigen Outdoorbot.
Ich will einfach so viel wie möglich testen damit:
-zuverlässige Hinderniserkennung auch draussen

  • autonome Fahr-und Rangiermanöver (kann ja auch mal eng werden in der Wirklichkeit)
    später dann auch selbständiges Navigieren, wahrscheinlich per GPS
    Zudem möcht ich ihn auch nutzen, um später (da sitzen wir grad im Roboternetz so bissel dran) ein Bakensystem zu erproben, was sowol in-also auch outdoor fixe Punkte bietet, und sowohl als virtuelle Hundeleine als auch als “Zaun” zu gebrauchen ist.

Bisher verbaut sind:
-zwei HC-SR04 in der Front, leicht schräg angeordnet, die Erfassungsbereiche überlappen sich teilweise
-Arduino Uno (wird, aufgrund der doch etlichen nötigen Pins wahrscheinlich gegen nen Mega getauscht später)
-RC-Empfänger (somit kann ich das Ding ggf. auch aus der Ferne stoppen, vorerst will ich ihn damit fahren, aber er soll selbständig Hindernissen ausweichen)
-Fahrtregler (siehe oben)
-Lenkservo (Standardservo)
-ein I2C-LCD, das billige 16x2, weils sowieso rumliegt
-ein Minijoystick (nur für Tests drinnen, später kann der evtl benutzt werden, um verschiedene Modi auszuwählen oder weiss der Geier)
-ein StepDown-Wandler, der mir fein 5V aus den 7.2V des Akkus macht, zusätzlich mit nem Spannungsteiler um die Akkuspannung überwachen zu können. Der UNO jedoch wird direkt über den Akku versorgt, der Stepdown ist mehr oder weniger das “BEC”-und versorgt auch Stick, Display usw.

Wahrscheinlich werde ich noch weitere HC-SR04 hinzufügen, zweie an den Seiten (nur so sind beispielsweise Türen oder ähnliches gut zu erkennen, wenn man an ner Wand lang fährt) und einen hinten, um auch da eine Möglichkeit der Hinderniserkennung zu haben.
Vielleicht aber kommt hinten auch ein Sharp-IR-Sensor, schwenkbar mit nem Miniservo, dran->weiss ich noch nicht.
Verbaut ist bis auf die Sensoren alles auf ner Sperholzplatte, die im Ganzen abnehmbar ist. Die Sensorplatte ist einfach an der Stossdämpferplatte verschraubt-somit ist alles spurlos rückbaubar-ausser zwei zusätzlichen Kabeln (vom Akku zum StepdownModul) ist am Auo selber nichts verändert worden. Die Platte soll die Technik zumindest etwas gegen Dreck von unten schützen. Später gibts vielleicht noch ne bessere Lösung.

Was bisher läuft:
-Joystick wird ordentlich eingelesen (beide Achsen, analog, auf 20 Werte gemappt), auch der Button (digital)
-Lenkservo
-Fahrtregler vorwärts (dazu später noch was)
-die beiden Frontsensoren- mehr oder weniger gut
-Display (gibt momentan nur die Akkuspannung aus)
-RC-Empfang so bisschen (ich vermute, der ollige empfänger hat nen Treffer, den tusch ich demnächst mal)

Probleme momentan:
-der Fahrtregler. Er ist eine Zicke.
Normalerweise arbeitet er so: beim Einschalten wartet er, bis der Sender auf Neutral steht. Das simuliere ich, indem ich ihm vom Ardunio einfach den passenden Wert über die Servo-Lib schicke.
Klappt.
Vorwärts arbeitet er wie ein normales Servo, auch das funktioniert.
Rückwärts ist tückisch, da er zudem ne Bremsfunktion (sogar proportional) hat:
Zieht man den Stick über den Neutralpunkt auf rückwärts, bremst das Ding ungefähr zwei Sekunden lang, und schaltet danach, proportional zur aktuellen Knüppelstellung, auf rückwärts um.
Idiotisch…
Das muss ich irgendwie per Software simulieren, mal gucken, wie.

-die HC-SR04: sie funktionieren (ich benutze derzeit die NewPing-Bibliothek), aber nicht so gut, wie sie es sollten.
Die Werte müssen noch ordentlich gefiltert werden. Problem dabei: es muss schnell gehen, ich hab zwar nie gemessen, wie schnell die Kiste ist, aber irgendwas zwischen 15 und 20 km/h werdens wohl sein.

Da ich nicht alle Bilder in das erste Posting bekam, hier der Rest, wie man sieht, passt die Karosserie grade noch (ich musst sie etwas höher montieren, aber so gehts immerhin):

Sodele.
Erster Fortschritt: ein Rückschritt. 8)

Ich kann das Auto nun per Joystick fahren. Deswegen nen Rückschritt: per RC gings entschieden benutzerfrendlicher. :wink:
Fortschritt ist es dennoch, da dabei das Auto komplett über den Dino gesteuert wird.
Damit das noch so einingermassen vernünftig geht, wurd natürlich der Gasweg drastisch reduziert, und die Auflösung des Sticks auf 40 Stufen raufgesetzt, pro Achse.

Nun hab ich ein Problem: die Bremsfunktion des Reglers. Offenbar schliesst die irgendwas kurz: immer wenn ich in den Bremsbereich komme, startet der Dino neu. Ich vermute, die schliesst einfach den Motorausgang kurz oder so`n Mist.
Werd nochmal die Anleitung des Reglers raussuchen, aber ich fürchte, die geht nicht zu deaktivieren-macht grundsätzlich ja auch Sinn, nur hier nicht wirklich (es wäre nicht soo schwer, nen Bremsalgorithmus zu schreiben, der das alleine erledigt).
Damit muss ich, beim Wechsel aus Fahrt vorwärts auf Fahrt rückwärts nen Riegel einbauen, der ca. 2s gar nix macht (dann wird klaglos rückwärts gefahren) → tolle Wurst.

Falls dazu jemand eine Idee hat (ich kann mit der Bremse leben, aber nicht damit, dass der Dino dann jedes mal neu startet), nur raus mit der Sprache.

Hallo Rabenauge,

wie hast du den Motortreiber verkabelt? Spannungsversorgung von Arduino? Kannst ja mal schaun, an welcher Stelle die Versorgungsspannung einbricht. Der LM2596, den du verbaust hast, sollte Ströme von 2A locker aushalten und auch Kurzschlüsse bringen ihn nicht um.

Hast du Kenndaten der Motors? Vielleicht hilft eine Polyfuse oder eine ähnliche selbstzurückstellende Sicherung. Dann währe der Dagger nur minimal einsatzunfähig.

Der "Motortreiber" ist ein stinknormaler RC-Car-Regler.
Hat ein BEC (was ich nicht nutze, da es für alles bisschen mickerig wär), und wird direkt an den Fahrakku angeschlossen.
Dort nehme ich auch die Stromvrsorgung für den StepDown ab.
Im Grunde ist der Regler angeschlossen wie ein Servo, nur ohne die +5V (das wär das BEC), also Signal am Arduinopin, Masse gegen den Spannungsregler.
Seine eigene Spannung scheint das Ding selber zu erzeugen (ausm Fahrakku halt), das funktioniert ja.
Kenndaten zu den Motoren hab ich nicht wirklich, es sind zwei "Blechmotoren" der 540er Baugrösse (ist üblich in solchen Modellen, irgendein Standardmotor zu dem es nirgends genauere Daten gibt).

Inzwischen hab ich die Anleitung des Reglers mal überflogen: die Bremse deaktivieren ist nicht möglich. So wie es also aussieht, muss für ca. 2Sekunden "nichts" gesteuert werden, damit das Ding in den Rückwärtsmodus geht-oder eben gebremst werden (sinnigerweise schaltet das Ding aus "bremsen" tatsächlich auf die jeweilige Knüppelstellung direkt um, man kann also ohne Verzögerung aus "voll bremsen" auf "voll rückwärts" gehn...schon genial.

@Rabenauge:
Wie liegt deine Einschätzung warum der Arduino einen Reset macht. Weil die Spannung beim Bremsen der Motoren kurz einbricht ?
Oder weil dann Störungen auf der VCC liegen, die den Arduino reseten lassen.

Hallo!
Wennst statt der ESC/Motorcombo ein kleines Servo verwendest, passiert das mit dem Reset auch ?

mfg Martin

Es gibt zu dem Regler praktisch keine Doku-nur ne Minianleitung.
Da auch nix konkretes draufsteht und er schon was älter ist, hab ich keinerlei Infos, wie der bremst-ich meine, proportional, aber das kann täuschen, immerhin werden da nen paar Kilo Auto runtergebremst, und das Ding steht nach 3m.

Dass die Spannung einbricht, kann ich mir kaum vorstellen: ich hab nen guten, alten NC-Racingpack dran. Die liefern auch 100A, wenns nötig ist. Da der Stepdown-Wandler direkt vom Akku versorgt wird, ist das fast nen Unding.
Vielleicht geht der Spannungsregler da mal kurz in die Knie, weil er für nen winzigen Moment mal nicht genug rein bekommt?

So- die Ursache des Regler-Absturz-Problemes hab ich nicht rausgefunden, aber ich hab es dennoch beseitigen können.

Es scheint nicht wirklich was mit der Bremse zu tun zu haben-der Absturz kam immer in dem Moment, wo der Regler zwischen Bremsen und Rückwärts umgeschalten hat.
Umschifft habe ich das, indem ich momentan den Wert für Rückwärtsfahrt noch etwas reduziert habe (vorher 1400µs, jetzt 1430µs), damit tritt das Problem nicht mehr auf.
Nach nem kleinen Moment kann man dann durchaus auch rückwärts weiter beschleunigen, soweit ich das bisher testen konnte (nicht so wirklich, da die jetztigen Parameter schon ein feinfühliges Steuern mit dem Daumen-Knüppel nicht mehr zulassen).
Scheint also ohne die Bremsverzögerung zu gehen.
Ich probiere da mal noch bissel rum- womöglich ist der Regler nicht soo feinfühlig, wie die Servoansteuerung der Servo-Lib (ich benutze dort ausschliesslich writeMicroseconds()), und braucht evtl. einfach nen grösseren Neutralbereich. Da der Arduino nunmal punktgenau arbeitet (was keine RC-Fernsteuerung macht), ist möglicherweise einfach irgendein Bereich zu schmal.

Immerhin: soweit funktionierts nun.
Jetzt werd ich das mal im autonomen Modus testen (noch ohne Sensoren, erstmal muss der Dino das fahren (und vor allem das rechtzeitige anhalten) kappiert haben..ist eine Sache, nen Spielzeugauto herumzufahren, aber ne andere, nen Laster...:smiley:

So.
Autonomen Modus hab ich (noch..) verschoben.
Wichtiger waren mir die beiden Frontsensoren.
Die hatten nen kleinen Bug: Werte bis bissle über nen Meter funktionieren, mehr nicht. Etwas mager-weiss man doch, dass die HC-SR04 vier Meter (ggf. mehr) schaffen.
Aber klar: in ein Byte passt nicht soo viel... 8)
Wertebereich erhöht und -klappt.

Grad bin ich dran, die virtuelle Stosstange zu justieren. Ich möchte die beiden Sensoren so ausrichten, dass sie vor dem Auto nen Bereich beide erfassen, und seitlich noch so viel wie möglich.
Dafür müssen die Sensoren allerdings mechanisch recht genau eingestellt sein. Glücklicherweise hatte ich das sowieso eingeplant, und kann sie nun bequem etwas drehen, und dann so auch fixieren (sind mit zwei Schrauben am Träger befestigt).
Damit das ohne Kabelei abgeht, hab ich die Werte der Sensoren (umgerechnet in cm, ist für uns Nicht-Maschinen einfach verständlicher) einfach aufs Display geworfen-dazu isses ja da. :slight_smile:

Sodele. Die Sensoren sind eingestellt, momentan überlappen sie so, dass der Bereich vorn bei 70cm Abstand ner Fahrzeugbreite entspricht. Macht mich noch nicht so ganz glücklich, weil damit ja die äusseren Bereiche auch schmaler werden, aber geht erstmal so.
Damit muss der Truck bis auf etwa 70 cm an eine Lücke ran, um feststellen zu können, ob er durchpasst später. Das reicht grad noch zum abdrehen.

Nebenbei gabs nen kleinen Hardwareumbau: bekanntlich frisst ein HC-Sr04 zwei digitale Pins-einen fürn Trigger (damit wird das Ding munter, und sendet zugleich den Ping aus), und einen um das Echo dann ausgewertet zu liefern.
Das ist blöd, weil ich zweie dran hab, noch mehr brauchen werde und nen Uno nun nicht grade mit Pins überladen ist.
Laut Datenblatt frisst so ein Sensor nur 15mA-also hab ich kurzerhand die beiden Trigger-Leitungen auf einen Pin geschmissen.
Es funktioniert auch. Auch die Messung ist weiterhin ausreichend genau (ich messe eh nur im Zentimeterbereich, das genügt), da die beiden Sensoren sowieso nebeneinander sitzen.
Bei weiter entfernten Sensoren sollte man das besser nicht machen, weil sie wohl kaum zwischen ihrem eigenen und nem fremden Ping unterscheiden können. Dann würds ungenau.

Als nächstes steht ne kleine Softwarearbeit an:
Lenkservo und Fahrtregler will ich per Knopfdruck ein-oder ausschalten können.
Das Ding steht längere Zeit hier aufgebockt rum, da können die Stromfresser aus (zumal ich dann den Regler nicht mehr separat schalten brauche).
Keine grossartige Sache- der Joystick hat ja auch nen Button, den nehm ich dafür.
Nebenbei kann das Ganze später als Notaus agieren-natürlich nur, wenn die Karosse nicht drauf ist- ich will die nicht öffnen, um an den Joystick zu kommen.

Sodele-bin etwas weiter gekommen (Regenwetter sei dank):

Ich kann nun die Fahr-und Lenkfunktion jederzeit zu-oder abschalten. Da gab es noch nen kleinen Bug zu finden-ehe man den Fahrtregler detach(t), sollte man ihn auf Stop stellen-hätt man eigentlich freiwillig drauf kommen können...ist behoben.
Der hat zwar "sowas wie ein" Failsave, aber er geht auf Hold und nicht auf Stop-auch schön. :slight_smile:

Die NemPing-Bibliothek macht den selben Mist wie wenn mans per Hand macht: bei Entfernungen ausserhalb des Sensorlimits (kann man in der NewPing ja hübsch einstellen) gibt sie Entfernung=0 zurück.
Gut-wenn mans weiss. Wenn nicht, staunt man, wieso nix losgeht.
Aber auch das war schnell behoben.

Momentan hab ich ein seeeehr rudimentäres, autonomes Fahrprogramm, was vorsichtshalber nach ner Minute abbricht (keine Lust, dem Ding ewig hinterherzurennen, um die RC-Anbindung hab ich mich noch nicht weiter gekümmert):

Wenn vor dem Auto mehr als ein Meter freie Bahn ist, wird (langsam...) gefahren. Dabei werden pausenlos die beiden Frontsensoren (andere gibts ja noch nich) abgefragt, und wenn auf einer Seite mehr Platz ist als auf der anderen, wird dorthin, sogar bisschen proportional, gelenkt.
Das funktioniert auch ganz gut, allerdings ist die Formel, nach der die Lenkeinschläge momentan berechnet werden, völliger Blödsinn. Musste nur schnell gehn: ich wollt das Ding mal alleine fahren sehen.
Da kommt ne vernünftige Berechnung rein, heute noch (denk ich mal, morgen wird wohl nich soo viel).
Schon nich übel, wenn der Brocken so alleine loszockelt... :slight_smile:

Macht entschieden mehr Spass als der Billig-Vorgänger mit seinem Plastikgeklapper und Getriebegekreische-auf dem Wäscheboden hört man vom Monster nur die Reifen summen... 8)

Sodele.
Es wurde weiter aufgerüstet. :smiley:

Hinten ist eine, zur vorderen fast identische, Sensorhalterung dazugekommen. Bestückt wie vorn: zwei HC-Sr04. allerdings etwas anders justiert(da grübele ich noch, was besser ist).

Damit hab ich nun nach vorne raus ca. 30 Grad Blickwinkel, und hinten sogar etwas mehr.
Eingepflegt in die Software sind die beiden auch schon- benutze wieder einen Pin für beide Trigger- langsam wird der kleine UNO doch voll ringsum.
Ein digitaler und ein analoger Pin sind noch frei...und RX&TX, aber die nicht mehr lange: ein GPS ist auch schon gekauft. Wird etwas dauern, bis die Brieftaube aus Hongkong hier ist aber dann.... 8)

Was mir dann noch fehlt ist ne brauchbare Speichermöglichkeit. Der erste, grössere Plan sieht vor, einige Wegpunkte per GPS festzulegen, und dann daraus (wenn ichs hinkrieg, mittels A*-Algorithmus) ein Navi fürs Monster zu machen.

Frag mich nur, wo ich die GPS-Koordinaten ablegen soll: im EEPROM nicht gerne (unkomfortabel)- am schönsten wär ne Speicherkarte, aber die ich hier hab, brauchen alle SPI. Und die SPI-Pins, sind auch längst belegt (nich als SPI aber eben mit anderem).
Dann kann ich mir, aus der Umgebung (da wo ich mich eben so rumtreibe) mal ne Handvoll GPS-Koordinaten da ablegen und dann einfach dem Monster sagen: daunddahin wollen wir, kümmer dich....

Gibts SD-Kartenleser (schreiben wär nicht unbedingt nötig) auch für I2C?
Oder: hat jemand ne andere Idee?

Hat keine Eile: ich schätze, die Brieftaube bringt das Ding eh erst in zwei Wochen und bis dahin muss erstmal die Hinderniserkennung und die Ausweich-Strategien gescheit laufen.

Da ich heut das ganze Programm noch mal komplett überarbeitet hab (wurd unhandlich), ist in der Beziehung nicht viel geworden.

Sodele.
Die ersten Rückschläge stellen sich nun ein.

-Hauptproblem: die Hinderniserkennung. Nach vorn und hinten funktionierts beispiellos gut, aber seitlich- gibts Probleme.
Es ist wahrscheinlich nicht möglich, mit den schräg gerichteten Ultraschallsensoren eine Wand neben dem Fahrzeug richtig zu erkennen.
Der Grund ist relativ klar: durch den spitzen Winkel, in dem die Sensoren gegen die Wand rufen, wird da so gut wie nix zurück reflektiert- auf kleine Entfernungen gehts nämlich, aber dann sind die Räder schon fast an der Wand.

Ich hab da nun im Grunde drei Möglichkeiten: entweder seitlich nochmal zwei US-Sensoren anbauen (gefällt mir nicht, zum einen hab ich nur noch einen rumschwirren, zum anderen wären die kaum noch geschützt anzubauen), oder einen Sharp GPY-Infrarotsensor mit Servo schwnekbar- je nach Bedarf guckt der dann nach rechts oder links, um ner Wand folgen zu können.
Die dritte Möglichkeit wäre, die vordere Sensorplatte umzubauen, und dort einen dritten US-Sensor zu montieren.
Hat den Nachteil, dass die dann nicht mehr wirklich Crashgeschützt anzubauen wären (wegen den grossen Rädern und den monstertypischen Federwegen gehts anders nicht), allerdings hab ich mal testweise etwas solides Drahtgitter vor die Sensoren gehalten: die funktionieren trotzdem, wenn es nahe genug dran ist. Da könnte man ggf. ne Art Rammschutz bauen.

So.
Inzwischen tuckert das Monster -kollisionsfrei!- auf dem Wäscheboden herum.
Laaaaangsam natürlich, da ich noch weder nen vernünftigen Bremsalgorithmus habe noch wirklich gut autonom lenken kann.
Letzteres ist allerdings das kleinere Übel, das is schnell gemacht dann (momentan wird eher digital gelenkt: kommt links was, dann lenke nach rechts, und umgedreht).
Auch eine Rückwärts-Strategie fehlt noch, ebenso weiss er nicht weiter, wenn er grade auf ne Wand zu fährt. Kann er aber nix für: den Teil erklär ich ihm als nächstes- er soll dann, vorerst zufällig, in irgendeine Richtung abdrehen.

Was mir, neben der zuverlässigen seitlichen Hinderniserkennung fehlt, ist ein Sensor, der mir Drehungen um die Hochachse ausgibt (um festzustellen, ob und wie weit gekurvt wurde)- der Kompass ist ja nicht wirklich zur Mitarbeit zu überreden. :frowning:
Das Ding misst einfach nur-Mist.

Und wieder gibt es nen paar Neuigkeiten:

-ohne seitliche Sensoren wollt ich nicht.
Da die beiden vorderen das nicht wirklich hinkriegten (logisch, wenn man sich die Erfassungswinkel anschaut), und auch ein dritter daran nichts geändert hätte (jedenfalls nicht so viel, dasss es z.B. gereicht hätte, um parallel an einer Wand lang zu fahren), hab ich den Plan geändert: die beiden, erst im Heck verbauten US-Sensoren sind seitlich ans Auto gewandert.
Schön, einer links, einer rechts, sie gucken grad noch unter der Karosserie vor.
Damit wäre das gelöst.
Nun aber die nächste Frage: wie dann rückwärts ausparken oder aus ner Sackgasse kommen?

Nen einzelner US-Sensor bringts nicht, für starr ist der Erfassungswinkel zu gering, für schwenkbar wiederum ist er zu gross-auf diversen Videos sieht man, wie rudimentär das funktioniert.
Zweie davon, wie vorne, hätten mir nun wieder PIN-Probleme bereitet also hab ich kurzerhand nen viel genaueren Sharp GP2Y0A21YK0F-Sensor hinten montiert. Die Dinger haben einen sehr schmalen Erfassungswinkel, somit sind sie starr allerdings nicht zu gebrauchen. Also das Ding an ein Miniservo montiert und ich hab ein schönes Rückwärtsfahr-Radar.

Das alles läuft inzwischen auch, aber der Sharp spuckt momentan lediglich analoge Werte aus, die müssen noch umgerechnet werden.
Falls den jemand von euch verwendet: macht es selber. Die Arduino-Lib dazu hab ich ausprobiert: sinnlos.
Die Genauigkeit damit ist jämmerlich....das Ding kanns viel besser. Allerdings gibt er Entfernungen leider nicht linear zurück, da muss man ein bisschen rumprobieren, irgendwo hab ich auch ne recht brauchbare Formel für...

Wenn das auch geklärt ist, fliegt der RC-Empfänger (erstmal) raus: benutzt hab ich den bisher eh noch nie und: ich will nen zeitgesteuerten Interrupt installieren.
Das tu ich mir mit der RCReceiver-Bibliothek aufm Uno nicht an, wer weiss, ob das überhaupt klappen würde...glaub nicht.
Der Grund: ich habs viel einfacher, wenn ich einen festen "Zeittakt" hab, den ich als Basis für diverse Dinge benutzen kann.
Nebeneffekt: noch zwei digitale Pins frei-auch mal zu was nütze....

Immerhin müssen im Fahrbetrieb doch etliche Dinge im Multitasking erledigt werden, sonst wird das einfach nix.
Wenn ich da aber feste Zeittakte habe, sieht das Ganze besser aus, dann brauch ich nur die grade nicht benötigten Funktionen mittels nen paar Flag-Variablen abschalten, und wenn sie gebraucht werden (rundum die Umgebung beobachten z.B. ist selten nötig), schalt ich sie einfach wieder zu.
Beispielsweise die Servobibliothek läuft nämlich auch recht bescheiden, wenn nebenbei zu viele andere Dinge zu tun sind..

Also: es bleibt spannend....:wink:

So-wieder einiges verbessert bzw. gelöst:

-der Button vom Joystick wurd bis vor kurzem über digitalRead eingelesen. Das klappte im Prinzip auch, aber als Notaus z.B. eher selten, da im autonomen Modus einfach der Button nicht oft genug abgefragt wurde.
Jetzt hab ich das umgeschrieben: nun löst ein Druck auf den Button nen Interrupt aus, der dann wiederum ein Flag ändert. Damit wird dann (ausserhalb der ISR natürlich) ds Fahrwerk (Regler und Lenkservo) ein-oder ausgeschalten.
Hab nen Tag gebraucht, um drauf zu kommen, wie man das entprellt-nun funktionierts. 8)

So kann ich nun jederzeit Antrieb und Lenkung stoppen, oder eben auch aktivieren.
Natürlich wird es auch auf dem Display entsprechend angezeigt.

Nebenbei grübele ich, ob ich eine "Kamera" verbauen sollte. Keine richtige, damit käm der Dino eh nicht klar, sondern eine sehr rudimentäre, sowas wie 8x8 Pixel oder ähnlich. Da das Monster im freien agieren soll (später.....) könnt man die auf den Boden richten, und eine Art "Linienfolger" draus machen, um z.B. Wegränder oder Fahrbahnmarkierungen zu erkennen.
Dafür brauchts ja nicht allzu viel, es reicht, wenn am Übergang bisschen Kontrast vorhanden ist.
Optischer Maussensor, mit geänderter Linse, vielleicht? Immerhin muss das Ding wenigstens auf 10cm arbeiten können, das klappt mit ner Maus erstmal nicht...oder gehts einfacher auch??

Jemand dazu Ideen?

Eine richtige Kamera wäre auch problemlos möglich. Die Verarbeitung soll dann nur nicht über den Dino gehen. Beispiel Wifi Cam. Dann müsste man aber Laptop/Tablet mit nach draussen nehmen.

Linenfolger? Das könnte schwierig werden, da doch ein bisschen Power in dem Gerät hast. Auf der Makerfaire hatten die auch wieder diese kleinen Robotor die einer solchen Linie folgen. Das Problem ist, in schnell hab ich es noch nicht gesehen.

Was jedoch interessant wäre, war aber die RC-Fernbedienung können muss, wäre eine Vibration, sobald dein Auto eine weiße Linie anfährt. Ähnlich wie im Auto, wenn man über die geritzen Fahrbahnbegrenzungen fährt.

Hm-ich glaub, du hast mich missverstanden.
Das Einsatzgebiet wird grösstenteils eher Feldwege oder sowas sein.

Quer über die Wiese kommt das Ding eh nur bis paar cm Grashöhe noch vernünftig durch, von daher möchte ich einfach, dass Übergänge (Weg-Asphaltiert,Dreck am Rand usw.) erkannt werden, und dann eben schön am Rand langgefahren wird, auch wenn das GPS, auf das ich ja warte, sagt: über die Wiese, is kürzer...
Von daher brauch ich weder eine hohe Auflösung noch allzu viel Rechnerei dabei. Im Grunde sogar so: je unschärfer, umso besser, ich will da einfach auswerten: links hell, rechts dunkel->da fahren wir mal lang.

NiboBee und Co können sowas- der hat simple IR-Sensoren nach unten gerichtet, mit denen er mühelos z.B. an ner Fliesen-oder Teppichkante lang hangeln kann. Allerdings funktioniert es so simpel nur bei einigermassen gutem Kontrast, und auf sehr geringe Entfernungen. Bisschen besser brauch ich es schon. PC-Mäuse können das ja, und ich hab auch ne Seite gefunden, wo sowas per Dino ausgewertet wird, aber ob es outdoortauglich ist??
Und: ich weiss schliesslich nich alles, eventuell gehts noch einfacher?

Stimmt, NiboBee hießen die Teile. Naja, da kann ich dir leider nicht weiterhelfen. Habe keinerlei Projekte bereits gemacht oder geplant, die sowas benötigen.