IR-bake

[Christian H]

Hi Joe,

Du hast natürlich recht, ist der TSOP7000. Der arbeitet auch nicht im Dauerbetrieb, sondern sendet eine Folge von Bytes zwischen denen jeweils eine Pause von 800us ist. Bei 8 MHz lassen sich die 455 Khz folgendermaßen erzeugen:

I = 0 
Do         'do-loop für 14 bursts mit 455 KHz 
Toggle Portd.5     ' Übertragung von bit = 1 
nop  'IR-LED an Portd.5 
nop  'Zahl der nops bestimmt burst-Dauer 
nop  'ausprobieren evtl 5 oder 6 nop besser 
nop  
Incr I 
Toggle Portd.5 
nop  'ausprobieren evtl. 4, 5 oder 6 besser 
nop 
nop 
Loop Until I = 14

Das ergibt 14 Blitze mit etwa 455 Khz und entspricht einem bit=1. Für bit =0 bleibt die LED gleich lang aus. So kann man
ein Startbit =1
einen Winkel (1 bis 128 ), Stellung des Servos auf dem die LED sitzt
ein bit zur Kennung der beiden baken
und ein Stopbit =1 übertragen

14 Blitze mit 455 Khz dauern 30 us
10 bit dauern 300 us
dann 800us Pause >>> etwa jede ms wird ein Byte verschickt.

Die links sollen nur zu Ideen anregen. Ist sicher nicht der Weisheit letzter Schluß. Problem ist immer die Alltagstauglichkeit. Wer will denn schon, falls es um Navigation in mehreren Räumen geht, mehrere Baken aufstellen und betreiben.

Grüße

Christian

[Dirk]

Leute,

ich würde meine Wünsche an ein Bakensystem für den RP6 so zusammen fassen (Pflichtenheft):
1. Es soll indoor arbeiten.
2. Die Raumgröße beträgt bis zu 5 x 5 m
3. Mit Hilfe des Systems soll der RP6:
3.1 Seine Position im Raum auf +- 5 cm feststellen können
3.2 Seine Drehrichtung (Yaw) bestimmen können
3.3 Im Raum eigenständig manövrieren können
3.4 Einen Punkt im Raum (z.B. eine Ladestation) eigenständig anfahren können
4. Die Sensoren (ACS...) und die Aktoren (IRCOMM...) des RP6 sollen (soweit möglich) genutzt werden
5. Aktive Baken sollen so aufgebaut sein, dass sie auch durch eine RP6 CONTROL M32 oder CCPRO M128 Zusatzplatine (stand alone) betrieben werden können
6. Die Anzahl von Baken soll bis 8 erweiterbar sein

[WL]

Das kommt mir alles sehr bekannt vor.................
Ich hole da mal einen alten Beitrag aus der Versenkung:
https://www.roboternetz.de/community/threads/54798-Laser-Positionsscanner
Das ganze lässt sich für 5cm Auflösung viel einfacher aufbauen.

[RolfD]

Die Lösung mit der Kombi aus IR und US aus Post #129 gefällt mir obwohl ich denke, das man sie noch deutlich verbessern bzw. vereinfachen kann.
(Rotierende) Laserbaken mögen auch funktionieren aber da halte ich den Bauteileaufwand für zu hoch gemessen an dem was man mehr erreicht als eine IR/US Bake kann.
Aber interessant sind alle Bauvorschläge.

Vielleicht sollten wir noch ein paar Wunschlisten für die Bake sammeln und dann mal durchsprechen, mit welchem Baken-Grundkonzepten man welche Wünsche am besten erfüllen kann.

Meine Wunschliste:

