Wegen fortgesetzter Spams vorübergehend geschlossen.
Druckbare Version
Wegen fortgesetzter Spams vorübergehend geschlossen.
Hallo,
ich war so kurz davor mit den ersten Versuchen anzufnagen als mir zum tausendstenmal mein l293d durchgebrannt ist.....so langsam gewöhne ich mich an den Geruch ;)
Deswegen habe ich mir heute ein md22 bestellt, wenn das da ist und läuft mache ich weiter.
Bis dahin hier ein Bild von Aufbau.
An der Seite sieht man den ADXL und auf dem Ausleger ist der Sharp-Sensor.
Ich habe den ADXL jetzt eher unten angebracht damit nicht so grosse Tangentialbeschleunigungen auftreten.
Oder ist es gerade andersherum richtig(also adxl nach oben)?
mfg
Involut
Dass dir die L293D ständig durchbrennen verstehe ich nicht.Zitat:
ich war so kurz davor mit den ersten Versuchen anzufnagen als mir zum tausendstenmal mein l293d durchgebrannt ist.....so langsam gewöhne ich mich an den Geruch
Ich verwende auch einen L293D mit RB35 Motoren. Vom Bild her würde ich schätzen, dass mein Gestell sogar noch etwas schwerer ist. Trotzdem ist mir der L293D noch nicht durchgebrannt.
Hast du mal versucht einfach zwei L293D "Huckepack" aufeinander zu löten?
Wenn ich mir das Bild von deinem Roboter ansehe, frage ich mich wié du den überhaupt testest.
Der müsste sich doch wenn er umkippt ständig den Sharp-Sensor verbiegen und die Elektronik zertrümmern.
Ich würde da unten noch eine Querstrebe einbauen mit der der Roboter zwar in einem begrenzten Bereich kippen aber nicht komplett umkippen kann.
Der Vorteil ist dann auch, dass du beim Testen viel besser sehen kannst ob sich Verhalten verbessert oder verschlechtert.
Ohne Stütze würde mein Fahrgestell jedesmal sofort umkippen. Mit Stütze kann ich ihn immer eine Weile rumeiern lassen und sehen dann, ob er nur zwischen den Stützen hin- und herkippt oder sich zwischendurch auch mal einen Moment aufrecht hält.
So 2-3 Sekunden hat er es schon mal geschafft ohne sich abzustützen.
Allerding nur mit dem Sharp. Mit dem ADXL hat er sich meist in kürzester Zeit aufgeschaukelt und kippte wie wild hin- und her.
Hallo,
warum mir der L293d Durchbrennt weiss ich auch nicht. Es ist wahrscheinlich irgend ein Fehler auf der Lochraster Platine.
Weil ich nicht so gut Löten Kann habe ich mir ja auch die RN Control gekauft, die in der Varibialität schon sehr gut ist.
Ich habe dann aber doch wieder meine Platine genommen weil mir +5V und GND fehlen.
Ich brauche diese Klemmen fast immer für Sensoren, Servos usw.
Wenn die RN-Control diese Feature hätte wäre sie in meinen Augne Perfekt.
Zurück zum Thema:
Stützräder stehen auch schon auf meiner 2do list.
Weil der Senseor(Sharp) auf einer M8 Gewindestange Montiert ist, ist das relativ Stabil und der Sharp geht (noch)nicht kaputt.
Diese 2-3 Sekunden habe ich auch mit dem Sharp hinbekommen :)
Der Equibot zeigt ja das möglich ist. Hast Du das Viedeo und den Code mal angesehen?
Auf dem Video zeigt der Equibot nämlich ein ganz anderes Verhalten als meiner.
Bist Du im speziellen eigentlich noch an diesem Projekt dran?
Und köntest Du malö ein Photo oder sogar ein Video Posten?
mfg
Involut
Hallo Involut
hmm, vielleicht hält meiner ja auch, weil ich noch viel schlechter löten kann und die dicken Klumpen Lötzinn gut kühlen ;-)Zitat:
Es ist wahrscheinlich irgend ein Fehler auf der Lochraster Platine.
Weil ich nicht so gut Löten Kann habe ich
Das RN-Control hat doch Kontakte an denen du 5V und GND abgreifen kannst.Zitat:
Ich habe dann aber doch wieder meine Platine genommen weil mir +5V und GND fehlen.
Ich brauche diese Klemmen fast immer für Sensoren, Servos usw.
Wenn die RN-Control diese Feature hätte wäre sie in meinen Augne Perfekt.
Ich habe am Anfang auch das RN Control verwendet und habe da wenn ich mich richtig erinnere auch die Spannung für meine Sensoren abgegriffen.
Inzwischen habe ich mir eine eigene Platine für den Motortreiber und die Stromversorgung gemacht, den Rest macht aber immer noch das RN Control.
Ich habe seit Minaten aus Zeitmangel nichts mehr dran gemacht.Zitat:
Bist Du im speziellen eigentlich noch an diesem Projekt dran?
Ich habe noch fest vor irgendwann damit weiterzumachen. Die nächste Zeit wird das aber wohl nichts, da jetzt erst noch ein Umzug ansteht und ich schon langsam die Kisten packe.
Ich habe weiter oben im Thread ein paar Fotos und Videos verlinkt, z.B. hier: https://www.roboternetz.de/phpBB2/vi...=asc&start=154Zitat:
Und köntest Du malö ein Photo oder sogar ein Video Posten?
Hallo Kollegen!
Bin erst jetzt durch das Wiedervorholen auf diesen Thread aufmerksam geworden. Sehr interessant! Unter anderem wird ja versucht dem Asuro das Balancieren beizubringen. Da hab ich mir gedacht: "Das musst du auch versuchen." Ihr müsst wissen, mein Asuro folgt mir nämlich aufs Wort. Also den Asuro kurz programmiert, aufgestellt und das Kommando "Mach Männchen!" gegeben. Dazu noch die Hand so wie bei einem Hund hingehalten und siehe da - der Asuro macht Männchen. Ihr glaubt das nicht? Zum Beweis hier der Link zu dem Video:
http://service.gmx.net/mc/8Hs7NKjnhA...Y2J32v4AJZ3Vjr
Hinweis: Der Link für den Gastzugang zum GMX MediaCenter ist bis zum 5.12.2005 gültig.
Ihr müsst dort auf "GMX MediaCenter starten" klicken, dann öffnet sich ein Fenster. Im Fenster könnt ihr dann das Video "Asuro2.mov" runter laden oder direkt starten.
Gruss Waste
Hallo Waste!
Sehr chique!
Kannst Du Deinen Code posten, das wäre sehr nett?!
[schild=13 fontcolor=000000 shadowcolor=C0C0C0 shieldshadow=1]waste´s ASURO kann Männchen machen ![/schild]
Du bist doch immer für eine Überachung gut ! =P~
So richtig klar ist mir noch nicht wie du es gemacht hast.
Das es mit der IR-Abstandsmessung geht ist mir schon klar - aber wie ?
Versucht er den Abstand zur Hand zu konstant zu halten ? :-k
Der Code wird Euch überraschen, der ist so einfach. Hab selten so wenig Code gebraucht für so eine komplizierte Sache.
Voraussetzung ist natürlich der Umbau auf die IR-Hinderniserkennung. Siehe Beitrag: https://www.roboternetz.de/phpBB2/viewtopic.php?t=11114
Gruß WasteCode:#include "asuro.h"
#include <stdlib.h>
int main(void)
{
Init();
DDRD |= (1 << DDD1);
PORTD &= ~(1 << PD1);
OCR2 = 0xFD; //Pulsbreite 2
MotorSpeed(250,250);
while(1)
{
if (PIND & (1 << PD0)){
StatusLED(GREEN);
MotorDir(FWD,FWD);}
else{
StatusLED(RED);
MotorDir(RWD,RWD);}
}
return 0;
}
Beeindruckend, dann müßte es entsprechend auch mit der Regelung des Abstands zum Boden gehen.
Er reagiert ja auch wirklich sehr schnell, es sieht aus als ob er mit dem Schwanz wedelt.
Ich weiß gar nicht ob ein GP2D12 schnell genug dafür wäre. Wenn es so um die 10Hz ist könnte es ja gerade noch gehen. Dafür hatten wir ja auch schon Maßnahmen zur Erhöhung der Umfallzeit angedacht (mit Gewicht oder Fächer).
Auf alle Fälle eine sehr überzeugende Demonstration. Ich habe mir den Film geladen und hier ein Bild davon ausgeschnitten.
Manfred
Hallo Waste!
Danke für den Code!
Ich bin aber Assemblerprogrammierer und kann mir nicht so recht vorstellen, was Du da genau programmiert hast!
Könntest Du den Code vielleicht etwas erläutern, welcher Pin hat welche Funktion!?
Was für einen Sensor hast Du eigentlich verwendet?
Außerdem finde ich es sehr interessant, dass der Schwerpunkt so verlagert ist, denn es sieht irgendwie surreal aus, wenn links die Platine und rechts nur ein Kabelbinder als Gegengewicht sind.
Gibt es das Video eigentlich auch als Datei zum downloaden und abspeichern?
Ich habe das unter dem angegebenen Link nicht hinbekommen und würde das Video aber gerne archivieren!
Es sieht schon etwas unwirklich aus, das muss ich zugeben. Aber es ist echt. Ich war selbst ziemlich baff, als es funktionierte. Eigentlich wollte ich den IR-Detektor so umbauen, dass er den Abstand zum Boden misst. Zudem dachte ich daran den Schwerpunkt durch verlagern des Akkus hochsetzen zu müssen. Aber da kam die dunkle Seite der Faulheit in mir durch und die Idee war geboren, den Abstand einfach durch meine Hand zu simulieren. Und siehe da, es funktionierte sogar. Ich bin mal gespannt darauf, wer von euch es auch noch hinbringt. Am besten auf einem Teppich ausprobieren, da schmerzt es nicht so wenn der Asuro umfällt.
Der Asuro regelt mit dem IR-Detektor auf meine Handkante. Wenn er nach vorne fällt, wird nichts mehr detektiert und der Asuro fährt vorwärts damit er sich wieder aufstellt. Kippt der Asuro nach hinten, dann kommt die ganze Hand ins Blickfeld des IR-Detektors, der Asuro fährt rückwärts um wieder nach vorne zu kippen. Wieso es nur mit einem Zweipunktregler funktioniert, ist mir selbst noch nicht klar. Ich war der Meinung ein invertiertes Pendel braucht mindestens einen PID-Regler.
@Florian
Sensor und Code sind in dem bereits genannten Beitrag beschreiben:
https://www.roboternetz.de/phpBB2/ze...ag.php?t=11114
Zum Downloaden des Videos im GMX MediaCenter öffnet sich ein Pop-up Fenster, d.h. Pop-UPs müssen erlaubt sein. Falls Du Firefox verwendest, einfach oben klicken und Pop-up für die Website erlauben.
Gruß Waste
Hallo Waste!
Also das ist ein wirklich toller Erfolg! *HG*
Ich kann das Video, überigens sehr Eindrucksvoll, zwar ansehen, aber ich würde es gerne speichern, also auf meiner HD haben, wenn es mal nicht mehr unter dem Links zu haben sein sollte ...
@Florian
Zum Downloaden einen Haken in das kleine Feld neben Asuro2.mov, dann Datei klicken und Download. Falls dann kein Fenster kommt, dann hast Du Pop-ups geblockt. Pop-ups für diese Seite freigeben, dann sollte es klappen.
Wenn es noch nicht klappt, dann hier bei Rapidshare downloaden:
http://rapidshare.de/files/7219387/DSCN2963.MOV.html
Das Video heisst hier DSCN2963.mov.
Gruß Waste
Hallo Waste!
Danke für den Link zu Rapidshare, damit hats geklappt ...
Jetzt ist das Video gut archiviert ... ;o)
Hallo, alle zusammen!
Ich habe euren Diskussion verfolgt, und mir gedacht: so was will ich auch probieren! O:)
Darauf hin hab ich mir einen kleinen Roboter gebaut, welcher mit 2 mini Servos angetrieben wird. (ohne Servo Elektronik, PWM erzeugt der Mega8, und Treiber L293D)
Als Sensor verwende ich den ADXL 210 mit PWM Ausgang. (wobei die Spannungsversorgung stark entkoppelt ist, da sonst bei der Ansteuerung der Motoren das Ergebnis verfälscht wird).
Die Regelung erfolgt mittels PID Algorithmus.
Leider will der Bot einfach nicht auf 2 Räder stehen 8-[
Aber ich vermute, dass die Position des Sensors nicht ideal, und die gewicht Verteilung (wegen den Akkus) auch nicht optimal ist.
Ich habe schon versucht ein Gegengewicht zu montieren, ohne wirklichen erfolg.
Ich hoffe ihr könnt mir ein paar Tipps geben.
Dake im vorhinein!
Mit freundlichen Grüßen
PS: Hier ein paar Bilder leider nur mit dem Handy aufgenommen:
http://www.directupload.net/show/d/508/raP8C7O6.jpg
http://www.directupload.net/show/d/508/wv9IbKh8.jpg
http://www.directupload.net/show/d/508/xnaIk8Ch.jpg
Hallo Waste,
herzlichen Glückwunsch zum balancierenden Asuro.
Ich hoffe, daß es noch weitere Roboterfans versuchen und schaffen werden dem Asuro das Stehen beizubringen.
Aus Erfahrung mit meinem UCBalBot weiß ich, daß eine Zweipunktregelung auf den Abstand zum Boden funktionieren kann, wenn die Schaltfrequenz hoch genug ist.
Danke!
Aber das war Zufall, normalerweise geht das nicht so einfach. Ich werde es auch noch versuchen, den IR-Detektor so umzubauen, dass er den Abstand zum Boden misst.
@locked
Kannst Du uns mehr von Deinen Versuchen erzählen. Was geht, was geht nicht? Wie ist der PID-Regler dimensioniert worden? Taktrate?
Gruß Waste
Hallo Waste,
nun ja, ich habe die Regleparameter und die Tacktrate variabel gemacht. Dh ich kann via UART verschiedene Parameter einstellen.
Zum Versuch: Also wenn der P Anteil zu klein ist, hat er keine Chance sich zu korrigieren, mache ich den P Anteil größer beginnt er sofort zu schwingen. I Anteil verwende ich keinen. Der D Anteil verursacht das gleich (nur stärkeres Vibrieren)
Weiter habe ich versucht den Sensor nach unten, und das gewicht (Akkus) nach oben zu verlagern. Hat etwas mehr erfolg gebracht, jedoch fällt er nach wie vor um.
Ich habe auch schon größere Räder getestet, leider auch ohne erfolg.
Mit freundlichen Grüßen
Ich hab zwar keine Erfahrung mit dem ADXL, aber meiner Ansicht nach sollte der auch so hoch wie möglich angeordnet sein, damit er am wenigsten von der Beschleunigung des Antriebs mitbekommt. Das Problem mit den ADXL ist ja, dass sie auf alle Beschleunigungen reagieren, also auch auf die Beschleunigung durch die Ausgleichsbewegungen. Wenn man die nicht in der Regelung berücksichtigt, dann verfälscht es. Deshalb werden gerne Gyros zum Regeln mit hinzugenommen.
Den Schwerpunkt möglichst nach oben ist gut, dann braucht es nicht so viel Motorpower.
Wenn Du keine Möglichkeit hast die Regelstrecke zu analysieren und den Regler zu berechnen, dann hilft nur probieren. Dabei möglichst kleine Taktrate, denn jede zusätzliche Totzeit verschlechtert die Stabilität.
Gruß Waste
nun ja, das könnte der Grund sein, das er die Ausgleich Bewegung auch wertet. Ich dachte mir zwar das es nicht in gewicht fällt, aber kann schon möglich sein.
Das mit dem Gyro währe zu überlegen.
Wie könnte man eine solche Regelstrecke analysieren?
Mit freundlichen Grüßen
Hallo,
ich hab da noch eine Frage:
Ein Gyro misst ja den Drehwinkel oder?
Aber inwiefern kann ich dieses Signal dazu verwenden, um festzustellen in welchem Neigungswinkel sich der Roboter befindet?
Danke in vorhinein
Mit freundlichen Grüßen
Hallo locked!
Weil ein Gyro driftet, werden ADXL und Gyro oft in Kombination verwendet. Dabei werden vom Gyro nur die schnellen Änderungen ausgewertet, also hochpassgefiltert und beim ADXL nur die langsamen Änderungen (tiefpassgefiltert). Zusammen ergibt das dann ein schönes breitbandiges Signal. Wenn ich mich richtig erinnere, hat das auch UlliC mit Erfolg so gemacht.
Bezüglich Analyse solltest Du ein technisches Studium hinter Dir haben, sonst wird es schwierig. Google mal nach 'invertiertes Pendel Regler' oder auf englisch 'inverted pendulum controller', da sollte eine Menge Material auftauchen. Wenn Du damit nichts anfangen kannst, bleibt nur probieren übrig.
Waste
Hallo,
bezüglich der Filterung:
Übernimmt der uP die Filterung der Signale?
Oder ist es effektiver, wenn man Analoge Sensoren verwendet, diese auch analog Filtert und anschließend AD wandelt?
Mit freundlichen Grüßen
Da die Signale der beiden Sensoren unterschiedlicher Art sind, müssen sie sowieso angepasst werden. Da bietet sich die digitale Verarbeitung, also im µC an.
Waste
Also, da ein Gyro aus Kostengründen zurzeit nicht in frage kommt (und man keine Samples zurzeit bekommt) werde ich das Projekt etwas abändern. Und zwar habe ich mit gedacht den Versuch wie ein "echtes" 'invertiertes Pendel aufzubauen. Also unten ein Gefährt (mein Bot) und oben dran eine gelagerte Stange, von welcher ich über ein Poti den Neigungswinkel erfahren kann.
Bin mal gespannt ob der Regelalgorithmus mit dieser Konstruktion funktioniert.
mfg
Gute Idee, da sollte der Sensor das kleinere Problem sein. Wenn das funktioniert, dann in kleinen Schritten zum balancierenden Bot übergehen.
Waste
Oder benutze doch 2 Infararot Sensoren um in in der Wage zu halten, wie bei dem Bot hier..
http://www.balbots.com
ist die günstiegste alternative, und ich finde der Läuft ziemlich gleichmässig.
O.R
Schönes Beispiel für die Technik, mit zwei Abstandssensoren als Neigungssensoren. Auch die zwei Filme sollte man sich ansehen. Der Preis von 360-550$ erscheint mir ein bisschen hoch für das Fahrzeug.Zitat:
Zitat von Anubisbot
Manfred
Hallo,
ich wollte es eigentlich ohne optischen Sensor verwirklichen, also dachte ich mir ich nehme den ADXL den ich sowieso schon länger zuhause habe.
Leider verfälscht die Beschleunigung der Ausgleich Bewegung die Regelung anscheinet so sehr, dass der Bot nie balanciert.
Nachdem ich mir das Video angesehne habe, werde ich es doch mit einem Sharp Sensor versuchen. (weil ich mit den umbau auf ein "echtes invertiertes Pendel" erspare)
Meine Frage: Reagiert der Sharpsensor auf Farbunterschiede auch?
Dürfte eigentlich nicht der Fall sein, da dieser Sensor soweit ich informiert bin über das Triangulationsprinzip misst.
Mit freundlichen Grüßen
PS.: Was ist das eigentlich für ein eigenartiger Post von Gast?
Guck mal ins Datenblatt. Wenn ich mich richtig erinnere sind da zwei Unterschiedliche Kurven für schwarze und weisse "Meßobjekte" aufgetragen.Zitat:
Meine Frage: Reagiert der Sharpsensor auf Farbunterschiede auch?
Dürfte eigentlich nicht der Fall sein, da dieser Sensor soweit ich informiert bin über das Triangulationsprinzip misst.
Ich könnte mir vorstellen, dass das auch der Grund ist, warum der BalBot zwei Sensoren verwendet.
Wenn man einmal die Neigung nach vorne ind einmal nach hinten misst, müsste man die Farbabhängigkeit vom Untergrund halbwegs rausrechnen können.
Spams:
11.11.05, 20:16
12.11.05, 13:24
12.11.05, 18:31
13.11.05, 07:19
14.11.05, 11:35
16.11.05, 03:25
21.11.05, 16:28
22.11.05, 04:16
22.11.05, 23:28
23.11.05, 23:31
25.11.05, 08:37
25.11.05, 12:21
26.11.05, 00:47
27.11.05, 08:03
Protokoll zum Spam in diesem Thread.
Manf
Hi ,
ich habe ein wenig recherchiert und unter anahme das es möglich ist mit dem Sharp eine TWR zu bauen stellt sich mir trozdem folgendes Problem.
Ich habe jetzt einen Bot mit sharp und adxl aber komme nicht zum Ergbeniss oder auch nur näher dran.
Der equibot hat einen PID regler und ich denke es ist möglich eine Regelung zu basteln die theoretisch funktioniert aber:
Was sind Eingangs und Ausgabe Grössen?
Eingangsgrössen sind wahrscheinlich Schieflagewinkel, Scheiflagewinkeländerung, Kippmoment und?
Ausgabegrössen?
Und da hört mein Vertsändniss auf.
Ich habe mal versucht die Räder festzuhalten und dann rauszufinden bei welcher Schräglage welche Motorleistung nötig ist um den Robo schräg zu halten oder wieder aufzurichetn aber das hat auch nicht geklappt.
Ich denke dass, wenn Ich da keine neuen Erkenntnisse auftuen kann, ich das Projekt wieder einmotten werde.
mfg
Involut ](*,) ](*,) ](*,)
Eigentlich hast du doch erst mal nur eine Grösse mit der du reagieren kannst, und zwar deine Motorspannung.Zitat:
Ausgabegrössen?
Sehr präzise und hilfreiche Tipps kann ich dir leider nicht geben - ich habe es bisher ja selber nicht geschafft.Zitat:
Und da hört mein Vertsändniss auf.
Ich habe mal versucht die Räder festzuhalten und dann rauszufinden bei welcher Schräglage welche Motorleistung nötig ist um den Robo schräg zu halten oder wieder aufzurichetn aber das hat auch nicht geklappt.
Dass du von "Motorleistung" und "aufrichten" schreibst, hört sich für mich aber an, als würdest du dir vielleicht ein etwas falsches Bild machen.
Du kannst den Roboter nicht einfach mit Motorkraft wieder aufrichten.
Das würde nur funktionieren, wenn du die Räder am Boden festklebst.
Beim ruckartigen anfahren und abbremsen der Motoren wird zwar ein Moment auf den Roboter übertragen, den würde ich aber eher als Störgrösse betrachten und nicht als die Regelgrösse.
Es gibt einen Punkt bei dem dein Roboter im Gleichgewicht ist, und zwar wenn sein Schwerpukt genau über der Achse zwischen den beiden Rädern ist.
Da das ein labiles Gleichgwicht ist, bleibt der Roboter da nicht, sondern er kippt. Beim kippen verschiebt sich der Schwerpunkt vor oder hinter die Achse. Also muss der Roboter mit der Achse wieder unter den Schwerpunkt fahren. Dabei muss er schneller fahren, als sich der Schwerpunkt aufgrund der Massenträgheit von der Achse weg bewegt.
Dass die Achse ganz genau unter dem Schwerpunkt zum Stehen kommt wird nicht funktionieren, also sollte der Roboter lieber ein Stückchen zu weit fahren, damit er dann in die entgegengesetzte Richtung kippt.
Dann geht das selbe Spiel in die andere Richtung los.
Theoretisch müsste dafür schon eine 2-Punkt Regelung ausreichen. Wenn das Ganze schnell genug geht, klappt es ja offensichtlich auch, wie man an Waste's Asuro sieht.
Ein Problem bei meinem Fahrgestell - ich vermute das trifft auch bei deinem zu - ist, dass es ziemlich schwer ist. Daher verwende ich RB35 Motoren mit einer relativ hohen Untersetzung. Die reagieren nicht so schnell wie der Asuro von Waste. Ausserdem habe ich wesentlich grössere und breitere Reifen. Dadurch dürfte der Moment der auf den Roboter übertragen wird bevor die Räder überhaupt losdrehen (das was ich oben als Störgrösse bezeichnet habe) grösser sein als bei Waste's Asuro.
Die Sharps messen auch nicht so besonders schnell.
Um das alles zu kompensieren, braucht man dann vermutlich eine PID Regelung.
Wenn du da mit Mathematik rangehen willst, must du erst mal die Massenträgheit deines Fahrgestells berechnen, damit du weisst wie schnell er kippt.
Über den Neigungswinkel kannst du errechnen wie weit er fahren muss um wieder unter den Schwerpunkt zu kommen. Über die Trägheit kannst du berechnen wie schnell das gehen muss.
Ein paar Radencoder würden sicherlich auch helfen zu bestimmen wie weit das Fahrgestell schon gefahren ist ......
Da ich keine Radencoder habe und Mathematik nie mein Lieblingsfach war, habe ich immer noch die Hoffnung es klappt auch mit ein paar Schätzungen und viel Try&Error.
Wenn du vorne und hinten eine Stütze an deinen Roboter montierst, kannst du dich ein bischen rantatsten, wieviel Spannung du geben musst, damit Roboter von einer Seite auf die andere rüberkippt und wie weit er dabei fährt.
Ausserdem kannst du testen, wieviel Spannung du geben musst, damit die Räder sich überhaupt bewegen.
Weiterhin kannst du mal ausprobieren, wie schnell dein Motor unter Belastung überhaupt auf Spannungsänderungen reagiert.
Wenn du dein Fahrgestell mal an den Rädern baumeln lässt, kannst du abschätzen wie lange er pro Schwingung braucht und wieviele Messwerte du in der Zeit überhaupt bekommen kannst.
Ob das reicht um jemals eine vernünfige Regelung hinzubekommen weiss ich nicht. Auf jeden Fall sollte es aber die möglichen Parameter beim Try&Error Verfahren etwas einschränken.
Also soweit ich das Diagramm Fig4 interpretieren kann fällt der Farbunterschied (Reflectivity) erst bei 16cm abstand minimal ins gewicht. Wobei der Abstand bei meinem Bot nie größer als 16cm sein wird. O:)Zitat:
Zitat von recycle
Mit freundlichen Grüßen
Hallo,
ist jetzt vielleicht etwas off Topic aber trotzdem,
ich habe vor 2 Jahren einmal so eine Schwebende Kugel gebaut, hat auch bestens funktioniert, jedoch habe ich den PD Regler Analog (mit OPs) realisiert.
Heute habe ich mir gedacht ich schließe diese Kugel an den Mega8 an und versuche sie über die PID Software (von meinem Bot etwas abgeändert) zu regeln. :-k
Und siehe da, nach ein paar wenigen Parameter Einstellungen Schwebt die Kugel Digital O:) \:D/
Mit freundlichen Grüßen
@locked
Hört sich doch gut an.Zitat:
Also soweit ich das Diagramm Fig4 interpretieren kann fällt der Farbunterschied (Reflectivity) erst bei 16cm abstand minimal ins gewicht. Wobei der Abstand bei meinem Bot nie größer als 16cm sein wird.
Davon abgesehen, würde es mir sowieso erst mal reichen die Regelung so hinzubekommen, dass der Roboter auf einer farblich einheitlichen glatten Oberfläche balanciert.
Wenn das erst mal geschafft ist, kann man den Schwierigkeitsgrad immer noch auf unterschiedliche Oberflächen erweitern.
Bei einem balancierenden Roboter fände ich auch den umgekehrten Weg recht interessant.Zitat:
ich habe vor 2 Jahren einmal so eine Schwebende Kugel gebaut, hat auch bestens funktioniert, jedoch habe ich den PD Regler Analog (mit OPs) realisiert.
Heute habe ich mir gedacht ich schließe diese Kugel an den Mega8 an und versuche sie über die PID Software (von meinem Bot etwas abgeändert) zu regeln.
Aber eins nach dem anderen, hauptsache er balanciert überhaupt erst mal ;-)
Ein balancierender Bot ist von der Thematik her schon ziemlich kompliziert, das mußte ich jetzt auch feststellen, nachdem ich mich auch damit befasst habe.
Grundsätzlich reicht ein PID- oder PD-Regler aus, um eine inverses Pendel (balancierenden Bot) zu stabilisieren. Aber in der Praxis hat das einen Haken. Da ein PID-Regler ein SISO-Sytem (single Input single Output) ist, kann er nur eine Regelgröße überwachen und eine Stellgröße ausgeben. Beim inversen Pendel ist die Regelgröße der Winkel, der so geregelt wird, dass das Pendel aufrecht stehen bleibt. Dabei kann sich aber eine beliebige konstante Geschwindigkeit des Bots einstellen. Um auch noch die Geschwindigkeit oder die Position mit zu berücksichtigen braucht es eine Mehrgrößenregelung. Das kann z.B. ein Zustandsregler (ist sehr kompliziert). Erschwerend kommt noch hinzu, dass ein Neigungssensor wahrscheinlich immer einen kleinen Offset hat. Die PID-Regelung wird den Bot genau auf den Offset (=Neigung) regeln. Um die Neigung stabil zu halten, bedarf es einer konstanten Beschleunigung, d.h. in der Praxis wird der Bot nach dem Einschwingen in eine Richtung solange beschleunigen, bis er nicht mehr kann und umfällt.
Ich habe meinen Asuro (mit Abstandssensor zum Boden ausgerichtet) nur in einer Mulde ins Gleichgewicht gebracht. Da kann er sich dann an den richtigen Abstand hin regeln. Auf einer ebenen Fläche klappt es bei mir auch noch nicht. Ich muss also auch noch eine 2. Regelgröße ins Spiel bringen. Da bin ich auch erst durch die Versuche darauf gekommen.
Waste
Das mit dem Finden der senkrechten Stellung stelle ich mir so vor:
Die Sensorwerte für die ausbalancierte Stellung sind zunächst nicht bekannt und werden nach bester Schätzung angenommen. Das Fahrzeug regelt auf diese Stellung, muss sich dabei aber bewegen. Diese Bewegung wird gemessen und gemittelt und der Sollwert der senkrechten Stellung wird dadurch korrigiert.
Auf diese Weise sollte es möglich sein, auf ebenen und auch auf leicht schrägem Untergrund zum im Mittel zum Stehen zu kommen oder im nächsten Schritt, sich mit einer vorgegebenen mittleren Geschwindigkeit zu bewegen.
Manfred
Ja, so ähnlich habe ich es vor. Leider kann ich die Odometrie vom Asuro dazu nicht verwenden, da man damit nicht herausfindet ob es vorwärts oder rückwärts geht. Ich will deshalb auf einen sogenannten Beobachter (virtuellen Sensor) zurückgreifen.
Außerdem habe ich noch andere Baustellen zu bearbeiten. Z.B. arbeitet der Abstandssensor nur digital. Da muss ich mir noch was überlegen. Die Empfindlichkeit (Entfernung) kann ich senderseitig zwar mittels Pulsbreite einstellen, aber bei der geringen Entfernung ist die Auflösung zu grob. Da will ich noch eine gebrochene (fractional) Einstellung testen. Da ist schon eine gehörige Portion an Kreativität gefragt, um mit den Gegebenheiten des Asuros zurecht zu kommen. Klar, ich könnte einen anderen Sensor einsetzen, aber vorerst will ich es so probieren.
Waste