NIBO2 - Test Bodensensoren

[oberallgeier]

... bin - wie 123_Hero auch - kein Löter und Bastler ... mehr für Software mit bestehender Hardware ...

Genauso sehe ich das. Ich hatte angenommen, dass bestehende Lösungen ein Hinweis für eure gesuchten Lösungen sein könnten.

[elektrolutz]

Hallo oberallgeier,

Chapeau!
Habe erstmal nur die von dir angegebenen Punkte gelesen, werde aber den Thread mal in Ruhe ab Seite 1 lesen.

... Für meinem Nibobee habe ich so eine Regelung nicht gebaut. Da ist soviel Bibliothekszeug drin, ...

Genau das ist der Punkt:
Grundsätzlich sind die Nibos so vorbereitet, dass sie eigentlich einen sehr einfachen Einstieg bieten sollen. Leider ist dazu die Doku noch nicht wirklich fertig und stellt den Einsteiger recht schnell vor große Hürden. (Die große Frage für den Programmierer: Was mache ich zuerst - die Doku oder das nächste Update )
Für etwas fortgeschrittene Anwender sind die Libs dann wieder etwas zu unflexibel, vielleicht auch nur, weil Libs / FWs zu schwach beschrieben sind, bzw. der Funktionsumfang nicht komplett offengelegt ist, oder ergänzungswürdig ist.
Um eigene Libs / FWs zu schreiben muss man dann Experte oder Profi sein.
(Das soll keine negative Kritik sein, das ist meine Einschätzung aus meinem Erwartungs-/Betrachtungswinkel.)

Hier aber erst einmal mein persönlicher Status:
Ich selbst komme aus der hardwarenahen Programmierung für Industrieanwendungen. Hardwarenah bedeutet hierbei die Nutzung vorgefertigter Libs zu eingesetzten Komponenten. C kenne ich aus der Programmierung von Visualisierungen, aber ohne besonders zeitkritische Funktionsanforderung.

Meine Nibos sind meine ersten Kontakte mit der prozessornahen Programmierung, bin da im Frühjahr 2010 recht blauäugig herangegangen. (Ziel war es, die Nibos im Bereich der Ausbildung einzusetzen: erster Kontakt mit Elektronik und Löten, erster Kontakt mit Programmierung.)
Seit dem grabe ich mich durch die Libs, Studio4 mit seinen "Configuration Options" und die umfangreichen Datenblätter der Prozessoren. Das ist spannend, aber auch sehr zeitintensiv. Bin somit grundsätzlich im Thema, bei der programmtechnischen Umsetzung aber sicherlich noch Anfänger.

Da die Prozessoren beim Nibo2 in SMD-Ausführung verbaut sind, ist zumindest der Zugriff auf den ATmega88 (ohne nicht ganz ungefährliche Lötarbeiten) nur über den I²C-Flaschenhals möglich.

[elektrolutz]

Hallo Lisbeth2010,

da workwind nun ein eigenes Forum aktiviert hat, stellt sich die Frage, wie weit und umfangreich er hier noch aktiv sein möchte und ob er auch die Zeit hat, zwei Foren zu betreuen.

Das ist zwar leider kompliziert, aber es wäre nicht schön, hier in diesem Forum Mitglieder abzuwerben, andererseits habe ich aber auch Verständnis, wenn workwind sein eigenes Forum bevorzugt. Ich hoffe, dass sich dazu ein brauchbarer Kompromiss finden wird.

Grundsätzlich wurde das Thema hier geboren, also gehört auch hier die Zusammenfassung hin.
Wenn eine Antwort von workwind ausbleibt, dann sollten wir ersteinmal zweigleisig fahren und die Einverständnis von workwind abfragen, seine Antworten hier zittieren zu dürfen.

[Lisbeth2010]

Hallo!
Frage: Warum hat workwind Zeit ein eigenes Forum zu erstellen, zu betreuen usw., aber offensichtlich keine Zeit, die einzigen aktiven User (so ca. 5-10) mit ein paar Zusatzinformationen zu füttern?
Ich bin gerade noch damit beschäftigt, mehr Infos zu den Bodensensoren und deren Einsatz zu sammeln (absorbieren), deshalb bitte ich um ein wenig Geduld, bis ich wieder etwas "emittieren" kann.
Mein persönlicher Status: Physiker und technischer Informatiker mit Kenntnis des Atmel Prozessors AT90CAN128 und stolzer Besitzer eines ASUROs (selbst gelötet!!!), der allerdings für mein derzeitiges Projekt etwas zu schwach ist.
Noch etwas: Danke für die bisherigen Inputs!
Lisbeth2010

