Hallo Sven,
dann bin ich mal auf weitere Fortschritte gespannt.
Hallo Harry,
ich bekomme Pipi im Auge, wenn ich hier so mitlese *LOL*
Bin beim Surfen bin ich auf dieses Video gestoßen.
Wobei das hier auch nicht schlecht ist.
Gruß Ingo
Hallo Sven,
dann bin ich mal auf weitere Fortschritte gespannt.
Hallo Harry,
ich bekomme Pipi im Auge, wenn ich hier so mitlese *LOL*
Bin beim Surfen bin ich auf dieses Video gestoßen.
Wobei das hier auch nicht schlecht ist.
Gruß Ingo
Meine Webseite
http://www.pc-braunschweig.de
Ohje daran habe ich auch gedacht... wir sind alle so gut wie tot.
Nils heißt unsere zukünftigen Roboterherren willkommen...
Harry: Ich habe bei den ersten evrsuchen wohl zu schnell zurück geschaltet, er erechnet einen Mittelwert aus 20 einzelwerten, frag mich nicht wie lange das dauert.
Hi Ingo,
wenn ich dich richtig verstehe, dann unterstellst du mir, dass ich Nils hochnehmen will.
Das entbehrt natürlich jeder Grundlage, ich bin einfach ein Weichei, was bestimmte Dinge angeht, und da gehört der Tri seit meinem letzten Kampf leider dazu.
Du kennst das ja: Wer schon mal gebissen wurde, ist ist in Zukunft vorsichtiger im Umgang mit Hunden
Außerdem kann ich im Moment nix selbst testen, mein Tri liegt mit zwei gebrochenen Flügeln in der Werft
Ich bin Nils also sehr dankbar, dass er meine Fragerei stoisch hin nimmt.
@Nils:
Wenn ich Willas Aussage noch richtig im Kopf habe, dann errechnet er neue Vorgabewerte für die ESCs mit 300 .. 400 Hz, mithin dauert ein Durchlauf seiner Hauptschleife 2,5 .. 3 ms.
20 Iterationen zur Mittelung sind dann nach 50 bis 60 ms fertig... so schnell kannst du den Schalter gar nicht zurück stellen, wenn du nicht gerade auf Speed bist
Hab mir den Code gerade noch mal reingezogen... Vergiss den Text oben, ist vollkommen anders gelöst.
Wenn der Schalter umgelegt wird, läuft die Mittelung der 20 Werte in Höchstgeschwindigkeit in eine Schleife ab, die durch zurück stellen des Schalters nicht unterbrochen werden kann. Genau genommen kann diese Schleife durch gar nichts unterbrochen werden, auch der Tri wird in dieser Zeit weder vom Sender noch von der TriGUIDE gesteuert, insofern ist es gut, dass dieser Vorgang sehr schnell vorüber ist
Dass du Probleme mit zu schnell wieder zurück schalten hattest, verstehe ich also eher nicht.
Allerdings ist dieser Programmteil so geschrieben, dass er immer wieder durchlaufen wird, solange der Schalter (im Flug, also wenn Gas >50 ist und die Motoren mal liefen) auf Off steht.
Das könnte man ggf. noch umschreiben, so dass die Mittelung nach einem On->Off-Übergang nur einmal Statt findet. Genauer wird der Wert durch mehrere Durchläufe direkt hintereinander nämlich nicht, eher ist die Gefahr gegeben, dass der Tri zwischenzeitlich durch äußere Einflüsse weg kippt und die mühsam eingetrimmte Horizontale aufgibt, die Routine sich also Schrott ausrechnet.
@Hans:
Und wenn ich schon am meckern bin... äh, ich meine Vorschläge habe (Hans, verzeih mir!)...
Es würde reichen, beim Abspeichern nur die beiden neuen Werte ins Flash zu schreiben, der Rest sollte unverändert sein. Die Schleife über alle Vars ist also unnötig. Oder habe ich was übersehen?
... später...
Nein, im Gegenteil!
Beim Auslesen der Variablen aus dem EEPROM (Routine Geteeprom) wird bei verschiedenen Variablen was abgezogen, dazu gerechnet, multipliziert oder geteilt.
Da du beim Abspeichern nach der Landung alle 33 Var(x) 1:1 ins EEPROM schreibst (Ausnahme Var(23) und Var(24), die du gerade neu berechnet hast), werden die Vorgabewerte also verfälscht. Das solltest du dir nochmal anschauen.
Geändert von deHarry (29.03.2011 um 08:24 Uhr)
Na stoisch würde ich das nicht nennen, ich lerne ja selsbt am meisten wenn ich mich damit ebschäftige.
1. mache ich es gerne
2. brauche ich ja auch immer wieder Hilfe
Harry,was meinst Du mit dem verfälschen? wie äußert sich das? Welche Werte?
Am Wochenende habe ich mal den IMU-Würfel mit den neuen Gyro-Board aufgebaut:
Bild hier
Bild hier
Bild hier
Bild hier
Bild hier
Bild hier
Bild hier
Bild hier
Bild hier
Bild hier
Funktioniert zumindest am Schreibtisch Einwandfrei
Die Idee den Offset im Flug neu einzustellen ist einfach genial.
Das werde ich ausprobieren sobald ich die Zeit finde.
Wenn das wirklich so gut klappt wie beschrieben würde das eine Menge Arbeit sparen.
Hallo
Freut mich.GENIAL, jetzt kann ich so fliegen, und danach die GoPro draufstecken ohne an den Laptop zu müssen und hab ein absolut austariertes System!!
@deHarry @Javermeister :
Für jede Schalter betätigung und zurücksetzung werden nur einmal 20 Werte errechnet egal wie schnell du mit den Schalter bist.
@deHarry
Wie gesat es wird nur einmal durchgerechnet (siehe variabel switch_validation)
Ich habe mal versucht nur vars 23 und 24 zu schreiben und hat damals nicht geklappt also dann alle Werte. Geht schnell genug.
Nichts außer var(23) und var(24) wird modifiziert. Array Werte (1..30) bleiben immer gleich. (Siehe Convert_Vars wo diese ungerechnet ABER als andere Variabeln benutzt werden z.b. P_sens_acro = Var(7) / 255 Var(7) bleibt unverändert.
Hoffe das erklärt alles.
@deHarry bist schneller als ich beim Antworten gewesen
Gruß
Hans
Man kann besser reinschaun als es auf dem Bild rüber kommt,Schluss nicht mehr so gut reinschauen kann . Aber das macht die Beleuchtung mehr als wett.
die Gyros kann man gut sehen.
Aber das Problem ist immer das die Dämpfe vom Sec.Kleber das Makrolon Trüben.
Das war leicht![]()
Ich hänge gerade zu Hause rum und warte, dass der Handwerker im Keller fertig wird. Da kann ich auch was Sinnvolles machen (z.B. vorschnell nicht vollständig verstandenen Code von anderen Leuten auseinander nehmen)...
Danach bin ich dann weg und normaler Weise nur abends und am WE online.
Danke!
Verfälschen... mhmm...
Mist, zu schnell gepostet, oder zu wenig Hirn eingeschaltet
Ich habe den Code nur zur Hälfte verstanden und falsch interpretiert, sorry. Die Var(x) werden von der Routine von Hans NICHT verfälscht. Seine Behandlung der Variablen ist ok.
Ich habe z.B. gelesen: "P_sens_acro = Var(7) / 255"
Habe aber nicht kapiert (also kapiert schon, aber vollkommen überlesen (Hirn ausgeschaltet)), dass die Var(7) zwar geteilt wird, aber nicht sich selbst sondern einer weiteren Variabeln P_sens_acro zugewiesen wird.
In Var(7) steht weiterhin der aus dem EEPROM gelesene Wert drin und wird von Hans dann einfach wieder zurück geschrieben. Das ist vollkommen in Ordnung so!
Mein Vorschlag, er bräuchte nur die beiden veränderten Werte zurück ins EEPROM zu schreiben, gilt aber weiterhin.
Geändert von deHarry (29.03.2011 um 09:19 Uhr) Grund: Zitat eingebaut, weil fat Tony dazwischen gerutscht ist
Lesezeichen