PC- Steuerung

[Andrew7]

Mein Endziel wäre es, zwei Asuros nebeneinander zu stellen und via Infrarot synchron fahren zu lassen.
Leider bin ich schon an einem Problem hängen geblieben;
Was bedeutet: SerRead (data,5,0) oder so ähnlich. Was SerRead und die 5 bedeuten ist mir klar. Aber was ist mit dem 0?
Ich bin mir fast schon sicher, dass dies der Fehler ist in meinem Programm.

[king_kaos]

ich zitier einfach mal aus dem asuro manual:


Will man Zeichen empfangen, ist für ASURO die Funktion SerRead () defi niert. Der erste
Parameter enthält die Zeichenkettenvariable, in welcher empfangen Zeichen abgespeichert
werden, der zweite Parameter gibt an, wieviele Zeichen empfangen werden sollen, der dritte stellt
ein Timeout dar. Werden innerhalb der eingestellten Zeit (Prozessortakte) keine Daten empfangen,
bricht die Funktion ab. Wird hier “0” eingestellt, wartete die Funktion bis alle Zeichen empfangen
wurden.


die 0 sollte nicht dein problem sein, wohl schon eher, dass asuro1/asuro2 nicht immer beide die gleichen daten empfangen. die ir kommunikation ist imo die häufigste fehlerquelle.

auf die schnelle fällt mir keine lösung ein, du könntest aber folgendermaßen vorgehen:

asuro1 ist der "leader", der daten empfängt. wenn er nen befehl erhält, versucht er ihm per ir an asuro2 zu schicken, der dann ne rückmeldung liefert. asuro2 fährt los, asuro1 erhält die rückmeldung und los gehts.

das problem wird aber auch in diesem fall die ir kommunkation zwischen den asuros sein. was ist, wenn asuro1 die rückmeldung nicht kriegt?

bin ja mal auf deine lösung gespannt...

gruß, kaos.


ach ja - um die asuros synchron fahren zu lassen würde ich auf odometrie zurückgreifen. in deinem code benutzt du nur motorgeschwindigkeit. diese wird aber wohl auch für beide asuros variieren...

[damaltor]

also die idee ist schön, aber die motoren sind zu unterscheidlich, das ist wahr. da musst du dir was anderes ausdenken. die idee ist gut, aber wird schwer, denn die ir-kommunikation ist wirklich nicht besonders toll.
was möglich wäre ist, ein übertragungsprotokoll für diese befehle zu erfnden, dass z.B. mit einer checksumme überprüft ob die richtigen daten angekommen sind. könnte evtl kompliziert werden... oder du baust eine ir-bake an den einen asuro (such mal, dann weisst du was das ist) und lässt den anderen asuro der bake hinterherfahren. dann ist das zwar nicht mehr synchron, aber sieht aus als wenn der eine asuro mit dem anderen gassi geht =)

[EDH]

also die übertragun der befehle ist mit abstand das komplizierteste.
die asuros müssen sich aber nicth nur gegenseti die kommandos (respektive bestätigungen) schicken. sie müssen immer überprüfen, ob der andere noch in reichweite ist. dazu wird einfach ständig ein "erkennungszeichen" gesendet.
aber was ist, wenn die asuros sich verloren haben, wie finden sie den anderen wieder?

mfg EDH

[king_kaos]

die asuros müssen sich aber nicth nur gegenseti die kommandos (respektive bestätigungen) schicken. sie müssen immer überprüfen, ob der andere noch in reichweite ist. dazu wird einfach ständig ein "erkennungszeichen" gesendet.