1. Es muss!!! indoor arbeiten, es wäre schön wenn man sie in gleicher Anordnung auch draußen verwenden kann.
2. Raumgröße bis zu 10 x 10 m
3. Position im Raum mit 3 Baken auf +- 5 cm feststellen können
4. ACS und IRCOMM des RP6 Base sollen genutzt werden
5. Alles so einfach wie möglich, alles was kompliziert oder schwierig anzufertigen ist wird die Verbreitung der Bake behindern.
6. Eine Bake sollte 2 Räume mit je 3 Messstellen/US sendern versorgen können - es reichen mir daher 6 Anschlüsse.
(wobei ich schon ausgeführt habe, das dazu mit dem IR/US Konzept nicht 6 einzelne Baken sondern nur 1 Bake mit insgesammt 6 "Satelliten" notwendig wären die lediglich die Schallgeber enthalten.)
7. Sollten wir uns auf einen Hardwareentwurf einigen können, wäre es auch schön wenn man die Software dazu gemeinsam hinbekommt oder zumindest eine Art Lib entsteht.
8. Die Bake sollte zunächst als Hardwareanforderung nur die RP6Base haben, es wird jedoch sicherlich Tendenzen geben, die M32 und andere Boards mit zu nutzen was ok ist.
9. Die Kosten für einen Raum auszustatten sollten nicht über 120-150 € liegen.

Wir sollten uns neben der Signaltechnologie jedoch auch darum kümmern, ob wir eine "Dumme Bake" und viel Code auf dem RP6 wollen, oder eine "schlaue Bake" mit eigenem Prozessor und Programm. Da ja mit Tochterboards noch zumindest ein TWIslave mit Motorsteuerung auf der Base laufen müsste, hat man nicht mehr so viel Platz.

Ich werde mir in den nächsten Wochen mal ein Versuchsaufbau der Bake mit einem AVR-Board von Polin http://www.pollin.de/shop/dt/MTQ5OTg...dule/Bausaetze
/Bausatz_AVR_NET_IO.html machen da dieses Board günstig zu bekommen und vom PC via Ethernet aus zu steuern ist. Zum Programmieren ist zwar ein ISP Adapter nötig aber den hab ich da. Damit kann ich sowohl "schlaue" wie "dumme" Baken simulieren und ggf. sogar später mal den PC mit einbinden. Ihr könnt natürlich andere Boards nutzen.

Gruß

[inka]

das wären meine (erweiterten) wünsche und vorstellung an bake 2.0:

1. aktive, „schlaue“ bake
2. bake betreiben über die M32 als master
3. eine gemeinsame hardware und library
4. ACS und IRCOMM des RP6 sollten verwendet werden
5. hauptsächlich indoor, raumgröße 5x5m
6. outdoor 10x10m (gartengröße )
7. IR/US konzept
8. position im raum auf +- 5cm festsstellen können
9. eigenständiges manövrieren im raum, eigenständiges anfahren eines punktes im raum
10. einbindung des gyro (multiIO)?
11. „tochterbaken“ - wie eingebunden, anzahl begrenzen? BT?
12. spannungsversorgung über USB
13. anschluss- / einbaumöglichkeit eines BT-moduls
14. kosten bis max 120€ für einen raum (1 mutterbake / 2 tochterbaken)

die leiterplatte von Pollin sieht gut aus, wäre ein arduino (unmenge an zusatzmodulen, leicht zu handhaben, günstige kosten) eine alternative?


mit diesen satelliten-us-gebern – wie sind die mit der „mutter“-bake verbunden?

[RolfD]

Als Logik-Board taugt eigentlich jede Hardware so lange ein paar Steuerpins abgreifbar sind und man ein Timer im Prozessor hat. Boards mit hoher Taktfrequenz haben es auch meist einfacher aber das relativiert sich ab 8MHz da meist nur schneller auf irgendwas gewartet wird. Wirklich zeitkritisch sind eher Boards unter 1MHz aber auch da kann man sich behelfen.
Das Polin Board gefällt mir deswegen besonders gut weil es noch eine erweiterung dafür gibt. http://www.pollin.de/shop/downloads/D810112B.PDF

Polin selbst hat noch weitere AVR Boards zu vertretbaren Preisen.. allerdings ohne LAN-Chip aber dafür verschiedene Sockel.
http://www.pollin.de/shop/downloads/D810038B.PDF
und
http://www.pollin.de/shop/downloads/D810046B.PDF