[Hero_123]

Hi

@oberallgeier - starker tobak, Donnerwetter! Muß ich in Ruhe "verdauen" - wie hast Du denn die Plots hinbekommen (mit welchem Programm aufgezeichnet/ausgewertet)?

@Lisbeth2010 - gemäß Deinem letzen Beitrag hast Du den ASURO - somit erübrigt sich mein penetrantes Fragen nach dem Bremsweg

@elektrolutz -die Bodensensoren SIND für die Erkennung eines Abgrundes - und dienen somit der Absturzerkennung. IMHO ist die Fkt copro_stop() bzw deren Übermittelung perI²C nicht ok, denn es ist bei mir mehrmals vorgekommen, daß der NIBO2 NICHT gestoppt hat, obwohl die Bedingung dafür vorhanden war - habe dies auch dem Hersteller gemeldet. Außerdem hatte ich mal irgendwo gelesen, daß die Übermittlung per I²C nur alle 10ms läuft - das ist aber nix für eine schnelle Regelung btw...und wenn ich die ISR mit dem Aufruf von copro_stop() alle 20ms tätige....
Hast DU jetzt schon mal den Bremsweg gemessen?

die einzig saubere Möglichkeit, das hinzubekommen ist:
- die Regelung läuft auf dem programmierbaren (per ISP) Atmega88
- es wird jeder Motor EINZELN geregelt
- der Atmega88 liest die Bodensensoren SELBST ein

->das alles GEHT DERZEIT NICHT => damit ist für mich das Thema erledigt

zum Thema "eigenes Forum" - da muß ich Lisbeth2010 recht geben...

mfg

Hero_123

[oberallgeier]

... Chapeau! ...

Merci, de rien.