daran hab ich auch schon gedacht. aber dann is halt nix mehr mit synchronität, wenn der eine dem anderen hinterherfährt. aber gefällt mir trotzdem eigentlich sogar noch besser. leider hab ich keine 2 asuros... :(

[EDH]

häh wieseo ist das dann nicht mehr synchron? der eine asuro schickt dem anderne asuro einen befehl, und der macht das dann. synachron ist das schon. allerdigns müssen die asuros logischerweise nicht direckt hintereindander fahren
auserdem: wenn die asuros direkt hintereinander fahren sollen, wird das ganze noch mal eine ganze reihe komplizierter. asuro 2 müsste nämlich eine zeitverzögerung berechnen, mit der er die befehle ausführen muss. sonst fahren die asuros nämlich nach der ersten kurfe nebeneinandern

mfg EDH

[king_kaos]

häh wieseo ist das dann nicht mehr synchron?

also unter synchronität verstehe ich, dass a1 und a2 zur gleichen zeit das selbe tun. wenn der eine kein signal mehr von anderen empfängt, dann ist einer der beiden zu weit bzw. zu lange (nicht) gefahren => aus mit der synchronität.

aber trotzdem, die idee von 2 miteinander kommunizierenden asuros eröffnet viele neue möglichkeiten, wie verstecken oder fangen spielen. oder wie in unserem fall a2 versucht a1 zu folgen. aber is wohl die einfachste möglichkeit synchronität zu simulieren. was besseres fällt mir jetzt auch nicht ein.

[damaltor]

naja... bevor wir uns überlegen was die asuros machen sollen sollte evtl erstmal feststehen wie die übertragung gehen soll... ich habe an ein RN-Funk modul gedacht.

[Andrew7]

Danke für eure Antworten
Ich glaube ich lasse Asuro1 vorrausfahren und Asuro2 ortet ihn mit Ultraschall, misst den Abstand und korrigiert wen nötig.
\:D/

[EDH]

asuro 2 folgt dann zwar asuro1 aber synchron wird das dann beileibe nicht
ich schätze ein asuro wird sich über ultraschall nur schwer orten lassen
(kleine angriffsfläche für den ultraschall)

mfg EDH

[uwegw]

Den Tranciever könnte man noch etwas aufmotzen und mit nem Verstärker (mit separater Stromversorgung) als "Nachbrenner" und mehreren IR-LEDs versehen. Damit dürfte sich die Reichweite deutlich steigern lassen.
Es gibt Infrarot-Tonübertragungssystem für Schwerhörige, da reicht ein Sender mit etwa 40 LEDs über 30m weit.

Auch ohne zusätzliche Verstärkung ließe sich theoretisch die Sendediode durch mehere in Reihe geschaltete Dioden (mit kleinerem Vorwiderstand) ersetzen, ohne die Schaltung stärker zu belasten. Das werde ich mal ausprobieren, wenn ich die Tage bei Reichelt bestelle und IR-Dioden bekomme. Vorschlag nach ein wenig Rechnerei: vier LEDs in Reihe mit 100 Ohm als R7. Damit wird sogar etwas weniger Strom verbraucht als mit der Originalschaltung.

[damaltor]

das klingt sinnvoll...

eine ultraschallortung halte ich für mehr oder weniger unmöglich. der asuro wird eher die wände orten als jemals den anderen asuro zu finden.

eine infrarotsendung wird schon passen. eine möglichkeit, die befehle relativ sicher zu übertragen wäre glaube ich folgende: während asuro1 vorausfährt, sendet er das, was er gerade tut als befehl zu asuro2. und zwar IMMER WIEDER, 10x pro sekunde oder so. dann ist es nicht weiter schlimm, wenn mal ein befehl verloren geht oder falsch übertragen wird.

dann müsste man die sendeleistung allerdings wirklich etwas verstärken. die idee vom uwegw ist gut, man könnte dann evtl auch jeweils eine diode in jede richtung zeigen lassen, dann ist das risiko eines "vorbeisendens", z.b. nach einer kurve nicht so groß...

[EDH]

optimal, wäre es, wenn man diese dioden auch noch nach bestimmtne bereichen einteilern würde.
(allerdings ist da glaub ich am atmega nichts mehr frei). man hätte dann praktisch mehrere ir dioden, die auch einzeln angesteuert werden. daurch wäre dann eine ortung relativ genau möglich

[damaltor]

hmm... dann müsste man evtl entweder eine porterweiterung oder einen zweiten atmega draufsetzen =) das ganze auf die erweiterungsplatine, und die leds gleich mit dazu. dann kann man das ganze auch bei bedarf wieder abbauen...

ich hatte ohnehin mal vor, einen zweiten atmega dazuzubauen.. mal sehen...

[EDH]

ist das mit dem zweiten atmega nicht ein wenig zu "trivial" ;)

[damaltor]

ööhm.. hab ich au grad gedacht... aber ich dachte an eine kommunikatin in beide richtung zwischen den beiden atmegas...

[EDH]

mit einem port der immer zwischen senden und empfangen umgeschlaten wird, so dass wie bei funkgeräten immer nur einer senden kann, oder mit zwei ports?

[damaltor]

na ich dachte eigentlich an folgendes: Möglichkeit 1
Hauptprozessor meldet an nebenprozessor "PIN1" und "HIGH", dann schaltet Nebenprozessor seinen pin1 auf high. quasi wird der neben prozwssor nur ferngesteuert, ohne wirklich zu wissen, was er da eigentlich tut. die gesamte rechenarbeit liegt beim hauptprozessor. eigentlich also ane porterweiterung mit einem zweiten prozessor. vorteil: der zweite prozessor hat viele frei ports, diese können über den ersten prozessor angesprochen und bedient werden (adc, digitale ein-&ausgänge..).
Die Daten werden an den ersten Prozessor zurückgegeben (z.B. adc werte) und dieser kann damit direkt arbeiten.
Nachteil: Viel rechenarbeit beim hauptprozessor.
Möglichkeit2:
Der Zweite Prozessor hat vordefinierte funktionen, und macht von selbst aus nichts, als auf den ersten prozessor zu warten, bis dieser sowas wie "Miss den Wert von Sensor 1" meldet. dann macht der nebenprozessor gennau das, kann die werte noch überarbeiten, meinetwegen "wert ist hoch genug" oder "Wert ist zu niedrig" oder einfach direkt den wert zurückgeben. Vorteil: Der HAuptprozessor wird entlastet. Nachteil: Der Nebenprozessor muss jedes mal, wenn eine neue funktion benötigt wird, neu geflasht werden und ist deshalb nicht so sehr flexibel für neue aufgaben und ideen.

Das schwierigste wird wohl, eine art übertragungsprotokoll zu entwerfen...

[EDH]

das mit dem übertragunsprotokoll hatten wir schon öfters
vielicht sollte man mal einen thread aufmachen in dem ein einheitliches universelles asuro übertragungsprotokoll entworfen wird...

[damaltor]

hmm.. vielleicht sollten wir uns erstmal was ausdenken... ich werd mich mal dransetzen.