Man kann aber auch Arduino verwenden oder irgend eine andere AVR Plattform/Hersteller.
Unser Anbieter des Forums vertreibt z.B. auch ein Board:
http://www.rn-wissen.de/index.php/RN-Control
Wie schon mal gesagt.. wir werden mit solchen Dingen nicht die ersten sein...
Da gibts auch noch mal interessantes zum Thema ISP
http://www.rn-wissen.de/index.php/AV...leicht_gemacht
Aber auch eine m32 oder m256 kann das. Die M128 kann es bedingt auch, da dort kein c läuft muss man gucken ob das in asm geht.

Es ist nur wichtig zu wissen, ob auf dem Prozessor schon ein Bootloader drauf ist, und man Programme wie bei AREXX/RP6 über eine serielle Schnittstelle bzw. USB flaschen kann oder ob ein Programmieradapter vom Typ MKII gebraucht wird. Letzterer kann auch zum onChip-Debuggen genutzt werden und benötigt meist ein spezielles Programm wie Ponyprog oder diverse andere incl. Atmel Studio. Beide Wege funktionieren. Man kann sich ja auch ein Prozessor in so einem Board programmieren und dann ein eigenes Leiterplattendesign mit dem Prozessor überlegen. Möglichkeiten gibts da reichlich. Die Polin Sachen sind halt in Steckwanne ausgeführt wie auch die RP6 Boards, aber es spricht nichts gegen andere Systeme.
Zudem ist der RP6 wie auch das M32 per ISP zu Programmieren wenn man ihn umbaut. Man könnte also sogar den Bootloader rauswerfen und alles über ISP machen.
http://www.rn-wissen.de/index.php/RP...Programming.29
Würde ich smd-löten nicht scheuen wie der Teufel das Weihwasser, hätte ich mir auch schon längst eine pinkompatible m644 oder eine m1284 CPU auf den RP6 gelötet und würde auch über ISP proggen.
Die Frage ist halt... will man die 35 Euro für den MKii "sparen" und zahlt dafür wo anders drauf oder nimmt man doch einen und kann dafür auch sehr preiswerte/vielseitige Boards nutzen.
Ich will da niemand Vorgaben machen aber ich hab halt einen und ich könnt auch für andere CPUs mit Code vorladen.

Gruß

[inka]

ich habe mir diese hardware bestellt, ich wollte ja den RP6 mit rädern ausstatten, mit 4 antrieben und da es die RP6-base offensichtlich von der elektronik her nicht unterstützt halt mit arduino (als zweiten slave) für die motorsteuerung. Noch viel arbeit, auch mit I2C, mal schauen wie das läuft...

das arduino mega 2560 board was dabei ist, war kinderleicht zu flashen: arduino IDE installieren (linux kein problem), per USB kabel mit dem PC verbunden und los gings. Ohne was dazwischen, kein adapter, nix. Bootloader ist schon drauf....

schaust Du Dir das bitte mal an? Was mich stört, ist die programmiersprache (processing) - aber angeblich gehts auch in c++

[RolfD]

c++ ist lediglich eine Erweiterung von c und wirkt sich hauptsächlich durch Klassen aus. Der gnu c compiler (als Port für windows) (den auch winavr und Atmel Studio nutzt) kann beides. c++ brauchst du nur wenn du die Libs vom arduino nutzt oder z.B. den c't-bot ... , man kann das Ding (Arduino) aber auch in c oder asm proggen. Manche Puristen hier behaupten übrigends, c++ ist zu überladen als das man das auf einem Prozessor dieser größe verwenden könne... ich seh das anders. Man könnte auch den RP6 in c++ proggen.. aber dafür müsste man erst so schöne klassen wie auf dem Arduino bauen... und das ist laut der Puristen eben bäbä... *grinsels
Ich selbst schreib aber auch lieber in c für den AVR. c++ braucht nämlich eigentlich malloc() und malloc ist wirklich bäbä wenn man nicht grade min. nen 64MB Speicherriegel im System hat. Kann aber sein das malloc auf dem arduino anders gelöst ist.
Gruß

