RP6 Robot Base Hardware

[Dirk]

Hier kann es um die Hardware des RP6 gehen.
Was ist alles dran? Schaltungsdetails? M32-Portzuordnung? Abgleich und Eichung ... usw. usw.

Hier sind die Hardwarespezialisten gefragt. Da gibt's ja ne Menge hier.
In der nächsten Woche haben wir die ersten RP6 in der Hand! Dann wird's spannend.

Gruß Dirk

[Xtreme]

Da in diesem Thread alles diskutiert werden soll was mit der Platine oder dem Chassis vom RP6 zu tun hat möchte ich gleich einmal ein Problem ansprechen. Die Lötstellen:

Bild hier  

Auch einige auf der Hauptplatine sehen so aus. Ich denke das liegt noch an den Anfangsschwierigkeiten die jede industrielle Serienfertigung mit sich bringt.
Bis jetzt habe ich auch noch keine kalte Lötstelle gefunden. Nur sehen so "Beulen" halt nicht besonders professionell aus. Hier muss bis zur Markteinführung noch was getan werden.

[Sommer]

Hi,

diese "Beulen" und meist graue Lötstellen kommen durch das Bleifrei löten!

Glaube nicht das es sich um anfangsschwirigkeiten beim löten handelt, eher um eine noch nicht ganz optimierte Lötanlage.

Gruß Ulli

[SlyD]

So ein paar unschöne Sachen liegen daran, dass eure Bots noch aus einer Vorabserie stammen - wie schon mehrmals erwähnt worden ist. Einige Boards sind da leider relativ dreckig aus Fernost zurückgekommen - die sollten natürlich eigentlich sauber sein.

Was da wohl beim Handlöten vor allem noch Probleme bereitet, ist das relativ neue Bleifreie Lötzinn. Wer das schonmal selbst verwendet hat, weiss wovon ich rede.
Das Zeug glänzt GAR NICHT mehr so wie bleihaltiges Lot und es ist ziemlich zäh.

Aber ich habe von den Chinesen auch schon ganz deutlich bessere Prototypen als das auf dem Foto bekommen - also wird sich das schnell verbessern denke ich.

MfG,
SlyD

[Xtreme]

Gestern und heute habe ich die ersten eigenen Programme geschrieben.
Ich bin mit der LIB wirklich seeehr zufrieden... ein Anfänger wird sich vermutlich sehr leicht zurecht finden. Vieleicht drücke ich das Teil morgen mal meinem Bruder in die Hand... mal sehen wie er sich dann so anstellt. Er hat auch schon Interresse bekundet.
Zu meiner Frage (darum auch im Hardware Thread): Ich habe folgenden Code:

setACSPwrMed();
task_ACS();	
if (!obstacle_left && !obstacle_right) 
{
c= 1; a = 80; b = 80;setACSPwrMed();
}
setACSPwrHigh();
task_ACS();	
if (!obstacle_left && !obstacle_right) 
{
c= 0; a = 120; b = 120;
}

Kann es sein, dass zwischen dem Einstellen der ACS Empfindlichkeit (setACSPwr) und der Aktualisierung der Variablen (task_ACS) einige Zeit liegen sollte? Ich habe nämlich das Gefühl, dass sich seit ich diesen Programmteil mit drinnen habe die Fehleranfälligkeit des ACS steigt.

[SlyD]

Hallo Xtreme,

ja allerdings! Da muss einiges an Zeit zwischen liegen!

Das ACS sendet periodisch IR Impulse aus.
Dabei läuft das Aussenden der IR Impulse im Hintergrund in einem der Timer Interrupts (s. ISR (TIMER2_COMP_vect) ) - das wird in der task_ACS() Funktion nur gesteuert.

Damit das korrekt funktioniert, müssen auch ein paar Millisekunden zwischen den einzelnen IR Impuls Paketen liegen, sonst erkennt der TSOP34836 das als Störlicht und blockiert den weiteren Empfang.


Wenn Du Dir mal die task_ACS Funktion in der Library anschaust, sieht Du, dass das ein schon eine recht komplexe Statemachine (=Zustandsautomat) ist (da ist aber auch noch einiges zur Synchronisation von ACS und IRCOMM drin).

Es wird immer zwischen beiden Sendedioden vorne hin und her gewechselt - erst sendet die linke Diode, es wird gewartet ob etwas emfpangen wird - dann die rechte, wieder warten - und es beginnt von vorne.
Je nachdem ob etwas detektiert wird, werden die obstacle_left und obstacle_right Variablen gesetzt.

Das braucht natürlich etwas Zeit



Teste mal 30ms Pause (oder mehr) nachdem Du die Sendeleistung umgeschaltet hast, z.B. so:

// Sendeleistung umschalten
// Pause:
uint8_t i;
for(i = 0; i < 10; i++)
{
      task_ACS();
      mSleep(3);
}
// Sendeleistung umschalten
// Pause...

