neues fahrgestell, arduino mega, RP6 M256-WIFi und Ardu_IO

hallo allerseits,

ich habe mich in letzter zeit intensiv mit einem neuen fahrgestell für meinen RP6 beschäftigt:
Anhang 31449

es besteht aus einem alu "gehäuse" von Sainsmart, hat vier steppermotoren mit omni-wheels, 2 einzeln zu- und ab- schaltbare accupacks mit jeweils 6x AA, einen arduino mega 2560 und einen arduino prototype-shield. Außerdem ist ein zweizeiliges LCD I2c display, bluetooth datenübertragung zum PC, ultraschall entfernung messgerät und eine linienfolgevorrichtung angebracht...

Unten sind die accupacks, darauf sitzt der arduino, leider habe ich kein foto in der aktuellen ausführung mit den steppermotoren. Auf dem arduino sitzt das prototype-shield, welches primär der powerverteilung für die steppermotoren, andere module und die ladeeinheit (induktiv) dient:

unbestückt:
Anhang 31450

verdrahtet:
Anhang 31451

es gibt noch baustellen am fahrgestell, trotzdem beschäftigt mich die frage, wie die anbindung an den RP6 realisiert werden soll.

1) der grundsätzliche momentane aufbau bleibt wie er ist, oben drauf kommt das M256-WIFI modul (die RP6 baseplatine möchte ich nicht verwenden), das modul wird aus den vorhandenen accus versorgt und die beiden MC's kommunizieren als master (M256-WIFI) und slave (der arduino mega) per I2C. Wäre denke ich machbar?

2) zwischen den arduino mega und das proto-verdrahtungsshield (position jetzt) wird die (noch nicht verwendete) ARDU_IO gesteckt, das verdrahtungsmodul sitzt dann auf den arduinobuchsen auf der ARDU_IO drauf, die M256-WIFI (wieder der master) sitzt neben der ARDU_IO und ist mit der M256 über die 10-poligen wannenstecker verbunden. Auch durchführbar, denke ich.

Ich möchte die aufgaben zwischen den beiden MC's so trennen, dass der arduino sich um's (sicheres) fahren und evtl. noch ein paar kleinigkeiten kümmert, den rest (also z.b. die vermessung eines raumes) der master übernimmt. Das steht so aber noch nicht 100%tig fest...

Fragen:

- welche von den beiden alternativen sollte ich anpeilen?

- funktionieren beide überhaupt?

- kommunizieren die beiden MC's bei der variante 2 auch über I2C?

- gäbe es noch andere alternativen?

Hi inka,

das ist ja ein richtig großes Projekt. Hut ab.

Wenn ich die 2 Varianten richtig verstehe, unterscheiden sie sich nur dadurch, dass bei Variante 2 die ArduIO mit dabei ist.
Ob du das machst, hängt nur davon ab, ob du die Funktionen der ArduIO brauchst.

Durch die ArduIO ändert sich zwischen M256 WiFi und Arduino Mega eigentlich nichts: Sie können über I2C kommunizieren.

hallo Dirk,

Zitat:

---

Zitat von Dirk

das ist ja ein richtig großes Projekt. Hut ab.

---

es macht mir schon seit ca. anderthalb jahren viel spass... :-)

Zitat:

---

Zitat von Dirk

Wenn ich die 2 Varianten richtig verstehe, unterscheiden sie sich nur dadurch, dass bei Variante 2 die ArduIO mit dabei ist. Ob du das machst, hängt nur davon ab, ob du die Funktionen der ArduIO brauchst.

---

die funktionserweiterung der ArduIO brauche ich an der stelle nicht, ich dachte eher an die möglichkeit eine vorhandene lib ( hier für die m32 ) für die kommunikation zu nutzen? Beim zweiten hinsehen müsste das auch ohne die ArduIO gehen...es gibt noch viel zu tun...

Hi,

mir ist gerade noch etwas aufgefallen:

Machen Omniwheels eigentlich Sinn, wenn sie wie bei einem Auto angeordnet sind?
Der Bot müßte doch eigentlich an einer Schräge zur Seite wegrutschen, ohne dass er das verhindern kann!?

Also Frage: Nutzt man Omniwheels nicht eigentlich so, dass z.B. 2 in Fahrtrichtung zeigen und die anderen 2 quer dazu ausgerichtet sind?

hi Dirk,

also die ideale anordnung für die omniwheels ist "drei am umfang", radachsen zeigen zum gemeinsamen schnittpunkt / roboter mittelpunkt. Das liess sich bei dem vorhandemem gehäuse leider nicht realisieren...

aus erfahrung mit den vier rädern:

- der roboter fährt auch eine schräge hinauf, wenn er senkrecht zu schräge fährt - problemlos (bis 30°)

- steht er auf einer schräge schräg zu dieser, rutsch er bei abgeschalteten motoren ab, es hängt aber von der lage der räder ab, bzw. der rollen der räder zu der unterlage und natürlich von der steilheit der schräge ab

- er fährt auch eine schräge "schräg" herauf und rutsch nicht ab, natürlich abhängig von der steilheit der schräge

mir kam es nicht so sehr auf die bewältigung von einer schrägen ebene an, in meiner wohnung sind ja die fussböden waagerecht :-), das drehen auf der stelle ist faszinierend, eine bewegung zur seite habe ich (noch) nicht geschafft, ich tippe auf zu schwache stepper, oder meine software...


was die kommunikation von m32 zum arduino per I2C betrifft - sind Dir irgendwelche beispiele an die ich mich anlehnen könnte bekannt?

Mit diesen Rädern und _der_ Anordnung ist quer fahren auch gar nicht möglich. Einziger Vorteil: halbwegs reibungsarm auf der Stelle drehen, das dürfte klappen.
Wenn er Schrägen schafft, ohne seitlich runter zu rollen, dann liegt das an der Reibung der Rollen, und ist somit auch eher Glückssache.
Um _irgendwie_ quer fahren zu können, musst du die Räder zumindest ein wenig schräg anordnen.
Oder zweie davon (diagonal) um 90° verdreht einbauen. Das gäbe dann ne kreuzförmige Anordnung.
Anderenfalls müsstest du Mecanum-Räder benutzen, bei denen die Rollen schräg angeordnet sind.

Zitat:

---

was die kommunikation von m32 zum arduino per I2C betrifft - sind Dir irgendwelche beispiele an die ich mich anlehnen könnte bekannt?

---

Wie ist denn die Aufgabenverteilung?
M32 = Master, Arduino = Slave?
Wer steuert die 4 Motoren an (Arduino)?
Wer ist der Hauptprozessor z.B. für Navigation?

Was soll über I2C von Master zu Slave übertragen werden (Fahrbefehle, Sensordaten ...)?
Soll der Slave z.B. auch Daten (Motorfehler, Odometrie ...) zurücksenden?

Zitat:

---

Wie ist denn die Aufgabenverteilung?

---

folgendes fällt mir dazu ein:

-beide microprozessoren haben kontakt per bluetooth zum PC (datentransfer zum terminal, für berechnungen und zum flashen)
-beide microprozessoren haben ein LCD display (M32 – 4x20, arduino2x16) für die darstellung eigener daten

-es gibt keine odometrie, nur die steppermotoren können vom arduino überwacht werden (wie?)

-M32 = master, arduino = slave
-der hauptprozessor ist der auf M32

-arduino soll verantwortlich für sicheres fahren des robbys sein (steppermotoren, US-sensor, linienfolger)
-arduino bekommt die fahr-befehle / ziele / gyrodaten vom M32

Sensoren/ module / funktionen auf der M32:

-gesamtsteuerung des roboters / navigation
-noch zu definierende aufgaben

-IR-sender / empfänger (datenverkehr mit IR-baken)
-gyro

-bluetoothverbindung zum PC


Sensoren/ module / funktionen am arduino-teil:

-steppermotoren
-US-entfernungsmesser
-linienfolgemodul

-überwachung und korrektur der motordaten (z.b. beim geradeausfahren)

-überwachung des ladezustands der accupacks / spannungsüberwachung
-um- / zu- schaltung der accupacks
-überwachnung des ladevorgangs der accupacks

-speakjet(?)
-bluetoothverbindung zum PC

Das sieht ja gut aus. Viel Arbeit!

Zitat:

---

-es gibt keine odometrie, nur die steppermotoren können vom arduino überwacht werden (wie?)

---

Die Steppermotoren bewegen pro Schritt der Ansteuerung das Rad um einen bestimmten Winkel, z.B. 1° (je nach Motortyp).
Dann wären also 360 Schritte eine Umdrehung und die Entfernung wäre zu berechnen.

hi Dirk,

Zitat:

---

Das sieht ja gut aus. Viel Arbeit!

---

stimmt, aber wenn ich etwas habe, dann ist es zeit...

Zitat:

---

Die Steppermotoren bewegen pro Schritt der Ansteuerung das Rad um einen bestimmten Winkel, z.B. 1° (je nach Motortyp).
Dann wären also 360 Schritte eine Umdrehung und die Entfernung wäre zu berechnen.

---

so war meine frage eigentlich nicht gemeint, diese berechnungen habe ich bereits angewendet, bzw. die entspreche library verwendet...

Mir ging es um folgenden, konkreten fall: Die ersten vier stepper, die ich eingebaut habe, liefen alle schön gleichmäßig, wahrscheinlich alle aus dem gleichen fertigungslos. Nachdem eines ausgefallen war - keine ahnung warum (vielleicht doch zu billig) habe ich es ersetzt, seitdem zieht der robby beständig nach rechts.
Es müsste also eine überwachung her und zwar nicht auf der outputseite, sondern auf der seite wo die stepps entstehen. Das sehen aber die von der lib her vorgesehen funktionen offensichtlich nicht vor...

das hier wäre die funktion für den fall, dass alles gut läuft, wo man nicht eingreifen muss, wo aber auch das eingreifen relativ schwierig wird:

Code:

---

    for (idx = stepper_VL; idx < stepper_MAX; idx++) //alle stepper vorwärts
    {
      stepper[idx].setRPM(12);
      stepper[idx].setSPR(4075.7728395);
      stepper[idx].setDirection(CW);
      stepper[idx].rotateDegrees(60); //rotate(1)
    }

---

das ist die weniger elegante variante, vo aber alle stepper einzeln angepasst werden können:

Code:

---

    stepper[stepper_VL].setRPM(12);
    stepper[stepper_HL].setRPM(12);
    stepper[stepper_HR].setRPM(12);
    stepper[stepper_VR].setRPM(12);


    stepper[stepper_VL].setSPR(4075.7728395);
    stepper[stepper_HL].setSPR(4075.7728395);
    stepper[stepper_HR].setSPR(4075.7728395);
    stepper[stepper_VR].setSPR(4075.7728395);


    stepper[stepper_VL].setDirection(CW);
    stepper[stepper_VL].rotateDegrees(30);
    stepper[stepper_HL].setDirection(CW);
    stepper[stepper_HL].rotateDegrees(30);
    stepper[stepper_HR].setDirection(CW);
    stepper[stepper_HR].rotateDegrees(30);
    stepper[stepper_VR].setDirection(CW);
    stepper[stepper_VR].rotateDegrees(30);

---

beide varianten lassen sich aber - so wie sie sind - nicht im laufendem betrieb an eine neu entstandene situation "automatisiert" einstellen. Z.b. wenn der gyro meldet - "achtung, abweichung vom nordkurs, gegensteuern!"...
Ginge das so, dass ich die werte in den klammern durch variable ersetze und die je nach situation ändere?

frohe ostern!

Ich denke schon, dass es geht.
Am besten packst du z.B. trpm in nen eigenes Unterprogramm, und rufst das dann bei Bedarf auf:

void drehZahl(float a,b,c,d)
{
stepper[stepper_VL].setRPM(a);
stepper[stepper_HL].setRPM(b);
stepper[stepper_HR].setRPM(c);
stepper[stepper_VR].setRPM(d);
}

An das Unterprogramm schickst du dann einfach die gewünschten Werte:

drehZahl(12.2, 17.45, 12.92, 14);

Vermutlich musst du das dann jedes Mal vor run() aufrufen, bzw. dann, wenn sich da Änderungen ergeben.
Was deine verlorenen Schritte angeht: kann es sein, dass das Programm einfach zu schnell läuft, so dass die Motoren einfach nicht nachkommen?
Das Problem hat man bei Servos ja auch, wenn man zu oft neue Positionen schickt, erreichen sie manche gar nicht.
Das kannst du mit isDone() offenbar überprüfen.

danke für den tipp...

Zitat:

---

Ich denke schon, dass es geht.
Am besten packst du z.B. trpm in nen eigenes Unterprogramm, und rufst das dann bei Bedarf auf:

void drehZahl(float a,b,c,d)
{
stepper[stepper_VL].setRPM(a);
stepper[stepper_HL].setRPM(b);
stepper[stepper_HR].setRPM(c);
stepper[stepper_VR].setRPM(d);
}

An das Unterprogramm schickst du dann einfach die gewünschten Werte:

drehZahl(12.2, 17.45, 12.92, 14);

---

das werde ich ausgiebig testen :-), eigentlich müsste man die restlichen konfigurationsbefehle für die stepper ähnlich manipulieren können, oder?

Zitat:

---

Was deine verlorenen Schritte angeht: kann es sein, dass das Programm einfach zu schnell läuft, so dass die Motoren einfach nicht nachkommen?

---

glaube ich nicht, dass die stepper nicht nachkommen, vor allem ist es ja nur der neuer, ausgewechselter:
das ist die loop:

Code:

---

void loop()
{
  lcd.setBacklight(LOW);
  hindernis_vorh();
  {
    alle_stepper_vorwaerts();
    bewegung = bewegung + 1;
    fahrt_ausfuehren();
  }
  if (bewegung >= 20)
  {
    lcd.setBacklight(HIGH);
    //previous_millis = current_millis;
    bewegung = 0;
    for (pos_1 = 0; pos_1 < 180; pos_1 += 1)
    {
      myservo_1.write(pos_1);
      delay(15);
      myservo_2.write(pos_1);
      delay(15);
    }
    for (pos_1 = 180; pos_1 >= 1; pos_1 -= 1)
    {
      myservo_1.write(pos_1);
      delay(15);
      myservo_2.write(pos_1);
      delay(15);
    }
    myservo_1.write(90);
    delay(15);
    myservo_2.write(90);
    delay(15);
    lcd.setBacklight(LOW);
  }
}

---

und "fahrt_ausfuehren()" und "fahrt fertig()" verwenden ja schon "isDone":

Code:

---

boolean fahrt_fertig()
{
  return        stepper[stepper_VL].isDone() && stepper[stepper_HL].isDone()
                && stepper[stepper_VR].isDone() && stepper[stepper_HR].isDone();
}


void fahrt_ausfuehren()
{
  while ( ! fahrt_fertig() )
  {
    for (idx = stepper_VL; idx < stepper_MAX; idx++)
    {
      stepper[idx].run();
      // delay(1);
    }
  }
}

---

Zitat:

---

Zitat von inka

das werde ich ausgiebig testen :-), eigentlich müsste man die restlichen konfigurationsbefehle für die stepper ähnlich manipulieren können, oder?

---

Denk ich schon.
Das funktioniert bei den meisten Bibliotheken so oder ähnlich- es wird ja nur ne Art "Voreinstellung" übergeben, wieso sollte man die nicht auch ändern können.

Hi Inka,

ist es sinnvoll die beiden Steper einer Seite unterschiedlich anzusteuern?!
Das was der STEPPER_VL bekommt muss ja auch an STEPPER_HL gehen