... wie hast Du denn die Plots hinbekommen (mit welchem Programm aufgezeichnet/ausgewertet ...

Danke für die Anerkennung, es freut mich, dass es euch gefällt, hoffentlich nutzt es etwas, da ich ja keine Coprozessortechnik habe. Aber so bekommt ihr vermutlich einen Einblick über Reaktionsgeschwindigkeit bzw. Strecke-je-Tick, über die Regelungswirksamkeit insbes. beim Bremsen, verschiedene Bremsmöglichkeiten und so.

Auswertung und Darstellung: Aufzeichnung zeitgetreu in entsprechend große Felder, nach Ablauf des Testlaufs bzw. der Messung Übertragung per UART ans Terminal. Auswertung mit dem vermutlich weltweit meistgenutzten Simulatons- und Auswerteprogramm für technische Vorgänge - Excel. Vorgehensweise ist hier ausführlicher beschrieben.

... es wird jeder Motor EINZELN geregelt ...

Ganz meine Meinung. Damit das nicht zu sehr den normalen Programmablauf beeinflusst, läuft bei mir die Regelung der beiden Motoren zeitlich versetzt - mal der eine, mal der andere - siehe erstes Codefenster im Link. Übrigens regelt der asuro AFAIK nur einen "gemittelten" Motor und "schummelt" durch einen offset die Unterschiede rein.

[OT]Reg elungstechnik war für mich ziemlich mühselig. Ne vierLoch in der Klausur - vor vielen Jahren - deutet ja auf keine allzugroße Liebe hin. Aber wenns mal sein muss, dann muss man eben. Übrigens gibt es bei mir noch ungelöste Details - aber eher Nachkommastellen - die mir Kopfzerbrechen machen und deren Lösungsversuch ich schiebe und schiebe und schiebe. Stichwort dazu z.B. lückenlose und drehrichtungstreue Tickbilanzierung, damit Entfernung- und Richtungsrechnung genauer werden und fast nur noch der Räderschlupf als Fehlerquelle bleibt.[/OT]

[elektrolutz]

Hallo zusammen,

bin gerade mal die Belegung des CoProz laut Schaltplan durchgegangen.
Der ist bis zum letzten Pin ausgereizt.
Leider sind die etwas zeitunkritischeren 5 Abstandsensoren auf den CoProz verdrahtet und die zeitkritischen Absturzsensoren liegen auf dem HauptProz. Hier möchte ich als einigermaßen erfahrener Löter aber nicht herumbrutzeln.
Mit recht überschaubarem Lötaufwand könnte man aber die Absturzsensoren fühlerartig mit schmalen Adapterplatinen in Fahrtrichtung vor den Nibo2 verlegen. Den im ungünstigsten Fall nur 20mm kurzen Bremsweg (3 Löcher auf der Odo-Scheibe - Mitte Sensoren bis Mitte Gleitpad) könnte man so recht einfach mindestens verdoppeln.

@Hero_123,
meine Anmerkung zu den Bodensensoren als Absturzsicherung war mit etwas Sarkasmus gespickt.

Mit dem Bremsentest tüftel ich derzeit noch ein wenig herun. Habe beobachtet, dass die Erkennung eines Abgrundes durch die Sensoren durch einige Faktoren drastisch unterschiedlich ausfällt. Offensichtlich beeinflusst das Umgebungslicht die Erkennung der Sensoren nicht unerheblich, auch scheinen fremde IR-Quellen die Sensoren zu stören. Größtes Problem ist aber die plausible Erkennung einer Tischkannte, bei einer rechtwinklig geschnittenen Holzplatte (ca. 15mm stark) wird der Abgrund erst richtig erkannt, wenn der jeweilige Sensor schon ca. 5-10mm über den Rand hinaus ragt - bedeutet, der zulässige Bremsweg verkürzt sich um diese 5-10mm. Bei meiner realen Tischkannte am Arbeitstisch ist die Kannte abgerundet, ab Beginn der Abrundung ragt der Sensor zur sicheren Erkennung bis zu 15mm hinaus - der Bremsweg bis Mitte Gleitpad dann im ungünstigsten Fall nur noch 5mm.
Diese Werte habe ich durch händisches Verschieben meines Nibo2 ermittelt.
Simuliere ich den Abgrund durch eine schwarze Fläche verhält sich die Sensorerkennung nicht vergleichbar zu einer Tischkannte und reagiert zudem auf matte und glänzende Oberflächen sehr unterschiedlich.
So Suche ich erst mal nach einer Lösung, den tatsächlichen Bremsweg als Wegstrecke mit einem Messstab nachmessen zu können.

Ich Suche also nach einer Lösung, den Sichtbereich der Sensoren zu begrenzen und gleichzeitig die Einwirkungen fremder Lichtquellen abzuschotten, ohne dabei die Bodenfreiheit zu stark einzuschränken. Muss mal schauen, was ich aus schwarzen Pinselborsten machen kann.

[Hero_123]

Hi elektrolutz

Bodensensoren beim NIBO2 - der Einfluß des Streulichtes/Umgebungslichtes ist klar, da die Sensoren ja nicht abgeschirmt sind (da weist der Hersteller aber irgendwo in seiner Doku drauf hin). Abschirmung - gute Idee. Sensoren weiter nach vorne zu verlagern -> Ändern der HW (naja!!) -> Abstandserkennung muß darauf angepasst werden (ist sw-technisch kein Problem)
Sinnvollerweise müßten sowohl Boden- als auch Abstandssensoren beim Atmega88 eingelesen und verarbeitet werden. Regelung müßte auch geändert werden, ebenso ISP für den Atmega88-> FAZIT es muß ein NIBO3 her

mfg

Hero_123

[workwind]

Ich könnte eine Funktion zum "aktiven" Bremsen in den COPRO bzw. MOTCO Code einbauen: Der Strom würde solange in entgegengesetzter Richtung fliessen, bis die Ticks von der Odometrie das erste mal in die andere Richtung gezählt würden. Danach würde der jeweilige Motor direkt abgestellt werden. Damit sollte der Roboter nahezu direkt anhalten...

[elektrolutz]

Hallo workwind,

das hört sich sehr gut an.
Das wäre dann ein neuer Befehl, der aus einer Interrupt-Routine aufgerufen werden kann und die Interrupt-Verarbeitung nicht abschaltet!