oder natürlich besser mit den Stopwatches. Dann z.B. eine kleine Statemachine basteln die alle 30ms aufgerufen wird ...

Grundlegend so:

startStopwatch1();

while(true)
{
     if(getStopwatch1() > 30) // mind. 30 ms vergangen?
     {
           // Hier Statemachine einfügen, die die Sendeleistung umschaltet
           // je nachdem ob etwas detekiert wird...
          
          // Stopwatch zurücksetzen:
          setStopwatch1(0);
      }

      // Ständig die task_ACS Funktion aufrufen - die kümmert sich selbst
      // ums Timing:
      task_ACS();
}

Ist nur das Grundgerüst.
Da fehlt natürlich noch der Hauptteil

MfG,
SlyD

PS: Den Code oben habe ich hier im Browser eingetippt - ist also nicht getestet!

[Xtreme]

Also, da Google Video mein Video nicht will und den Upload ständig abbricht, muss ich wohl erst mal ohne berichten:
1. Getriebe (RP5 <> RP6)
Die Getriebe des RP6 sind schräg verzahnt. Im Vergleich mit denen des RP5 sind sie somit wesentlich leiser.
Es wurden andere Kunststoffe verwendet, (vieleicht auch zur Lautstärkesenkung!?) wodurch mir die Getriebe nun wesentlich stabiler vorkommen.
Die maximalen Geschwindigkeiten der beiden sind ungefähr gleich, der RP5 ist geringfügig schneller, aber dafür mindestens doppelt so laut. (Genaue Angaben in m/s folgen! Laut Bedienungsanleitung für kurze Zeit max. 30cm/s)
In diesem Thread findet man Fotos der Getriebe:
https://www.roboternetz.de/phpBB2/viewtopic.php?t=32298

2. Radencoder
Die Radencoder beim RP5 waren ja bekanntlich nicht gerade der Hit. Beim RP6 wurde deutliche Verbesserungsarbeit geleistet. Die Encoderscheiben sind in 36 Segmente unterteilt. Durch zwei 50:12 Untersetzungen ergibt sich eine Auflösung von 625 Flanken pro Radumdrehung. Pro Sekunde können von der Lib max 1000 Flanken verarbeitet werden.
Mit einem Raddurchmesser von 5cm ergibt sich eine rechnerische Auflösung von 0,2512mm pro Impuls. Allerdings schwankt dieser Wert etwas, so dass die Radencoder mit einem Poti kalibriert werden können (am besten mit einem Oszi).
Die Lib stellt sehr brauchbare Antriebs- Funktionen zur Verfügung:
-Einregeln und halten einer best Drehzahl (unabhängig von der Akkuspannung)
-Fahren einer best Strecke
-Drehen um einen best Winkel

Alle Funktionen haben eine Art "Softstart" integriert, d.h. die eingestellte Geschwindigkeit wird mehr oder weniger langsam angefahren.
Die Wegstreckenfunktion regelt kurz vor Erreichen der gewünschten Strecke die Geschwindigkeit herunter, um nicht über das Ziel hinaus zu schießen.
Dies hat weiterhin zur Folge, dass keine abrupten Richtungswechsel möglich sind (wenn man die Lib verwendet), was die Getriebe schont.
Die Genauigkeit dieser Funktionen ist natürlich vom Kettenschlupf abhängig. Wie genau sie in der Praxis funktionieren wird noch im Software Thread berichtet.
Beim RP5 gab es das alles, bedingt durch dir schlechten Encoder, nicht.

So, ich hoffe nichts vergessen zu haben, wenn doch -> FRAGEN!

[SlyD]

Allerdings schwankt dieser Wert etwas, so dass die Radencoder mit einem Poti kalibriert werden können (am besten mit einem Oszi).

Nicht ganz:
Die Potis sind zum Einstellen da, damit die Encoder ein sauberes Signal liefern. Der Abstand der Sensoren zur Codescheibe unterliegt natürlich Fertigungsschwankungen und die Sensoreigenschaften und Widerstandswerte streuen auch immer etwas. Daher muss man das damit justieren.
An der Auflösung ändern die beiden Potis also nichts. Die ist nur abhängig vom tatsächlichen Raddurchmesser und von den Ketten.

--> An den kleinen Potis der Encoder also bitte nur rumstellen, wenn es absolut notwendig ist - die werden normalerweise schon in der Fabrik passend eingestellt!
s. auch diesen Thread:
https://www.roboternetz.de/phpBB2/viewtopic.php?t=32328



