seltsam, dass meine links alle funktionieren. wahrscheinlich liegt es daran, dass ich keine conrad-links verschicke. und du kannst ruhig davon ausgehen, dass ich dinge überprüfe bevor ich was behaupte...
btw. den ESP hatte ich schon, wg. Wifi...
Druckbare Version
seltsam, dass meine links alle funktionieren. wahrscheinlich liegt es daran, dass ich keine conrad-links verschicke. und du kannst ruhig davon ausgehen, dass ich dinge überprüfe bevor ich was behaupte...
btw. den ESP hatte ich schon, wg. Wifi...
Das mit den Conrad-Links ist nichts neues..aber wer kauft da auch, hehe.
Die meisten anderen funktionieren- ich setze ja auch hin und wieder einen....
Hab mir dein Dokument mal angesehen....du willst BT _und_ Wifi nutzen?
Auch, wenn mir nicht ganz klar ist, warum beides- wieso nimmst du dann nicht einfach nen RasPi?
Schon der ZeroW hat beides an Bord...und kostet nun wirklich nicht die Welt (um die 15 Mäuse).
Linux kennst du ja eh schon (sehr hilfreich, wenn man mit RasPi's spielt)...den Mega kannst du trotzdem die Steuerung der Antriebe machen lassen. Das können die besser als ein Pi, zumindest, wenn man den mit Python programmiert.
Ne Kamera könntest du dann auch ganz einfach noch an Bord holen...
Ich bin nicht sicher was und wann sinnvoll ist, wollte mir beide möglichkeiten offen halten...Zitat:
Zitat von Rabenauge
Und - ich hatte den eindruck, dass es hier von manchem als zu viel des guten gesehen wird wenn man schon den ESP nimmt und den nicht in allen belangen nutzt :-) - und den RasPi? Ein overshoot ohne gleichen, oder? Einen hätte ich ja auch bereits
Anhang 34942
habe ich mir 2012 mal gekauft, nur ein bischen damit rumgespielt, also nicht richtig warm geworden damit. Wahrscheinlich schon total veraltet...
Das ist aber kein muss mit python?Zitat:
Zitat von Rabenauge
das ist allerdings ein argument. Also nach ZeroW suchen? Oder doch was anderes?Zitat:
Zitat von Rabenauge
ob du den zero nimmst oder den alten rpi ist das gleiche, beide haben nur 1 cpu und beide haben wahrscheinlich 512mb, eventeull hat der alte auch nur 256mb, was bei kamera nutzung dann nur noch 128mb sind.
ich habe jetzt einen zeroW bestellt :-), es dauer ein paar tage bis der kommt...Zitat:
Zitat von morob
Das zusammenfügen der zwei codeteile hat gut funktioniert, muss noch die eingestellten entfernungen ausgiebig testen. Den mittleren vorderen US-sensor wollte ich nach "schräg-unten" ausrichten und so mögliche "negative hindernisse" im boden messen zu können. Bin gespannt ob und wie das funktioniert :-( - gottseidank funktioniert nun die fernbedienung, die ich im notfall als bremse einsetzen kann...
Frage: hat schon jemand versucht von einem HC SR04 einen ping zu schicken und den von einem anderen SR04 zu empfangen?
Hatte ich mal versucht- erfolglos.
Aber sehr viel Mühe hatte ich mir bei dem Experiment auch nicht gegeben...
Bin nicht ganz sicher, aber ich glaube, die Dinger gehn nur dann überhaupt auf Empfang, wenn sie vorher gesendet hatten.
Du willst also Bodenabsätze per Ultraschall finden- da bin ich mal sehr gespannt. Meiner Meinung nach geht das schon-wenn der Sensor steil genug nach unten schaut- ab etwa 45° dürfts aus sein.
Zum RasPi: tu dir bitte nen Gefallen, und benutze _nicht_ das neueste Raspian. Gut möglich, dass es auf den 4ern brauchbar läuft- auf den 3ern eher erbärmlich- und aufm Zero auch.
Jessie läuft sehr gut.
Und nein, natürlich muss man nen Pi nicht mit Python quälen, das geht auch in C- nur dann _richtig_ C- und nicht das, was wir von den Arduinos kennen.
Allerdings: für Python gibt es halt die meisten Bibliotheken...leider.
Ich bin da auch noch hin-und hergerissen: einerseits ist Python genauso ein Blödsinn wie Java: ich brauche nen schnelleren Rechner, damit ich den dann mit nem Bytecode-Interpreter ordentlich ausbremsen kann- andererseits kriegt man in Python schneller was fertig (wobei die Programmiersprache irgendwas von Kindergarten hat, so richtig Spass dran hab ich nicht).
rpi, jessie wird kaum noch unterstützt, stretch ist besser und auch stabil, mit dem rpi4 gebe ich dir recht, wenn möglich nimm einen rpi3
so,
nun habe ich ein paar tage codemässig gebastelt...
Es stellt sich immer deutlicher raus, dass die beiden aktivitäten - fahren und auf hindernisse zu achten - nur unbefriedigend mit einem controler (mega 2560) durchzuführen und nur mit unbefriedigenden qualität von beiden ergebnissen zu schaffen ist. Entweder ist das fahren zu ruckelig und auch zu laut, oder die hindernisserkennung sehr unbefriedigend... Und auch das blinde vorwärtsfahren um anschließend anzuhalten und zu messen ist nicht schön. Man muss auch auf plötzlich auftauchende hindernisse reagieren können...
Würde bedeuten, dass man z.b. für die US-ortung von hindernissen einen nano zusätzlich einsetzt. Platzmässig sicher kein problem :-) , zwei probleme (ich habe mich an die umschreibung herausforderung immer noch nicht so richtig gewöhnt) sehe ich:
- das flashen habe ich bisher mit einer USB verbindung von aussen zum mega gelöst, das wird nun bei zwei, später mit dem zeroW sogar drei controlern und drei USB anschlüssen zu umständlich und zu unübersichtlich. Ich muss ja nicht über USB gehen, ich könnte auch die TX/RX0 pins auch direkt nutzen. Frage hierzu: kann man mit einem drehencoder (nur als beispiel) die TX/RX signale zum jeweils zuständigen controler durchschalten? Oder andere idee?
- die kommunikation zwischen den cotrolern über I2C ist ein neues gebiet für mich (bisher war es nur der mega und das LCD display), aber es ist nicht das erste neue gebiet :-)
früher gab es sowas mal für serielle schnittstellen :D
ich werde das problem anders lösen, ich werde die microcontroller an den raspberry pi anschliessen und dann bei notwendigkeit von da programmieren. ich kommuniziere ja zwischen rpi und mc.
genau :-)Zitat:
Zitat von morob
heisst: ich schreibe den sketch über WLAN von meinem PC aus auf dem raspberry pi (wo die arduino IDE installiert ist) und übertrage es dann auf den jeweiligen mc?Zitat:
Zitat von morob