Nachtrag bzw. Korrektur:
Bei den Polin AVR Evaluation Boards ist schon ein Programmieradapter a la Ponyprog auf dem Board integriert. Zumindest auf dem Funkboard, auf dem anderen aber wohl auch. Man spart sich also sogar den MKii. Nur das Netio Board ggf. mit Erweiterung hat keinen.

Nachtrag:
Ein weiteren Vorteil kann c++ bei Muktitasking Systemen gegenüber c ausspielen da man mit c++ und dem new Operator bzw con-/destruktoren gut reentranten Code bauen kann. Man kommt auf Kleinprozessoren aber selten in die Verlegenheit solchen Code zu nutzen und letztlich erreicht man mit bischen Nachdenken das Gleiche auch in c.

[inka]

hallo,

zunächstmal würde ich feststellen, dass die mitgliederzahl in unserem team auf drei zusammengeschrumpft ist...

auf dieser basis sollten wir anfangen (punkte, die weitgehends in unseren auflistungen übereinstimmen)
--------------------------------------
1. aktive, „schlaue“ bake
2. eine gemeinsame hardware und library (Dirk?)
3. ACS und IRCOMM des RP6 sollten verwendet werden
4. hauptsächlich indoor, raumgröße 5x5m
5. IR/US konzept
6. position im raum auf +- 5cm festsstellen können
7. eigenständiges manövrieren im raum, eigenständiges anfahren eines punktes im raum
8. kosten bis max 120€ für einen raum (1 mutterbake / 2 tochterbaken)
----------------------------------------
Differenzen zwischen Team-Mitgliedern:
(über diese punkte sollten wir noch diskutieren und so definieren/beschreiben, dass sie dann oben aufgenommen oder gestriche nwerden können)
---------------------------------
Anzahl von baken soll bis 8 erweiterbar sein
Outdoor, dann Raumgröße 10x10m
Bake soll auch von einer M32 oder CCPRO M128 (standalone) betrieben werden können
Drehrichtungbestimmung (Yaw)
Eine Bake sollte 2 Räume mit je 3 Messstellen/US sendern versorgen können (6 anschlüsse)
Die Bake sollte zunächst als Hardwareanforderung nur die RP6Base haben
Die Bake betreiben über die M32 als master
Spannungsversorgung über USB
Anschluss- / Einbaumöglichkeit eines BT- Moduls
Definition Mutter- / Tochterbaken
Einbindung des gyro (multiIO)?
------------------------------------------

Was Hardware betrifft lege ich erst einmal vor – Arduino Mega 2560:

ich habe am montag ein board in D bestellt, geliefert wurde es heute, 14€, portofrei...

ist seehhrr weit verbreitet, kostengünstig, simpel, kein programmieradapter, wir würden damit eine „Brücke“ zwischen zwei AVR-Systemen (M32 und M2560) schlagen...
mir käme es entgegen, weil ich bereits beim Allradantrieb des RP6 solches Modul verwende...

@Rolf,
die ergänzung von beiträgen ist ungünstig, ich habe Deine zwei edits rein zufällig entdeckt...


schöne heisse pfingsten...

[Besserwessi]

Die Anforderungen an die µCs sollte man eher gegen Ende festlegen. Das ergibt sich im wesentlichen aus den Sensoren / Sendern die man verwendet. Das erste was man Festelegen sollte wären entsprechend die Signale die Gesendet werden. Was man dafür dann an HW bracht, sieht man dann - vermutlichwerden die Anforderungen für die Baken auch gar nicht so hoch werden. Beim mobilen Teil ist halt noch die Frage ob man einen eigenen µC braucht oder einfach nur etwas code und und einige IO Pins am Bot.

Bei den Zielen ist "eigenständiges manövrieren im raum, eigenständiges anfahren eines punktes im raum" schon eine eher höhere Softwareebene - das hat so direkt nichts mit der Barke zu tun.

