Projekt Mähroboter

[Feuerring]

Update ...

habe gestern mit mehreren Arduino(Nano) als I2C-Slave und einem Arduino(Nano) als I2C-Master verscheide Situationen durchgespielt,
um zu sehen wie sicher der I2C-BUS ist.
Dabei habe ich festgestellt, das ich was wichtiges übersehen habe, ein abgeschaltetes Modul zieht über die Schutzdioden des 329p den I2C-BUS (SDA/SCL) runter,
bedeutet ich muss diese PINs sowie die Not-AUS-Leitung beim deaktivieren des Modul von der BUS-Platine trennen, dazu werde ich die Level-Shift-Schaltung von NXP nehmen
die Gates der drei MOSFET (IRLML2402) werden dann mit über den BUS-Anschluss POWER(EN) im jeweiligem Modul mit geschaltet geschaltet.

Damit der Master handlungsfähig bleibt bekommt er einen Festen Platz auf der Bus-Platine, diese Slot kann über eine direkte Steuerleitung vom restlichen TWI-Bus getrennt werden,
die beiden "PCF-8574" sind da aber von nicht betroffen und bleiben mit dem Master direkt verbunden.

Sollte es zu einer Störung auf dem I2C-Bus kommen, wird über direkt gestaltete Leitung (NOT-AUS) alle Aktoren erst mal abgeschaltet,
dann kann der Master, das oder die störenden Module abschalten (neu-starten) ...

Auch musste ich festgestellten, das die Bascom Befehle ( I2creceive / I2csend ) mir mehrmals die Hauptschleife do / Loop zum stehen gebracht haben, ohne das eine Aktivität auf dem BUS vorlag ...
werde deswegen den I2C-Master ebenfalls direkt über die TWI-Register ansprechen, so wie ich es bei den TWI-Slave auch schon umgesetzt habe,
werde mich dabei an der hervorragenden Beschreibung TWI-Praxis orientieren.

So kann ich besser auf Fehler-Situationen reagieren und auch selber Timeouts festlegen ... Das Projekt mit den aufgeteilten Funktionen über Module, Fällt oder Steht mit der sicheren Kommunikation der Module ...

[Ceos]

Auf was für einem Controller basiert der Arduino? Hört sich nach einem Atmel Problem an .... der I2C benutzt SMBus Logik und erfordert als Slave sog. Clock Stretching! Wenn der Slave seine Adresse hört und ein Datenbyte empfangen wurde, hält er die Clock Leitung auf Low bis die Programmlogik das Byte aus dem Empfangsregister kopiert ... das geht maximal 25mS gut, danach zwingt der Master wegen SMBus Logik ein erneutes Senden und hängt sich dabei weg ... während der Slave munter auf weitere Bytes wartet, der Bus ist dann in einem Konfliktzustand

[Feuerring]

Update ...

heute habe ich mich noch mal mit dem Power_Management der Module beschäftigt ...

Der Master kann darüber die Module einzeln abschalten und so auch bei Störungen dieses neu starten,
zum Glück habe ich heute eine Lieferung MosFet bekommen,
denn alle Ports vom Modul müssen vor dem Abschalten vom System-BUS getrennt werden.
Der abgeschaltete Controller zieht sonst alle Leitungen runter.

Schaltet der Master das Modul ein Power_EN = HIGH wird das Modul und alle angeschlossenen Baugruppen mit Strom versorgt,
der PIN PD6 wird als Ausgang geschaltet und auf 1 gesetzt, durch das Power_EN am FET wird dieser PIN aber auf LOW gezogen.

Schaltet der Master nun auf Power_EN = LOW werden alle Leitungen vom BUS getrennt, am PIN PD6 liegt nun HIGH an und erhält so die Stromversorgung für das Modul, in einer Timer-Routine wird dieser PIN abgefragt, ist dieser HIGH wird zu einem Label (Abschalten ) gesprungen,
alle wichtigen Parameter können nun ins EEProm geschrieben werden, danach wird PD6 auf LOW gesetzt, die abschalt Routine wartet nun
in einer do / Loop Schleife solange bis das Modul aus ist ...

[Feuerring]

Vor lauter Begeisterung für diese Technik, muss man natürlich auch die Sicherheit berücksichtigen.

Ich plane die rotierenden Klingen hinter ein Art Käfig / Kamm laufen zu lassen, weiterhin bekommt der Bott ein Cover,
dieser wird recht weit runter gezogen und wird mit Gummi-Dämpfer am Grund-Modul befestigt ...
so kann ich rundherum ein anstoßen oder anheben des Cover registrieren und die Mäh-Antriebe sofort stoppen ...
So ein Bot wird nicht gleich beim ersten Lauf zu 100% funktionieren, ist eher ein Projekt was über mehrere Jahre immer wieder überarbeitet werden muss.
Der Bot wird anfänglich immer nur unter Aufsicht laufen, erst wenn ich mir sicher bin das alles 100% funktioniert, kann / soll er auch unbeaufsichtigt seine Arbeit verrichten.

Hat der Bot dann eine Störung schaltet er im GO-HOME Mode um und fährt in seine Garage oder bleibt einfach stehen ...
bei meinem Projekt wird der Bot Rechner (PC) unterstützt funktionieren und immer eine Funk-Verbindung zum selbigen aufrecht halten, die Mäh-Programme werden dann vom PC aus gesteuert ...

[Bernd_Stein]

Hallo,

ich finde ein guter Ansatz, um schneller das Erwünschte zu erreichen kann sein, eine bereits gut funktionierende Plattform zu nutzen. Damit meine ich einen gebrauchten Rasenmähroboter ( RMR ) zu erwerben und diesen nach seinen Wünschen umzugestalten.

Der RoboMow RL500 ist ein äußerst begehrtes Bastelobjekt und es gibt jede Menge Informationen über diesen RMR.

https://www.roboternetz.de/community...l=1#post602229


Bernd_Stein

[Feuerring]

dann mal mit nem Kollegen drüber reden und plötzlich sieht man den Wald wieder den man vorher vor lauter Bäumen einfach nicht gefunden hat

manchmal braucht man einfach nur eine andere Info " z.B. ... wieso macht Du das denn so umständlich ?" ... wenn man sich fest gebissen hat, sieht man oft die alternativen nicht mehr ...

Habe im Bascom-Forum leider deswegen ein Rüffel bekommen ... wollte unbedingt die I2C-Slave-Routine als Interrupt laufen lassen, und es wollte einfach nicht klappen ...

Im Zuge der Umsetzung habe ich aber festgestellt das es gar nicht so Vorteilhaft war, da noch andere Zeitkritische Interrupt-Routinen dann gestört werden ... also blieb es beim pollen in der Hauptschleife ...