Warum nutzt Du für Verzögerungen noch ein delay()? ein delay() wäre in der in der setup() ja noch oK, aber in der loop()!?
Befasse ich Dich doch mal mit den Watches der RP6 Library (bzw. der niborobolib clock.c)

Code:

---

void loop()
{
  uint8_t loop_millis = (uint8_t) (current_millis - previous_millis);
  // das sind UINT32 Variablen, Überlauf erst nach ca. 46 Tagen
  previous_millis = current_millis;
 
  lcd.setBacklight(LOW);
  hindernis_vorh();
  {
    alle_stepper_vorwaerts();
    bewegung = bewegung + 1;
    fahrt_ausfuehren();
  }
  if (bewegung >= 20)
  {
    lcd.setBacklight(HIGH);
    //previous_millis = current_millis;
    bewegung = 0;

#define SERVO_WRITE_DELAY 15
static uint8_t servo_write_timer = 0;

  if (servo_write_timer > loop_millis) {
    servo_write_timer -= loop_millis;
  } // if (servo_write_timer > loop_millis)

  else {
    // Der else Zweig wir alle SERVO_WRITE_DELAY ms ausgeführt,
    // wenn in der loop() keine weiteren delay() vorkommen

    // Timer neu setzen
    servo_write_timer = SERVO_WRITE_DELAY;

    static int8_t dir = 1; // vorwärts = +1, rückwärts = -1, Stopp = 0
// pos_1 = 0; // Initialisierung evtl. in der setup()


  // Alle SERVO_WRITE_DELAY ms Servos aktualisieren
  myservo_1.write(pos_1);
  myservo_2.write(pos_1);

  pos_1 += dir;
  // Wenn 180° erreicht, sollen Servos wieder gegen 0° fahren
  if (pos_1 > 180 ) dir = -1;
  if (pos_1 == 0) {
      // Zielposition erreicht
      dir = 0;
      pos_1 = 90;
      lcd.setBacklight(LOW);
  } //  if (pos_1 == 0)


/*
    for (pos_1 = 0; pos_1 < 180; pos_1 += 1)
    {
      myservo_1.write(pos_1);
      delay(15);
      myservo_2.write(pos_1);
      delay(15);
    }
 
  for (pos_1 = 180; pos_1 >= 1; pos_1 -= 1)
    {
      myservo_1.write(pos_1);
      delay(15);
      myservo_2.write(pos_1);
      delay(15);
    }
    myservo_1.write(90);
    delay(15);
    myservo_2.write(90);
    delay(15);
    lcd.setBacklight(LOW);
  }
*/
} // else if (servo_write_timer > loop_millis)

// und hier könnte noch mehr Code stehen, der quasi parallel ausgeführt würde

} // loop()

---

Also dann, noch viel Spaß und Erfolg

Hi BirgerT,

das mit der unterschiedlichen ansteuerung der stepper hat sich aus der situation ergeben, dass einer plötzlich (nach umbau des fahrgestells) nicht mehr so lief wie vorher und auch nicht so wie die anderen drei...
Zu guter letzt hat sich rausgestellt, dass der elektrische anschluss dieses verd... steppers nicht richtig war. Nun läuft er wieder genauso wie die anderen drei :-) naja, fast genau so, also das thema kontrolle der durchgeführten stepps bleibt evtl. ein problem.

Und nun zu delay() :

das equivalent hierzu ist bei RP6 das sleep() oder msleep()

beide sind "systemblockierend", vielleicht nicht der richtige ausdruck, aber während des wartens steht alles andere auch still. Das mag man als nachteil empfinden und im manch einer situation ist es das evtl. auch...

Hier zeigt sich wieder einmal, dass ich trotz alldem, was ich schon verstehe, immer noch ein anfänger bin. Ich komm ja von der (elektro)mechanischen seite, für mich ist alles, was vom microcontroler kommt unvorstellbar schnell. Ist es ja auch, wenn man es mit einem servo vergleicht, der gemütlich von links nach rechts schwenkt und dabei volle 3 sekunden "verschwendet"...(Bei der überprüfung ob ein hindernis vor dem fahrzeug ist, ist es ja keine volle drehung, sondern nur ein kurzes hin und her und drei pings)

