- Akku Tests und Balkonkraftwerk Speicher         
Seite 4 von 7 ErsteErste ... 23456 ... LetzteLetzte
Ergebnis 31 bis 40 von 63

Thema: XPlorer 2

  1. #31
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    56
    Beiträge
    2.209
    Anzeige

    LiFePo4 Akku selber bauen - Video
    Inzwischen ging es -ein bisschen- weiter:
    Die neue Unterwanne (äusserlich von der alten nicht zu unterscheiden, abgesehen vom Akku-Deckel im Boden) ist fertig.
    Auch die ganzen Aufnahmen und Halterungen, die da rein mussten, sind drin.
    Weniger als in der alten: ich krieg den Motortreiber da unten nicht wirklich rein.

    Inzwischen hab ich mich mal mit den Encodern beschäftigt: grosser Murks!
    Auf den Platinen steht 3.3V- ich hab drei Stunden umgesteckt, gemessen und gerätselt- kein Mucks von den Hall-Sensoren.
    Aus lauter Verzweiflung hab ich dann mal 5V drauf gegeben und -oh wunder- ein grünes Lichtlein geht an!
    Und nun kann man die Dinger auch auslesen, funktioniert sehr gut.
    Offenbar wussten die Chinesen selber nich genau, was sie da eigentlich basteln....trotzdem sind die Motoren, mit grademal 12€/Stück (incl. Inline-Getriebe und Encoder) ein Schnäppchen, verglichen mit den nahezu baugleichen Polulus.

    Auf den angelöteten Platinen gibts jeweils zwei Sensoren- man kann also auch die Drehrichtung ermitteln- wozu man das brauchen könnte, wüsst ich, ehrlich gesagt nicht- schliesslich weiss man ja, was man ansteuert..aber egal: ich lese nur einen aus, und fertig.

    Nun muss ich alles mal neu verkabeln, mal sehn, was dieses Wochenende noch wird...
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  2. #32
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    56
    Beiträge
    2.209
    Sodele.
    Nach einer halben Bastel-Nacht ist der XP2 wieder im Geschäft.

    Inzwischen hab ich die alte Software weitgehend angepasst- da musste einiges umgeschrieben werden, denn der jetztige Motortreiber arbeitet doch deutlich anders- aber sie laufen.
    Beeindruckend kräftig- ich glaub, Probleme mit der Antriebsleistung werd ich nicht mehr haben.
    Hab im Moment zwar keine Ketten dauf, aber die Kettenräder mit den Fingern anhalten, was bei den kleinen Motoren schon ging, wird nix mehr.

    Bin allerdings noch nicht gefahren, vorher muss ich noch den Kilometerzähler anpassen, denn jetzt hab ich irgendwas um die 400 Odo-Ticks pro Radumdrehung, das waren vorher, glaub ich, nur ca. 40.
    Vorher aber will ich mich noch mal genauer mit dem Motortreiber befassen, das Ding hab ich seit Jahren nich mehr benutzt...
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  3. #33
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    77
    Beiträge
    2.180
    bin schon auf das nächste video gespannt
    gruß inka

  4. #34
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    56
    Beiträge
    2.209
    Hm, mal sehen, was wird die Woche- hier geht der Stress gerade los.
    Riecht ziemlich nach Arbeit....

    Aber der XPlorer ist wieder einsatzfähig-ab etwa PWM 150 fährt er schon sicher los (bergauf kann ich grad schlecht probieren).
    Das ist deutlich weniger, als er mit den kleinen Motoren brauchte.

    Ein kleines Problem gab es noch: diese Motortreiber-Platine braucht Pulldown-Widerstände an den PWM-Pins, sonst laufen die Motoren schon los, sobald der Strom eingeschaltet wird (während der Arduino auf ne Programmierung wartet)- nich so prall.
    War aber einfach zu beheben..
    Geändert von Rabenauge (10.02.2020 um 23:46 Uhr)
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  5. #35
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    56
    Beiträge
    2.209
    Sodele.
    Das Timing ist an verschiedenen Stellen angepasst worden, und die Regelung der Geradeausfahrt auch.
    Beispielsweise musste ich das Entprell-Delay für die Odometer-Interrupts deutlich runter setzen (aktuell nur noch 5ms), da die Geber jetzt ja direkt auf den Motorachsen sitzen, und nicht mehr am Getriebeausgang.
    Dadurch kommen die Interrupts viel schneller rein.

    Funktioniert wieder ziemlich gut jetzt:

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