Der normale Auflösungsbereich liegt zwischen 0.23 bis 0.25mm. Der für einen bestimmten Roboter passende Wert, kann durch abfahren von Teststrecken ermittelt werden - also z.B. 4000 Zählschritte weit fahren und die tatsächlich gefahrene Strecke messen ...
Wenn man z.B. 4012 Zählschritte fährt (die 4000 genau zu treffen ist gar nicht so leicht --> Bremsweg...) und die tatsächliche Wegstrecke 965mm war, wäre die Auflösung 965 / 4012 = 0.24mm (gerundet).
Das macht man ein paar mal und nimmt den Mittelwert.
Den trägt man in der RP6Config.h ein, übersetzt das Testprogramm erneut und probiert aus, ob der Bot bei 4000 Schritten nun den einen Meter besser trifft.


----------------------------

für kurze Zeit max. 30cm/s

Die Library begrenzt die Maximalgeschwindigkeit absichtlich!
*Etwa* 30cm/s wären ohne Begrenzung und bei vollen Akkus möglich...

Das wird begrenzt, weil die Maximalgeschwindigkeit nur bei voll aufgeladenen Akkus gehalten werden könnte. 1000 Flanken pro Sekunde ist ein Wert, der auch mit etwas schwächeren Akkus noch erreicht werden kann. Und nebenbei ist das für die Lebensdauer der Motoren und Getriebe natürlich besser...

1000 Flanken/s entspricht etwa 25cm/s, je nach tatsächlicher Auflösung der Encoder.


MfG,
SlyD

[Xtreme]

Nun hat es mit dem Video geklappt. http://video.google.de/videoplay?doc...31951998&hl=de

Beide Roboter werden ancheinander mit 20%, 40%, 60%, 80% und 100% der maximal einstellbaren Motorleistung betrieben.

Das Klicken ist übrigens nicht das Getriebe der Roboter, sondern der Autofokus meiner Cam...

[ACU]

Ich wollte auch mal meine Erfahrungen ein bisschen berichten.
Eigene Programme habe ich noch nicht ausprobiert.
Ich habe aber einige der Testprogramme schon draufgeladen und haben auch mal ein paar Parameter geändert (Geschwindigkeit) und selber compiliert und draufgeladen.
Hat alles sehr gut funktioniert.
Das Uploader ist besser als erwartet.
Als ich gehört hatte, dass er nicht in der IDE integriert ist, habe ich schon Angst bekommen. Aber da der Uploader sich die Hex Datei merkt ist er ziemlich flexibel. Dadurch ist man sehr flexibel und kann auch andere Compiler und Sprachen verwenden.
Der Roboter ist wirklich sehr geländegängig.
Habe ich nicht erwartet.
Mein Zimmer ist wirklich ein extremes Risikogebiet.
Überall liegen fette Kabel und auch mal die eine oder andere Zeitschrift .
Der RP6 kommt aber super durch. Selbst über die großen Klinkenstecker, die am Kabel von der E-gitarre sind, fährt er locker drüber.
Mein Roboter Cyntronixx hatte damit mehr Probleme.

Was ich als einziges ein bischen bemängeln würde sind die berührungslosen IR Sensoren.
Es passiert relativ häufig, dass der Roboter Gegenstände übersieht, oder auch mal plötzlich wendet, obwohl nix war.
Die Taster vorne waren eine sehr gute Erfindung. Mithilfe von den IR Sensoren und den Bumpern vorne kommt der Roboter auch durch das Gewirr von Stuhl und Tischbeinen bei uns im Wohnzimmer unter dem Esstisch. Dort sind schon teurere Roboter gescheitert .
Die IR Sensoren schauen ziemlich gerade nach vorne. Dadurch sieht er Roboter nicht, wenn auf einer Seite eine Wand immer näher kommt (in einem flachen Winkel).
Die Lautstärke ist echt ok, da kann man nicht meckern.
Die Größe und das Gewicht sind ideal.
Mein großer Roboter Cyntronixx hat ja doch ziemlich gewaltige Ausmaße.
Den RP6 stecke ich einfach in seine Kiste und schon kann er in einen Rucksack. Wenn man im Urlaub nicht auf sein Hobby verzichten will, braucht man eigentlich nur einen kleinen Steckerlader und ein Notebook einzupacken. Schon geht der Spaß los.
Ich habe den Roboter letzte Woche in der Turnhalle auf dem Parkett fahren lassen. Hat zwar ne ganze Weile gebraucht, aber schließlich war er hinten und hat auch korrekt gewendet.
Heute werde ich ihn mal mitnehmen und meinen Kollegen vom Eurobot Team aus der Hochschule zeigen.

Zusätzliche Entfernungssensoren kommen auf alle Fälle dran.
Besonders, wenn man noch Aufbauten (Lochrasterplatinen) hat, kann es sonst schnell passieren, dass der Roboter oben hängen bleibt und es aber nicht merkt.

Mein Fazit: Empfehlenswert

MfG ACU


PS Paar Videos werde ich auch bald mal machen und bei youtube reinstellen...