ich finde es halt verständlicher und nachvollziehbarer, wenn der mc darauf wartet, bis der servo mit seinem "dreh" fertig ist und dann wieder loslegt. Der servo dankt es mit dem vollständigen ausführen seiner bewegung und ich merke es nicht, dass der mc 3 sekunden lang stillstand...

Frage:
Ist es jetzt so, dass durch die delays oder sleeps irgendwas schieflaufen kann, oder nutze ich durch ihre nutzung "nur" nicht alle mir zur verfügung stehenden mittel um einen vorgang "quasi parallel" kontrolliert ablaufen zu lassen?

Hallo inka,

grundsätzlich sollte das mit den delays() kein Problem sein, da du alles in Reihenfolge machst. Das hattest Du ja für Dich so entschieden, dass das am Sinvollsten ist.

Nur macht Dein Programm nicht wirklich das, was es machten sollte?!
Ich gehe mal davon aus das Du den Servo einen Schritt weiter setzten möchtest und dann messen möchtest ob etwas vor Dir liegt?

Im Moment misst Du einmal am Anfang und machst einen Fahrschritt. Wenn Du davon genug hast, läßt Du die Servos hin- und herlaufen machst aber keine Messungen. So wie Dein Prog z.Zt. aufgebaut ist, wird nur an der äußersten, rechten Position gemessen und nicht in all den anderen Schritten!
Ausserdem macht es wenig Sinn, die Servos immer nur ein Grad voranschreiten zu lassen. Wenn ich's richtig in Erinnerung habe, dann aben die Sensoren einen Abstrahwinkel von ca. 15°, da könntest Du größere Winkel z.B. 1/4 oder gar 1/3 des Abstrahlwinkels nehmen und so weniger Schritte beim hin- und herschwenken Deines Radars haben. Was dann in der Summe schneller gehen würde.

Grüße

Chris

hallo botty,

ich muss in zukunft wohl mehr drauf achten welchen code ich hier poste, nicht jeder kann ja gedanken lesen :-)...

das ganze mit dem drehen des servos, (z.b. um ein grad) waren nur "interne" tests, wie es überhaupt aussieht...


mein plan ist folgender:

- der roboter fährt eine bestimmte anzahl - momenten 60° - sequenzen, der servo (und der US-sensor) ist nach vorne in fahrtrichtung gestellt, US-messung nach vorne läuft permanent, die messkeule beträgt ca. +- 15°

- der robby bleibt kurz stehen, auch wenn in fahrtrichtung kein hindernis gemessen wurde

- der sensor schwenkt ca. 20° nach links, prüft ob auch weiter links alles frei ist

- der sensor schwenkt ca. 40° nach rechts, prüft ob auch rechts alles frei ist

- robby fährt weiter

so, oder oder so ähnlich...

natürlich ist es eleganter, wenn auch der schwenk (und ping) nach links und rechts während der fahrt passiert, es ist aber in meinen augen kein muss...

hallo in die runde,

nach langer zeit wieder eine kurze meldung - ich bin - nachdem ich mit dem dreirädrigen roboter "fertig" bin (zumindest so weit, dass ich ihn mit meinem enkel zusammen nach und nach weiter entwickeln kann) wieder am fahrgestell dran, es gab kleine fortschritte:

- sainsmart motorshield V2 eingebaut, ist viel einfacher und effektiver, wird über I2C angesteuert, es bleiben viele pins zu freien verfügung...

- so gut wie keine delays im code, vieles kann ich jetzt mit millis() erledigen...:-)

ein paar fotos:

Anhang 32400Anhang 32401

hier zwei kurze videos:
2017 02 03 cruise avoid collision: https://youtu.be/VYyODaNvFTM
2017 02 03 fernbedienung: https://youtu.be/WKTGpe4jd7k

