Hi Jo, bei 16MHz sind 25 clock cycles 1.5625 µs, richtig? 10 µs sind also in jedem Fall auf der sicheren Seite. Gewartet haben wir über den Timer 1, der hochgezählt wurde und bei ich weiß nicht mehr genau, aber so um 10 µs eine Variable auf "TRUE" gesetzt hat. Ich probier's trotzdem mal aus!
Lisbeth2010
Das steht im Sourcefile des Nibo/adc.c:
// Warten bis konvertierung beendet, das sollte 25 ADC-Zyklen dauern,
// also 1/4608 s
while ( (ADCSRA & _BV(ADSC)) != 0) {
__asm volatile("nop");
}
Funktioniert aber nicht! Sonst würde der erste Wert ja nicht falsch sein.
@Jo:Was soll ich mit dem Link?
Grüße Lisbeth2010
Hallo Lisbeth
Leider ist das mit den Erklärungen so beim Nibo. Viele Sachen probieren wir aus. Ab und zu kommen ein paar Infos. In anderen Foren läuft es besser. Auch der Kollege vom Asuo ist hier fast ständig vertreten. (Siehe Randleiste - Mitglieder). Bei einer Frage habe ich nicht schlecht gestaunt. Die Antwort war ohne Probleme wieder auf meinem Rechner und gut erklärt. Das Gefälle zwischen den Usern ist recht gross. Ich selber zähle mich auch zu den Anfängern. Vielleicht komme ich mal auf eine höhere Stufe. Es ist nur Schade um den Nibo. Ist so ein recht netter kleiner Kerl. In ihm steckt noch viel drin. Ist scheint nun an uns zu sein, was draus zu machen. Die Hardware haben wir. Jede Verbesserung der Software bringt uns Vorteile. Wenn der Hersteller meint, sich in Schweigen zu Hüllen, dann muss er auch mit diesen Seiten und den Meinungen fertig werden. Du hast ja auf seinen Seiten auch ganz schön losgelegt. Lasse mich überraschen wie es weiter geht. Viele User verfolgen diese Diskussion recht Neugierig. Es werden sich aber nur wenige dazu äussern. An Hand der mails die ich bekomme, kann ich das gut verfolgen. Kan dich nur bitten beim Nibo zu bleiben und uns zu helfen. Ich kann den Usen meine ganzen Programme zur Verfügung stellen. Sind extra geschrieben für Anfänger und Fortgeschrittene. Bisher habe ich alle so aus dem Bereich Test. Alle haben reichlich Kommentare und sind gedacht selber was draus zu machen. Werde demnächst eine Liste ins Netz stellen. Kurze mail und das Prg kommt als Worddatei.Hoffe weiter auf deine Unterstützung und Hilfe. Lass uns gemeinsam was draus machen. Habe noch einige Ideen.
Achim S.
Hallo Lisbeth
Deine Kommentare sind von der anderen Seite verschwunden.
Allenfalls das Video ansehen. Ich erzähle nicht gerne "Erfolg gehabt" ohne dies halbwegs glaubhaft dokumentieren zu können. Warum ansehen? Um zu sehen, dass der ADC schnell und genau laufen kann; sonst könnte er die Balance-Regelung nicht ingang halten. Er kann das.Zitat von Lisbeth2010
Uuups! Verschunden ist gut. Elektronische Datenverarbeitung ist das - man verarbeitet Informationen zu einer Elektronenwolke. Anders ausgedrückt: manche finden Kritik gut - solange es pures Lob ist.
Ciao sagt der JoeamBerg
Hi
@elektrolutz - wie willste denn sauber (!) einen Regler optimieren, der auf einem Atmega88 läuft, auf den man keinen direkten Zugriff hat? Außerdem kannste nur ki, kp, kd einstellen.. sinnvoll wäre es, wenn man den Atmega88 DIREKT programmieren könnte
Der Nachteil des Reglers ist auch, daß er für BEIDE Motoren gilt....
und ob der zyklische Programmteil langsam ist - das hängt vom Code ab. Klar ist, das der check/Aufruf der copro_stop() fkt in einer ISR mehr bringt - aber der copro_stop() stoppt auch alle anderen ISR... (da cli() und sei()) und dann tut man sich doch etwas schwer, wenn man da noch Zeiten per ISR/Timer messen will
mfg
Hero_123
@Lisbeth2010
Hast Du nun mal den Bremsweg deines Nibo gemessen oder nicht??
@elektrolutz
wie stehts mit dem Bremsweg deines NIBO2??
Hero_123
Hallo Hero_123,
richtig, einzige Möglichkeit ist, ein wenig mit ki, kp und kd herumzuspielen und optisch zu erfassen, ob es besser oder schlechter wird. (Wenn überhaupt erkennbar.) Zudem habe ich keine Ahnung, welche Default-Werte eingesetzt sind - habe allerdings auch noch nicht übermäßig viel danach gesucht.
Grundsätzlich müsste man erst einmal prüfen, ob und welche Wirkungen man durch Spielen mit den Parametern erzielen kann. Sind dabei überhaupt Unterschiede zwischen beiden Antrieben erkennbar?
- Wenn ja, dann müsst man bei "workwind" eine entsprechende Änderung beantragen [-o< .
- Wenn nein, dann kann es so bleiben.
Dass copro_stop auch die anderen ISR stoppt hatte ich jetzt nicht im Auge, aber zumindest könnte man, wie von workwind vorgeschlagen, in einer ISR den/die Regler auf "BRUTAL" stellen und entgegengesetzt beschleunigen. Ist sicher nicht die edelste Lösung, dürfte aber von Elektronik und Mechanik verkraftet werden.
Ob die Bodensensoren tatsächlich als Absturzsicherung vorgesehen sind, kann ich nicht erkennen, in der Anleitung steht nur, dass die Sensoren Abgründe erkennen können - und das funktioniert.
Spass bei Seite, ich denke, man sollte die gesammelten Erkenntnisse gut begründet zusammenfassen und workwind dazu ansprechen. Nur so lebt das Produkt weiter und Fehler sowie nicht bedachte Eigenschaften können verbessert werden. Die nächste Lib mit FW kommt bestimmt.
Gruß aus Werl
elektrolutz
Theorie ist, wenn man weiß, wie alles funktioniert. Praxis ist, wenn alles klappt und keiner weiß warum!
Hallo nibo-Freaks,
vielleicht helfen ein paar Anregungen von meinen einigermassen gelösten Regelungsfragen, die aber nicht den NIBO mit egal welchem Index betreffen.
Hardware: einfach aufgebaute Hardware, Antrieb mit zwei Kleinstgetriebemotoren, eigener Umbau aus billigsten Servos, etwa 180 tics pro Radumdrehung (2 Ticks pro Motorumdrehung), Raddurchmesser 24 mm, gesamter Aufbau hier gezeigt. Regelung und alle sonstigen Funktionen mit einem einzigen Controller mega168/m328p mit 20 MHz.
Die von mir aufgebaute und mittels Sprungantwort bzw. den daraus abgeleiteten Kennwerten dimensionierten Regelroutinen (je eine Routine pro Motor) laufen recht schnell . Das ist durch Integer-Werte bei ziemlich geringer CPU-Auslastung, ca. 5%, gut zu schaffen. Die einzelnen Regleranteile habe ich in 100-Werte-langen Messschrieben nach Testfahrten ausgegeben und mir als Diagramm angesehen. Da kann man gut Überschwinger oder sonstige Eigenschaften erkennen - und natürlich auch Auswirkung von Parameteränderungen. Viele Testfahrten, viele Diagramme, viele fruchtlose Änderungen aber immer wieder mal ein Fortschritt. Als Rumspielerei konnte ich das nicht bezeichnen, da muss man schon ein paar Notizen mit Bleistift und Papier und immer wieder mal eine modifizierte Parameterberechnung mitführen.
Natürlich habe ich auch Bremsmanöver nach verschiedenen Verfahren vermessen. Einfaches, gestuftes Gaswegnehmen, abrupte Wegnahme der Motorversorgung - und als Powerbremse mit bester Bremswirkung: Gegengas (macht man mit jedem größeren Motorboot genauso). Die Diagramme sind über den eben genannten Link erreichbar.
Damit habe ich eine relativ gute Reproduzierbarkeit meines R3D01/MiniD0 erreicht. Es ist schon ein wenig Arbeit reinzustecken, bis es so läuft. Für meinem Nibobee habe ich so eine Regelung nicht gebaut. Da ist soviel Bibliothekszeug drin, das ich erst mühselig entsprechend meinen Ansprüchen übersichtlich aufbereiten müsste - die Arbeit habe ich mir nicht gemacht.
Ciao sagt der JoeamBerg
Hallo alle zusammen!
Bremsweg ermitteln: Hat jemand einen Hinweis, wie man à la ASURO eine Messfahrt durchführen kann: Auslesen während der Fahrt gespeicherter Daten nach Abschluß der Fahrt in ein Terminalprogramm? Stichwort UART.
Danke!
@oberallgeier: Ich bin - wie 123_Hero auch - kein Löter und Bastler, sondern mehr für Software mit bestehender Hardware.
@elektrolutz: Wie und wo fasst man die gesammelten Erkenntnisse am besten zusammen?
Lisbeth
(Übrigens kann ich keine Entfernung von mir geschriebener Beträge finden! Will dem auch nicht weiter nachgehen.)
Berechtigungen
Zitieren
Lesezeichen