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.
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.
das leben ist hart, aber wir müssen da durch.
ich habe jetzt einen zeroW bestelltZitat von morob
, es dauer ein paar tage bis der kommt...
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?
gruß inka
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).
Geändert von Rabenauge (14.04.2020 um 17:04 Uhr)
Grüssle, Sly
..dem Inschenör ist nix zu schwör..
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
das leben ist hart, aber wir müssen da durch.
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
- 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
gruß inka
früher gab es sowas mal für serielle schnittstellen
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.
das leben ist hart, aber wir müssen da durch.
genaufrüher gab es sowas mal für serielle schnittstellen
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?
gruß inka
Das sehe ich ganz anders. Auch wenn ich kein AVR-Fan bin, ist der Mega2560 schon ziemlich kräftig. Nur mal so zum Vergleich, obwohl die "MIPS" nicht so wirklich vergleichbar sind: für den Mega werden 16 MIPS angegeben, für den ersten PC mit 8088 0,75 MIPS und für die ersten 386 2,15 MIPS (und da lief schonmal Windows drauf). Um deine Aufgaben zu schaffen hat der Mega ausreichend MIPS und eine Menge eingebaute Hardware zur Unterstützung.
Ich versuche mal ein Konzept zu skizzieren, wie das IMHO machbar ist. Es bietet sich an, mit den Steppern anzufangen. Wenn ich mich richtig erinnere, taktest du mit 4ms, wenn es mal etwas schneller sein soll, könnten es auch 2ms sein. Ich würde also einen Timerinterrupt mit ca. 2ms aufsetzen. Von diesem werden unabhängig von der Mainloop die Motoren bedient. Gleichzeitig werden alle Schalter und Kontakte eingelesen und entprellt. (Auf dem Arduino gibt es das eigentlich schon, dort werden z.B. die Millis bearbeitet, es wird aber vor dem User versteckt, mit ein Grund, daß ich kein Arduino-Fan bin).
Nun zu den US-Sensoren. Eigentlich sind sie ein schlechtes Design. Als sie mal erfunden wurden, waren sie reine Hardware bestehend aus Treiber, OP-Amps und Komparator. Die echte Auswertung musste der µC machen. Soweit war das in Ordnung. Der neueste Schaltplan, den ich gesehen habe, hat aber einen eigenen Prozessor drauf, der das eigentlich erledigen könnte. Um aber mit den alten Teilen kompatibel zu sein, erzeugt der die gleichen Signale wie sie. Aber auch dafür hat der Mega Unterstützung, den Input-Capture. Damit kann man das zeitliche Eintreten einer Taktflanke automatisch aufzeichnen, ohne den Prozessor zu blockieren. Es gibt davon mehrere Einheiten, damit kann man auch mehrere Sensoren, möglicherweise abwechselnd, laufen lassen.
Die Kommunikation lässt man ebenfalls aus ihren Interrupten laufen und kann sich in der Mainloop mit der Routenplanung beschäftigen oder PI auf hunderttausend Stellen ausrechnen.
Die Vorstellung, daß das Aufteilen der Aufgaben auf mehrere Prozessoren einem das Leben erleichtert, ist trügerisch. Am Ende ist der Aufwand, die µCs zu überwachen und zu synchronisieren und dabei kein Ereignis zu verpassen größer, als alles mit einem zu erledigen.
MfG Klebwax
Strom fließt auch durch krumme Drähte !
also bei mir läuft das nach eva prinzip, kommunikation kommt noch vor dem a also ein evka
praxis erfahrung in 2 wochen auf dem 2560, mit 6 x hsr04, mal schauen.
das leben ist hart, aber wir müssen da durch.
Ack.
Kann irgendwie nicht sein, dass 64000 Befehlszyklen (4ms) und 6 Timer für diese Aufgabe nicht reichen.
Berechtigungen
Zitieren
Lesezeichen