Jump to content

baboboy

Members
  • Gesamte Inhalte

    11
  • Benutzer seit

  • Letzter Besuch

baboboy's Achievements

Newbie

Newbie (1/14)

0

Reputation in der Community

  1. Hallo, dein Post ist zwar schon etwas älter, trotzdem möchte ich noch ein paar Anregungen geben. Vielleicht hilft es dir ja noch weiter, oder jemand anderes stößt auf dieses Thema. Zum Thema Kamera und OpenCV: Wenn du Personen detektieren möchtest, ist das natürlich vom Rechenaufwand her etwas heftiger. Vom Programmieren her sollte es allerdings kein Problem sein, so etwas kann man in OpenCV mit ein paar Zeilen Code erledigen. Dazu verwendet man einen sog. Cascading Classifier. Diesem übergibt man ein XML-File, das Merkmale der Objekte beschreibt, die man gerne erkennen möchte. Diese XML-Files werden mit einer großen Menge an Bildern und speziellen Trainingsalgorithmen erstellt. Allerdings hat diese Arbeit (was bei der Objekterkennung mit Abstand die Meiste ist) bei so einem gängigen Objekt wie einer Person schon jemand für dich erledigt (einfach mal nach Classifier HOG suchen). Wegen der mangelnden Echtzeitfähigkeit würde ich mir keine Gedanken machen. Zum einen sind diese Algorithmen für den Einsatz mit schwächeren Prozessoren optimiert (die Gesichtserkennung auf einer Digitalkamera funktioniert nach einem ähnlichen Prinzip), zum anderen ist eine hohe Latenzzeit für dieses Einsatzgebiet in Ordnung. Selbst wenn es 1s dauert deine Objekterkennung durchzuführen, dann wird es halt mit 1s Verzögerung erkannt, dass jemand den Raum betreten hat. Es ist aber gar nicht unbedingt notwendig Personen zu detektieren. Wenn sich niemand im Raum aufhält, dann bleibt der Raum unverändert (wenn man nicht gerade das Fenster filmt). Also könnte man einfach in regelmäßigen Abständen (z.B. jede Sekunde) ein Bild aufnehmen und dann die zwei aufeinanderfolgenden Bilder vergleichen, indem die Pixel voneinander subtrahiert werden. Wenn sich dann eine gewisse Anzahl an Pixeln stark voneinander unterscheiden, kann man davon ausgehen, dass sich etwas im Raum bewegt, sich also eine Person darin befindet.
  2. Hallo jgmischke, die Idee finde ich interessant. Die Kombination aus Feder und Wegmessung erinnert mich an die Kraftmesser, die wir früher im Physikunterricht verwendet haben. Du solltest natürlich vorher wissen, welche Kräfte ungefähr auftreten könne und eine entsprechende Feder auswählen. Eine Feder mit linearer Kennlinie hat den Vorteil, dass die Umrechnung Weg->Kraft einfach ist. ein Problem sehe ich im langen Weg eines Linearpotis. Angenommen auf der rechten Seite deines Roboters ist mehr Last, dann werden die Beine dort weiter eingedrückt. Dadurch bekommt der Roboter eine gewisse Schräglage und die Last verteilt sich noch weiter auf die rechte Seite => die Beine werden noch weiter eingedrückt. Aber ich denke wenn der Federweg sehr klein ist im Vergleich zu den restlichen Maßen deines Roboters, sollte es klappen.
  3. Um die Schwierigkeiten mit Timing, Taktleitung etc. zu umgehen, verwende ich keine serielle, sondern eine parallele Schnittstelle. D.h. die Bits werden nicht nacheinander über eine Leitung, sondern gleichzeitig über mehrere Leitungen gesendet. Pro Bit verwende ich 1 Leitung. Wie ich bereits geschrieben habe möchte ich mindestens 8 Bit senden. Ich benötige also mindestens 8 Leitungen von TF zum Arduino Board. Bei TF kann ich das IO Bricklet verwenden, das hat genug Ausgänge. Beim Arduino Board habe ich allerdings nur noch 4 Pins frei. Deshalb benötige ich einen sog. "Portexpander", z.B. diesen hier: https://www.adafruit.com/products/732 Das ist ein integrierter Baustein, der über den I2C-Bus an den Arduino angeschlossen werden kann. Für den I2C-Bus werden lediglich zwei Pins benötigt (SCL für den Takt und SDA für die Daten). Ich erweitere also mein Arduino Board um 16 weitere IOs. Leider kann ich die IOs nicht ganz so verwenden, wie die normalen IOs des Boards. Wenn ich abfragen möchte, was an den Eingängen anliegt, muss ich einen entsprechenden Befehl über den I2C-Bus senden. Der Portexpander antwortet dann darauf, indem er den Status der Eingänge zurücksendet. Je nach Geschwindigkeit des Buses, kann dieser Vorgang bis zu einigen hundert µs dauern. Das klingt erstmal nicht viel. Allerdings weiß ich nicht, wann TF Daten an meinen Arduino schicken wird. Ich muss also permanent die Eingänge des Portexpanders abfragen, was viel Rechenzeit benötigt. Also verbinde ich noch zusätzlich einen Ausgang von TF direkt mit dem µC des Arduinos und konfiguriere diesen Pin so, dass z.B. bei steigender Flanke ein Interrupt ausgelöst wird. Ich kann dann mit TF die Daten an den Portexpander anlegen und anschließend einen Interrupt auslösen um dem Arduino Board zu signalisieren, dass es sich jetzt die Daten vom Portexpander abholen kann. Es werden also nur Daten über den (vergleichsweise langsamen) I2C-Bus übertragen, wenn es auch wirklich neue Daten gibt. Ich habe noch ein Bild mit dem Konzept angehängt, dann sollte es klarer werden.
  4. Ich mache es jetzt folgendermaßen: An TF kommt ein IO-Bricklet, an den Arduino ein Portexpander. Portexpander und IO-Bricklet werden mit der benötigten Anzahl an Datenleitungen verbunden. Zusätzlich wird ein Ausgang des IO-Bricklet direkt mit dem Arduino verbunden. Wenn TF eine Motorgeschwindigkeit ändern will, werden die Daten als einzelne Bit an den Portexpander angelegt. Anschließend löst TF am Pin des Arduino einen Interrupt aus. In der Interruptfunktion des Arduino werden die Daten des Portexpanders ausgelesen. Vielleicht etwas umständlich, aber ich bin mir zumindest sicher, dass ich das ohne Probleme hinbekomme.
  5. Ich muss die Geschwindigkeiten für vier Motoren übertragen. 4 Motoren -> 2 Bit Richtung -> 1 Bit Für die Geschwindigkeit wäre dann noch 1 Bit übrig, was zu wenig ist. Ich bräuchte mindestens 5 Bit Auflösung für die Geschwindigkeit. Vielleicht ist die Idee mit dem Portexpander am Arduino doch nicht so schlecht. Oder ich schiebe 2x hintereinander 4 Bit rüber.
  6. Ich habe mich schon recht viel mit µC beschäftigt, habe allerdings nicht viel Erfahrung, wenn es um TF oder Linux geht. Keine Ahnung, ob das aufwändig ist, aber für mich klingt das erstmal nicht ganz trivial. Das Ziel ist es einfache Daten von TF an Arduino zu senden. Der Weg auf dem das geschieht ist mir dabei egal, solange der Weg kurz ist und wenig Stolpersteine hat. D.h. es sollte etwas sein was möglichst wenig Arbeitsaufwand erfordert und möglichst wenige Dinge enthält, die noch niemand ausprobiert hat. Ich denke ich habe den Sinn des Breakout-Bricklets zuerst falsch verstanden. Es ist eigentlich dazu gedacht, dass man es an ein anderes Bricklet anschließt und dann direkt auf die Signale des Bricklets zugreifen kann. Ich dachte zuerst es wird an einen Brick angeschlossen (wegen der Bezeichnung "Bricklet"), um eigene Bricklets zu realisieren. Die Frage ist, kann man es auch an einen Brick anschließen und dann auf Signale des Bricks zugreifen? Kann man z.B. ein selbst definiertes Adressbyte+Datenbyte auf dem I2C eines Bricks legen und diese Daten am Breakout-Bricklet abgreifen? Ich befürchte mal das geht nicht. Wenn ich mir hier im Forum andere Threads durchlese, dann widerspricht so etwas der Philosophie von TF
  7. Ich denke so blöd ist die Frage nicht Die USB-Schnittstelle ist zwar hardwareseitig bei TF und Arduino vorhanden, aber das bedeutet noch lange nicht, dass das auch von der Software her klappt (ohne dafür unverhältnismäßig viel Aufwand zu betreiben). Auf dem Arduinoboard ist der USB-Anschluss lediglich mit einem USB/Seriell-Wandler verbunden, der wiederum an den µC angeschlossen ist. Es muss also möglich sein, auf dem Redbrick eine virtuelle serielle Schnittstelle einzurichten und über diese in einem selbstgeschriebenen Programm Nachrichten zu verschicken. Hat vielleicht schon mal jemand das Breakout-Bricklet verwendet? Ist es damit möglich beliebige I2C Nachrichten zu verschicken?
  8. Hallo liebe TinkerUnity, Ich habe ein kleine Herausforderung (Probleme gibt es ja bekanntlich nicht ), bei der ihr mir vielleich behilflich sein könnt. Ich möchte, dass mein Arduinoboard mit TF kommunizieren kann. Konkret geht es darum, einfache Befehle von TF an den Arduino zu schicken. Ich habe gesehen, dass bald ein RS232 Bricklet rauskommt. Das wäre natürlich optimal, aber so lange kann ich leider nicht warten (das Projekt muss bald fertig werden ). Also ist die Frage, ob es noch eine andere Möglichkeit gibt. Am Arduino befinden sich noch maximal vier frei Pins. Ich habe mir überlegt ein IO Bricklet zu verwenden und damit softwareseitig selbst eine serielle Schnittstelle für TF zu implementieren. Ich denke zwar, dass das grundsätzlich möglich ist, aber sehr viel Aufwand bedeutet. Hat vielleicht schon mal jemand etwas Ähnliches gemacht? Eine etwas pfuschigere Idee wäre ein 16 IO Bricklet als parallele Schnittstelle zu missbrauchen. An den Arduino dann über den I2C einen simplen Portexpander dranklatschen... Bisher bin ich aber von keiner meiner Lösungen überzeugt. Ich werde das Gefühl nicht los, dass es da eine einfachere/schönere Möglichkeit gibt Wenn also irgendjemand noch frische Ideen oder Anregung hat, freue ich mich sehr
  9. Ja, das mit der Ausrichtung im Raum ist ein Problem, aber ich bin mir sicher, dass der Kompass dafür keine Lösung ist. Die Frage ist, muss sich der Roboter überhaupt drehen können? Mit den Mecanum Rädern kann er sich ja auch so in alle Richtungen bewegen, das ist ja gerade das Schöne an den Dingern. Vielleicht ist es möglich den Roboter am Anfang manuell auszurichten und dann nur noch nach vorne und seitlich zu verfahren, ohne den Roboter dabei zu drehen (kommt natürlich darauf an, wie genau der Testlauf aussieht, das kann uns nur Samuel beantworten). Wenn man vier Lasersensoren am Roboter befestigt (vorne, hinten, links und rechts), kann man sogar erkennen wenn sich der Roboter verdreht. Nämlich dann, wenn die Summe der beiden gegenüberliegenden Strecken größer wird.
  10. Auf den Kompass würde ich mich nicht verlassen. Ich habe mal etwas ähnliches mit einem Android Smartphone probiert, das war völlig unzuverlässig sobald irgendwas aus Eisen in der Nähe war. Wenn du dann noch E-Motoren in der Nähe betreibst kannst du es wahrscheinlich komplett vergessen. Aber die Abstandssensoren klingen auf jeden Fall vielversprechend.
  11. Hallo Samuel, ich glaube nicht, dass du damit deine gewünschte Genauigkeit erreichen kannst. Du brauchst zumindest in regelmäßigen Abständen wieder eine absolute Position, da dein Fehler mit der Zeit sehr groß wird. Wenn du den IMU Brick schon hast, dann kannst du ja einfach mal folgendes machen: - Laufend Beschleunigungsdaten aufzeichnen. - Mit dem Roboter an einer definierten Position beginnen, eine gewisse Strecke abfahren und anschließend genau zum Ausgangspunkt zurückkehren. - Die aufgezeichneten Beschleunigungsdaten z.B. in Excel importieren, zweifach integrieren und schauen wie nahe du bei allen Achsen an der 0 bist. Du hast bei Kurvenfahrten das Problem, dass zusätzlich eine Zentripetalkraft wirkt, die von dem Sensor als Beschleunigung wahrgenommen wird und das Ergebnis enorm verfälscht. Der Fehler kann zwar mit dem Drehratensensor rausgerechnet werden, ist aber vermutlich nicht ganz trivial. Um zumindest systematische Fehler rauszurechnen brauchst du schon ein bisschen Mathe/Physikkentnisse. Ich würde da mal nach fertigen Algorithmen schauen (Stichwort ->Sensor Fusion). Das Thema Positionsbestimmung/Navigation in geschlossenen Räumen ist ein Thema, an dem aktuell noch viel geforscht wird. Es gibt auch komplette Abschlussarbeiten, die sich nur diesem Thema widmen, vielleicht findest du da noch Anregungen.
×
×
  • Neu erstellen...