outdoor I

[Rabenauge]

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).

[morob]

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

[inka]

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

[morob]

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.

[inka]

früher gab es sowas mal für serielle schnittstellen

genau

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.

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?

[morob]

es gibt eine angepasste version auf der kommndozeile für arduino für den rpi.

[Klebwax]

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.

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

[morob]

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.

[Rabenauge]

Du kannst auch noch anders vorgehen (hab ich auch schon gemacht): den Arduino direkt vom Pi aus mit der Arduino-IDE programmieren.
Das funktioniert einwandfrei, auch wenn complilieren ein _bisschen_ länger dauert, als gewohnt.
Selbst ohne ein Display am Pi geht das: ich benutze (aus Bequemlichkeit) einfach VNC- somit kann ich gemütlich am Laptop sitzen, und via WLAN auf dem Pi die IDE starten, und so bedienen als liefe sie auf dem Laptop.

[inka]

so sieht die bestückte platine aus (noch ohne steppertreiber)


das hier alle unbestückten pinns det atmega ausgeführt sind ist super, bei der RAMPS platine musste ich die mühsam anlöten. War ja auch nicht für meine anwendung gedacht, sondern für einen 3D drucker, so gesehen war das auch ok...