hallo,

die eingebauten getriebemotoren sind alle vier mit ir-encodern versehen. Das habe ich damals gemacht weil ich mir nicht sicher war ob ich sie brauchen werde oder nicht. Den einen habe ich versuchsweise in einem tesprogramm verwendet, der code ist so:

Code:

---

void encoder_1_auslesen(void)
{
  wert_[1] = digitalRead(encoder_1);


  if (vorwaerts_[1] == 1)
  {


    if (wert_[1] == 0 && zaehler_[1] == 0)
    {
      zaehler_[1] = 1;
    }


    else if (wert_[1] == 1 && zaehler_[1] == 1)
    {
      zaehler_[1] = 0;
      summe_[1] = (summe_[1] + wert_[1]);
      Serial.print(wert_[1]);
      Serial.print("    ");
      Serial.println(summe_[1]);
      Serial1.print(wert_[1]);
      Serial1.print("    ");
      Serial1.println(summe_[1]);
    }
  }
  else
  {
    if (wert_[1] == 0 && zaehler_[1] == 0)
    {
      zaehler_[1] = 1;
    }


    else if (wert_[1] == 1 && zaehler_[1] == 1)
    {
      zaehler_[1] = 0;
      summe_[1] = (summe_[1] - wert_[1]); //+
      Serial.print(wert_[1]);
      Serial.print("    ");
      Serial.println(summe_[1]);
      Serial1.print(wert_[1]);
      Serial1.print("    ");
      Serial1.println(summe_[1]);
    }
  }
}

---

es funktioniert soweit, wäre auch möglich das einfach mal auf vier zu erweitern. Würde wahrscheinlich dahingehend probleme bringen, dass die ausgelesenen werte praktisch nie identisch wären. Glaube ich zumindest...

Jetzt die frage: Kann sich hier jemand vorstellen, dass es wirklich situationen geben kann, wo alle vier notwendig sind? Oder würde z. b. ein zweiter "übers eck" also vorne-rechts, wenn der im code hinten-links ist, abzufragen?

würde mich über meinungen sehr freuen...

Hallo Inka,

sehr schönes Projekt !

Leider habe ich keine Antwort auf Deine Frage.

Mich würde aber interessieren, welche Getriebemotoren (mit ir-encodern) du genau verwendest (wenn möglich mit Bezugsquelle).
Auch die Übersetzung wäre interessant. Dein Robbi ist ja auf den Videos recht flott unterwegs.

Viele Grüße,

Gerhard

hallo Gerhard, schaue dir die links in meinem letzten post an...
gruss inka

hallo allerseits,

mehrer male bin ich bereits von den omni-move rädern und den standard TT rädern und wieder zurück gewechselt, die omni-move räder sind recht schwer, die normalen räder rutschen durch...

Die idee nun: schneeketten :-)

Anhang 32521Anhang 32522Anhang 32523Anhang 32524

hier ein video, jetzt muss ich noch testen bei welcher geschwindigkeit des motors die räder mit den ketten wirklich nicht durchdrehen...

Zitat:

---

Zitat von inka

hallo allerseits,

mehrer male bin ich bereits von den omni-move rädern und den standard TT rädern und wieder zurück gewechselt, die omni-move räder sind recht schwer, die normalen räder rutschen durch...

Die idee nun: schneeketten :-)

Anhang 32521Anhang 32522Anhang 32523Anhang 32524

hier ein video, jetzt muss ich noch testen bei welcher geschwindigkeit des motors die räder mit den ketten wirklich nicht durchdrehen...

---

Sie haben das Problem gelöst?

Zitat:

---

Zitat von Carposept

Sie haben das Problem gelöst?

---

leider nein, es rutscht immer noch, bei jeder geschwindigkeit, fast wie im richtigen leben. Es braucht halt einen fahrer und schleifende kupplung :-) und das mit arduino?

bin wieder bei den omni-moves und hoffe noch auf eine eingebung...