Die erste große Frage ist in welche Richtung IR und US gesendet werden. Sowohl für IR als auch US ist das Senden wohl etwas einfacher als Empfangen. Einer der Empfänger wird am Bot sein müssen. Beim Ultraschall hat man ein ggf. störendes Echo, und damit eine merkliche Totzeit nach dem Senden - da wäre es schon praktisch wenn man nur einen Sender und viele Empfänger hätte. Bis das Echo abgeklungen ist dauert es geschätzt 0,1-0,2 s. Beim Ultraschall ist auch noch die Frage nach der Ausrichtung: die US Kapseln sind etwas gerichtet - mit einem Reflektor für einen ungerichteten Empfang hat man dann ggf. keine so große Reichweite mehr - ob das noch ausreicht müsste man wohl testen. Die IR Signal können für so etwa wie TSOPxx38 etwa 5 ms kurz sein. Bei den IR Signalen könnt man ggf. die Intensität auswerten - allerdings bringt das vermultich eher wenig um daraus die Entfernung zu schätzen, jedenfalls kaum um auf 5 cm zu kommen.


Ich sehe einige mögliche Systeme:
1) Der Bot sendet ein US Signal und die Baken anworten als IR Signal. Eine kleine Schwierrigkeit bekommt man hier, wenn mehr als eine Bake antwortet - da müsste man ggf. mit Verzögerungen arbeiten, bzw. die Signale der Baken Synchronisieren. Einfach direkt nach Empfang Antworten klapt nicht. Da bräuchte es noch einige Überlagungen zum IR Protokoll.
2) Die Baken senden US und IR, der Bot empfängt nur. Die IR Signale können hierbei in kürzeren Abständen kommen als die US Signal: wenn man bis etwa 8 Baken annimmt. hätte man etwa 1 Sekunde für je 1 US Signal. Bei IR wäre dagegen ein Zyklus von etwa 50 ms möglich (6 ms je Puls-paket), in denen jede Bake einen Pulse gesendet hat - ein schnelles Senden ist hier für die Richtungssuche hilfreich, sonst muss man recht langsam drehen. Beim Ultraschall ist auch noch die Frage ob jede Bake Ultraschall senden muss - da reichen ggf. auch ein paar weniger, schon wegen der Kosten.

3) Der Bot sendet IR und Empfängt Ultraschall. Auch hier hat man wieder das Problem, dass ggf. mehr als eine Antwort kommt, auch wenn das mit einem gebündelten IR Strahl eher selten vorkommt. Die Baken müssten sich für den Fall wohl irgendwie absprechen.

Das wären eigentlich schon die 3 einfachen Möglichkeiten, ohne eine (IR) Kommunikation in beide Richtungen. An einfachsten davon ist klar der Fall 2. Eine wesentlichen Freiheiten die man da noch hat, ist Frage der Empfänger. Beim Ultraschall ist der teilweise gerichtete Empfang (so wie der Transducer es vorgibt) wohl einfacher und auch ohne Reichweiteproblem. Da sehe ich eher wenig Motivation für den extra Aufwand für rundum Empfang. Beim IR Empfang hätte der RP6 zwar schon einen Empfänger, aber der ist nicht wirklich gerichtet, gibt also kaum eine brauchbare Richtungsinformation. Für die genaue Richtung wird man einen besser gerichteten zusätzlichen Empfänger brauchen. Theoretisch könnt man man die Richtung auch über den US machen (mit 2 Empfängerkapseln)- der Aufwand ist aber wohl relativ groß, und echos könnten stören.
Die Frage die sich bei der Richtung noch stellt, ist ob man den ganzen Bot dreht, oder einen schwenkbaren Empfänger zum Abscannen der Richtungen baut. Der Vorteil wäre halt, das man schneller und wohl auch genauer schwenken kann - das Kettenfahrwerk des RP6 ist halt nicht so präzise. Für die Baken selber ist das aber egal - das ist eine Frage wie die HW und das Programm auf dem Bot aussieht.

Nach den Ausführungen hier, sehe ich vor allem den Fall mit Baken die nur Senden (IR und US) und nur Empfängern am Bot als interessant an - oder hat da einer noch einen anderen Vorschlag ?