- LiTime Speicher und Akkus         
Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 24

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

  1. #1
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    76
    Beiträge
    2.180

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

    Anzeige

    Praxistest und DIY Projekte
    hallo allerseits,

    ich habe mich in letzter zeit intensiv mit einem neuen fahrgestell für meinen RP6 beschäftigt:
    Klicke auf die Grafik für eine größere Ansicht

Name:	ansicht_von_vorne-1.jpg
Hits:	105
Größe:	57,9 KB
ID:	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:
    Klicke auf die Grafik für eine größere Ansicht

Name:	verteiler_board_unbestueckt-1.jpg
Hits:	64
Größe:	56,3 KB
ID:	31450

    verdrahtet:
    Klicke auf die Grafik für eine größere Ansicht

Name:	verteiler_board_verdrahtet-1.jpg
Hits:	66
Größe:	96,8 KB
ID:	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?
    Geändert von inka (22.03.2016 um 15:07 Uhr) Grund: accus von AAA zu AA geändert
    gruß inka

  2. #2
    Erfahrener Benutzer Robotik Einstein Avatar von Dirk
    Registriert seit
    30.04.2004
    Ort
    NRW
    Beiträge
    3.803
    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.
    Gruß
    Dirk

  3. #3
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    76
    Beiträge
    2.180
    hallo Dirk,
    Zitat Zitat von Dirk Beitrag anzeigen
    das ist ja ein richtig großes Projekt. Hut ab.
    es macht mir schon seit ca. anderthalb jahren viel spass...

    Zitat Zitat von Dirk Beitrag anzeigen
    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...
    gruß inka

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von Dirk
    Registriert seit
    30.04.2004
    Ort
    NRW
    Beiträge
    3.803
    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?
    Gruß
    Dirk

  5. #5
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    76
    Beiträge
    2.180
    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?
    gruß inka

  6. #6
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    55
    Beiträge
    2.196
    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.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  7. #7
    Erfahrener Benutzer Robotik Einstein Avatar von Dirk
    Registriert seit
    30.04.2004
    Ort
    NRW
    Beiträge
    3.803
    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?
    Gruß
    Dirk

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    76
    Beiträge
    2.180
    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
    gruß inka

  9. #9
    Erfahrener Benutzer Robotik Einstein Avatar von Dirk
    Registriert seit
    30.04.2004
    Ort
    NRW
    Beiträge
    3.803
    Das sieht ja gut aus. Viel Arbeit!
    -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.
    Gruß
    Dirk

  10. #10
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    76
    Beiträge
    2.180
    hi Dirk,
    Das sieht ja gut aus. Viel Arbeit!
    stimmt, aber wenn ich etwas habe, dann ist es zeit...

    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!
    gruß inka

Seite 1 von 3 123 LetzteLetzte

Ähnliche Themen

  1. RP6 - M256 WIFI Modul
    Von markus788 im Forum Robby RP6
    Antworten: 1
    Letzter Beitrag: 26.05.2013, 17:45
  2. Probleme mit M256 WIFI 1.2
    Von markus788 im Forum Robby RP6
    Antworten: 26
    Letzter Beitrag: 06.05.2013, 19:47
  3. M256 WIFI Modul
    Von markus788 im Forum Robby RP6
    Antworten: 11
    Letzter Beitrag: 20.02.2013, 21:30
  4. Verkaufe Robotsystem RP6v2 + WIFI-System M256 + CCPro Mega 128 incl. Prozessor
    Von oldy im Forum Kaufen, Verkaufen, Tauschen, Suchen
    Antworten: 1
    Letzter Beitrag: 15.01.2013, 18:51
  5. RP6v2 M256 WiFi !?
    Von Dirk im Forum Robby RP6
    Antworten: 20
    Letzter Beitrag: 11.05.2012, 20:27

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiTime Speicher und Akkus