Name:	Regelung.jpg
Hits:	9
Größe:	75,5 KB
ID:	34811

    Dass da mitunter etwas unstimmige Werte auftauchen, liegt daran, dass die Regelung viel öfter eingreift, als die serielle Ausgabe geschrieben wird- letztere nämlich nur jede Sekunde einmal.
    Das sind also nur Snapshots des momentanen Zustandes.

    Aber, ich finde, so kann man das erstmal lassen.
    Als nächstes werd ich mich mal um den Kilometerzähler kümmern, aber nich mehr heute.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  6. #36
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    56
    Beiträge
    2.209
    Inzwischen hab ich sowas wie ein Fahrprogramm geschrieben.
    Und...Probleme.

    Im Grunde läuft es so ab: es wird ein Ultraschall-Ping nach vorne gesendet, dann aufs Echo gewartet, und anhand der ermittelten Entfernung festgelegt, was passieren soll: bei mehr als einem Meter Platz Volgas, wird es weniger, geht der XP2 etwas vom Gas, und wenn ein halber Meter unterschritten wird, wird gelenkt.
    Eigentlich ganz simpel nur- funktioniert es nicht richtig.
    Der Zustand "Vollgas" wurde nie erreicht.

    Also hab ich mir mal angeschaut, was denn der vordere US-Sensor so liefert- und der kommt, aus irgendeinem Grund, nicht mehr über etwa 70cm hinaus.
    Auch nicht, wenn 5m vor dem Roboter nichts ist.
    Da ich absolut keine Erklärung für finden konnte (und irgendwelche Beeinflussungen durch andere Programmteile ausschliessen wollte), hab ich die Sensor-Abfrage-und Auswert-Routine mal in ein separates Programm gepackt, mit dem selben Ergebnis.

    Interessant ist: betreib ich den Arduino Nano nur an USB, wird die mögliche Entfernung grösser.
    Schalt ich auf Akkubetrieb um ist bei 70 cm Schluss.
    Es kann aber kein Problem mit der Stromversorgung sein, denn im Akkubetrieb messe ich an der 5V-Schiene (die auch den US-Sensor versorgt) 4.97V, im USB-Betrieb nur knapp vier.
    Es müsste also, wenn die Stromversorgung die Ursache wäre, umgedreht sein.

    Nen Gegentest habe ich auch gemacht: der hintere US-Sensor erreicht lässig Werte oberhalb nem Meter.
    Der funktioniert also offenbar...die Software für beide kann auch nicht die Ursache sein, denn die ist identisch.

    Interessant auch: innerhalb der Distanz, die der vordere schafft, stimmen die Ergebnisse auch.
    Aber während eben der hintere auch Entfernungen von mehr als 2m sicher messen kann, ist vorne bei knapp über 70 cm Schluss.

    Ich hänge mal die Sensoren-Abfrage an, finde da zwar keinen Fehler (wie gesagt, der hintere wird ganz genauso abgefragt, funktioniert aber richtig), vielleicht findet doch jemand etwas, dass ich übersehen habe:

    Code:
    void pingVorne()// ******************** Vorn nach Hindernissen suchen **************************************
    {
      delay(10);                            // ggf, alte Echos abklingen lassen
      digitalWrite(triggerVorne, LOW);
      delayMicroseconds(2);
      digitalWrite(triggerVorne, HIGH);     //Trigger Impuls 10 µs
      delayMicroseconds(10);
      digitalWrite(triggerVorne, LOW);      //Messung starten
      long laufZeit = pulseIn(echoVorne, HIGH,maxEntfernung); // Echo-Zeit messen, aber nicht zu lange warten
      float messung=laufZeit/ 58.2;         //Laufzeit in cm umrechnen
      entfernungVorne = ((entfernungVorneAlt*0.2)+(messung*0.8)); // Ergebnis glätten
      if(entfernungVorne==0)                // das gibts nicht, also muss die Bahn frei sein
        {
          entfernungVorne=120;
        }
      entfernungVorneAlt=entfernungVorne;
    }

    Die Variable maxEntfernung ist ne globale, die sorgt dafür, dass der Eingang nicht die volle Sekunde wartet, was bei pulseIn() normalerweise der Fall wäre.
    Die kann auch nicht die Ursache sein (damit _könnte_ man die mögliche Entfernung einschränken)- aber der hintere benutzt die auch.

    Der einzige Unterschied liegt in den Pins: der vordere hängt an A0 und A1, während der hintere digitale Pins nutzt.
    Aber die sind natürlich ordentlich als Ein- bzw. Ausgang definiert.

    Hat jemand ne Idee?
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  7. #37
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    77
    Beiträge
    2.180
    ich gehe davon aus, dass die

    #define MAX_DISTANCE 100 //400

    auf 400 eingestellt ist?

    wie verhält sich der hintere sensor vorne?
    gruß inka

  8. #38
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.04.2015
    Beiträge
    899
    Auch ganz beliebt: Der Sensor bekommt ein Echo vom Boden.
    Abhilfe: Etwas nach oben richten.

  9. #39
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    56
    Beiträge
    2.209
    Nein, die ist sogar deutlich höher.
    Das Timeout wird nämlich in Mikrosekunden angegeben.
    Wie gesagt: das kann nicht die Ursache sein, denn diese Variable benutzen beide.
    Testweise hatte ich das auch mal ganz raus genommen...ohne Erfolg.

    Interessante Idee, die Sensoren einfach mal zu vertauschen- da hätte man selbst drauf kommen können.
    Grad eben versucht...
    Wenn ich sie austausche, dann läufts umgedreht-also ist der Sensor, und nicht das Board, die Ursache *grummel
    Was haben denn diese Dinger andauernd....?
    Den hatte ich beim Umbau auf die anderen Motoren nicht mal abgesteckt, geschweigedenn ausgebaut.

    @Holomino:
    Das hab ich schon bedacht. Das Problem besteht auch, wenn ich das Teil quer durch nen grösseren Raum richte, von Ecke zu Ecke (was dann locker mehr als 5m sind).
    Er läuft auch _niemals_ ins Timeout, sondern gibt immer brav irgendwas zwischen 68 und 75cm zurück- oder eben weniger (und das stimmt dann auch).
    Geändert von Rabenauge (15.02.2020 um 11:18 Uhr)
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  10. #40
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    77
    Beiträge
    2.180
    Zitat Zitat von Rabenauge Beitrag anzeigen
    Interessante Idee, die Sensoren einfach mal zu vertauschen- da hätte man selbst drauf kommen können.
    Grad eben versucht...
    Wenn ich sie austausche, dann läufts umgedreht-also ist der Sensor, und nicht das Board, die Ursache *grummel
    Was haben denn diese Dinger andauernd....?
    Den hatte ich beim Umbau auf die anderen Motoren nicht mal abgesteckt, geschweigedenn ausgebaut.
    die Sensoren kosten fast nichts und sind auch schon mal defekt gleich wenn sie ankommen. ich weiss ja nicht wieviel du bestellt hast - für den fall der fälle - ich hab noch ein paar... so ein teil kann auch sein gewicht in gold wert sein, wenn man es mal eilig hat
    gruß inka

Seite 4 von 7 ErsteErste ... 23456 ... LetzteLetzte

Berechtigungen

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

LiFePO4 Speicher Test