Hi Leute,
mein Problem besteht noch : meine weißen Pentium 10A ESCs melden sich nicht, wenn die nanowii hochgefahren ist.

ABER: Wenn ich das zweite Mal über arduino 1.0.1 die Software (20120606) hochlade, dann funktionieren die Regler!
Ich kann das USB Kabel abziehen und (theoretisch) fliegen. Ziehe ich jetzt aber den Strom ab und stecke ihn sofort wieder dran, schalten sich die Regler nicht mehr an.

Ich habe mincommand auf 950 und minthrottle auf 1380 (aufsteigend von 1120). Gibt es hierzu evtl. einen bugreport oder noch besser eine Abhilfe ?

Wenn ich die nanowii an meinen bestehenden QuadX hänge, dann schltet er dort auch nur zwei von vier ESCs an. Ist der Fehler nun in den ESCs, der nanowii oder in der Softwarekonfiguration zu suchen?

segelpeter63 hat geschrieben:Hi Roswhite aka Tilmann, ich sehe auf Deinem Bild, dass Du eine Multiplex Funke hast. Fliegst Du mit Summensignal, wenn ja, mit Summensignalkonverter (welcher)? Oder hast Du die Multiplex auf Spektrum FASST umgebaut.

Danke und Gruß

Peter

Hallo Peter,

FASST ist Futaba, nicht Spektrum.

Ich habe in der Royal Evo ein Spektrum-Modul drin und fliege mit DSM2. Wieso fragst Du nach Summensignal? Ich habe doch oben geschrieben, dass ich einen Spektrum Satelliten direkt angeschlossen habe.

r0sewhite hat geschrieben:Schon mit dem Flydumini hatte ich unerklärliche "Ausraster", wenn ich mal etwas wilder geflogen bin. Jetzt mit dem neuen Mini und dem NanoWii drauf, kann ich das Problem endlich sogar reproduzieren und damit dokumentieren.

Beide Quads sind bis auf die Motoren gänzlich unterschiedlich, daher kann man wohl ein Hardwareproblem ausschließen. Das Problem zeigt sich nach harten Stops (z.B. nach einem Flip) oder sonstigen heftigen Steuerbefehlen: Der Quad flippt auf einmal völlig unkontrollierbar herum und stürzt anschließend ab. Hier in dem Video sieht man gut, was passiert: Die gegensteuernden Motoren (und nur die) bleiben quasi auf Vollgas für eine kurze Zeit hängen. Anschließend schalten alle Motoren auf Minthrottle und nehmen auch kein Gas mehr an. Nach einigen Sekunden schalten sich die Motoren dann ab.

Ich glaube, dass das Problem nur den MPU6050 betrifft und somit auch nur MultiWii-Versionen ab v2.0. Zumindest betraf es in beiden Fällen sehr kleine Copter mit einem MPU6050 drauf. Hat das jemand schon mal erlebt?

Hi Tilman,

ich habe hier bis auf frame, regler und motoren genau das gleiche setup (auch ähnliche größe ) und habe versucht dein problem nach zu stellen.. aber ohne "erfolg"..

ich vermute stark das es doch was an sender oder empfänger ist. .. weil der satellit, wenn er kein signal vom sender bekommt sehr extreme werte aus giebt .. bei mir sind dann alle kanähle auf 998 .. hast du einen 1024 oder 2048 satelliten?

also was ich denke .. irgentwie wird das signal gestört -> der satellite giebt volle anschläge aus -> er versucht mit allem was er hat zu gieren .. dann greift failsave ein und der copter lässt sich nicht mehr steuern ..

könntest du das nochmal mit deaktiviertem failsave versuchen?

gruß

felix

[edit]
habe mir grad nochmal das video angeguckt .. und der satellit blinkt sobald das passiert .. was doch signalverlust bedeutet oder?
[edit]

[nochmal edit]
der blinkt ja die ganze zeit??

wenn ich mit futaber fliege und aus der reichweite kommen gibt es im menü der funke zwei möglichkeiten.
einmal gibt der empfänger die letzten empfangenden daten weiter hin aus.
oder ich kann eine bestimmet servo position ausgeben lassen.

was aber zb ein naza braucht is das der empfänger einfach mal nichts mehr ausgibt.
wie macht man das mit futaba ???

Felix, es gehen genau die Motoren auf Vollgas, die in dem Augenblick hart gegen meine Bewegung steuern:
- Wenn ich den Copter hart nach vorne kippe, sind es die vorderen Motoren (Nick Ausgleich)
- Wenn ich den Copter hart um die Hochachse drehe, sind es zwei gegenüberliegende Motoren (YAW Ausgleich)

Es handelt sich also um einen definitiven Lageausgleich der FC und kein Empfangsproblem oder fehlerhaftes Steuersignal vom Sat/Empfänger. Wenn ich normal fliege, kann ich bis weit über die Sichtgrenze hinaus fliegen.

Failsafe ist im Sketch übrigens deaktiviert und wenn ich den Sender ausschalte, geht der Quad einfach auf Minthrottle und macht weiter nichts. Zudem habe ich es ja mit zwei weiteren Sats gegen geprüft.

Meine Sats habe ich übrigens immer mit 1024 im Sketch aktiviert. Hab's mal mit 2048 probiert, da kam nur Signalbockmist dabei heraus.


EDIT: Der blinke Sat zeigt nur, dass ich den Sender nicht ausgeschaltet hatte, nachdem ich den Akku einmal ab und wieder angeklemmt hatte. Der blinkt nach jedem Akkuwechsel, da das ja auch ein Empfangsverlust ist. Ist also völlig normal.

Hallo,

Habe nun neue Latten bekommen und noch mal mit den einstellung gespielt.
Irgend wann ist mir klar geworden das mein Wobbeln nicht von der einstellung kommt, deswegen habe ich mir heute ein drehzahlmesser gekauft.

Beim messen habe ich dann festgestellt das der Motor vorne rechts sehr stark schwankt.

Wie kann ich das Problem beheben?

r0sewhite hat geschrieben:

segelpeter63 hat geschrieben:Hi Roswhite aka Tilmann, ich sehe auf Deinem Bild, dass Du eine Multiplex Funke hast. Fliegst Du mit Summensignal, wenn ja, mit Summensignalkonverter (welcher)? Oder hast Du die Multiplex auf Spektrum FASST umgebaut.

Danke und Gruß

Peter

Hallo Peter,

FASST ist Futaba, nicht Spektrum.

Ich habe in der Royal Evo ein Spektrum-Modul drin und fliege mit DSM2. Wieso fragst Du nach Summensignal? Ich habe doch oben geschrieben, dass ich einen Spektrum Satelliten direkt angeschlossen habe.

Danke, halt ne Wissenslücke von mir, da ich seit eh und je Multiplex fliege, hab ich mich nie mit Satelliten und dergleichen befasst. Stehe halt vor dem Problem, nur max. 5 Kanäle verwenden zu können ( wegen dem Paris v.2 Board). Nun überlege ich (um bei 2,4 GHz zu bleiben) einen Summensignalwandler (z.B. Quadro PPM) zu verwenden oder aber den vorhandenen auf Summensignal umgebauten R700 Empfänger 35 MHz zu verwenden. Mit dem Mikrokopter fliege ich auch noch 35 MHz und hatte bisher noch keine Probleme.

Gruß

Peter

ThorstenS hat geschrieben:Hi Leute,
mein Problem besteht noch : meine weißen Pentium 10A ESCs melden sich nicht, wenn die nanowii hochgefahren ist.

ABER: Wenn ich das zweite Mal über arduino 1.0.1 die Software (20120606) hochlade, dann funktionieren die Regler!
Ich kann das USB Kabel abziehen und (theoretisch) fliegen. Ziehe ich jetzt aber den Strom ab und stecke ihn sofort wieder dran, schalten sich die Regler nicht mehr an.

Ich habe mincommand auf 950 und minthrottle auf 1380 (aufsteigend von 1120). Gibt es hierzu evtl. einen bugreport oder noch besser eine Abhilfe ?

Wenn ich die nanowii an meinen bestehenden QuadX hänge, dann schltet er dort auch nur zwei von vier ESCs an. Ist der Fehler nun in den ESCs, der nanowii oder in der Softwarekonfiguration zu suchen?

Hallo Thorsten,

auch wenn es nicht unbedingt vergleichbar ist:
bei meinem ersten Versuch mit der Version 20120522 hatte ich das Problem, dass die Motoren sich nicht starten ließen.
Weil sowieso vieles anders als bei meiner letzten Version 1.9 ist, ging ich die config.h einmal komplett Zeile für Zeile durch und stolperte über einige (für mich) Ungereimtheiten,
MINTHROTTLE, MAXTHROTTLE und MINCOMMAND tauchen an mehreren Stellen auf, mal aktiv, mal auskommentiert,
und
es gibt eine Passage, wo man festlegt, ob man mit Throttle_Links oder Roll_Links die Motoren scharfschaltet,
"ALLOW_ARM_DISARM...." wobei beide Optionen im Original aktiv sind.

Ich habe nur die eine Option mit THROTTLE_ARM aktiviert - aus Gewohnheit - und allerdings noch weitere Einstellungen getätigt... jedenfalls gingen beim darauffolgenden Startversuch die Motoren an!

Manfred

Michael Brakhage hat geschrieben:

Zuse hat geschrieben:Guten Abend zusammen,

.....
Bevor ich noch mehr Aufwand in die Parametrisierung stecke:
gibt es mindestens einen entscheidenden Vorteil gegenüber der Version 1.9, wenn als Hardware ausschließlich ein ProMini, eine ausgeschnittene ITG3205 Einheit und evtl. ein externer ADXL345 für die Regelung eines 4-Motor-X-Aufbaus mit 800g Kampfgewicht zum Einsatz kommt?

Manfred

Hallo Manfred

ich lese, das du einen itg3205 verwendest. die dinger sind immer etwas zappelig gewesen. keine ahnung warum. der 3200 ist wesentlich besser geeignet.
am einfachsten wird es sein, wenn du dir ein "moderneres" imu board zulegst. empfehlen kann ich dir das flyduino mpu6050. dort ist ein gyro+acc in einem chip verbaut. der mpu6050 ist um längen genauer und fliegt einfach klasse!
einfach meine meinung zu deinen komponenten. den rest kannst du beibehalten!

Hallo Michael,
danke für den Tip.
Dennoch - wenn ich den identischen Hardware-Aufbau mit der Version 1.9 versorge, gibt es kein Zappeln.
Lediglich - und daran arbeite ich - eine Drift nach dem Abheben nach z.B. Links-Hinten, die, wenn ich gegensteuere, sich zum Schwingen aufschaukelt.
Deshalb war meine Frage oben nicht, ob ich mir einen anderen Sensor zulegen sollte, sondern die, ob es einen entscheidenden Vorteil für die Version 2.0 gibt, regelungstechnisch gesehen, wenn ich nur den Gyro und allenfalls den ACC verwende, kein GPS, keinen MAG, keinen BARO oder was sonst noch.
Ich denke allenfalls noch an mein herumliegendes Ultraschall-Modul für irgendeine Spielerei auf der fliegenden Plattform.

Gruss Manfred

@Fussel : welche WMC-Version hast du drauf ? Wenn es eine 2.0 ( pre1 , pre 4 oder so ) ist, liegt es daran. Ich hab das Problem mit meinem Flydumini, der fliegt mit der 2.0 wie Nüsse. Mit der 20120606 Dev-Version sind da Welten zwischen, kein wobbeln, kein zittern, nix.

Das einzige was die Version an Macke hat : mit dem ProMini wird nicht immer eine saubere Verbindung zur GUI aufgebaut, wenn man keine Sensordaten erhält muß man einmal den Reset-Taster auf dem ProMini betätigen, dann geht alles. Tritt bei mit mit Promini und MPU6050 auf.

Zur Sicherheit gehe ich her und mache das selbe, wenn cih nen Akku angesteckt habe - bevor die Version da evtl. auch ein Problem haben sollte hab ich keinen Bock auf Eigenleben im Copter

@Felix : gibt es eigentlich mittlerweile einen Workaround für Win-PCs ( XP ) auf denen die GUI der aktuellen DEV´s nicht läuft ?

Ich habe den Eindruck das der Fehler wohl in Verbindung mit onboard-GraKa´s auftritt da meine betroffenen PCs beide Onboard-Grafik haben, also Shared Mem verwenden.

Falls meine Zeit es erlaubt werde ich morgen mal versuchsweise den ganzen Sulms auf meinen Büro-PC mit sep. Grafik installieren um das hardwareseitig halbwegs zu verifizieren, damit ihr da in der Richtung auch schaun könnt was los ist, sofern das Problem noch nicht eruiert werden konnte.

Crizz hat geschrieben:@Fussel : welche WMC-Version hast du drauf ? Wenn es eine 2.0 ( pre1 , pre 4 oder so ) ist, liegt es daran. Ich hab das Problem mit meinem Flydumini, der fliegt mit der 2.0 wie Nüsse. Mit der 20120606 Dev-Version sind da Welten zwischen, kein wobbeln, kein zittern, nix.

Das einzige was die Version an Macke hat : mit dem ProMini wird nicht immer eine saubere Verbindung zur GUI aufgebaut, wenn man keine Sensordaten erhält muß man einmal den Reset-Taster auf dem ProMini betätigen, dann geht alles. Tritt bei mit mit Promini und MPU6050 auf.

Zur Sicherheit gehe ich her und mache das selbe, wenn cih nen Akku angesteckt habe - bevor die Version da evtl. auch ein Problem haben sollte hab ich keinen Bock auf Eigenleben im Copter

Hallo Crizz,

kann beides bestätigen:

1. habe eben gerade die _DEV_20120622 geflasht --> kein Zappeln, absolut ruhiges Schweben!
(mit der Version 20120522 ging absolut nichts - bin kein Virtuose am Knüppel)

2. Verbindung zur GUI klemmt gelegentlich, Reset drücken oder COM12 (bei mir) ein paar mal schliessen / öffnen
(hier: Netbook, Win7 Starter)

Was mich noch stört, ist die fehlende Rückmeldung, dass die Parameter geschrieben werden.
Bei der Version 20120522 konnte ich am ganz kurzen Stocken der roten TX-LED sehen, dass etwas auf der Leitung passiert,
bei der Version 1.9 flackerte die D12 LED

Manfred

@Manfrad : da stimme ich dir voll zu, die optische Bestätigung durch die Pin13-LED fehlt mir da auch beim schreiben von GUI-Änderungen. Da bin ich stehts unsicher und klicke anschließend "read" als verifikation, aber schöner wäre es, wenn man durch die LED direkt wie gewohnt angezeigt bekomtm, das eine Datenübertragung stattfindet. V>ielleicht kriege die Jungs das ja wieder hin.

Was mich aber mehr ärgert ist die Tatsache mit der "fehlerhaften" GUI - insbesondere das bei jeder Version eine eigene GUI erforderlich ist und ich bei der Vielzahl der Versionen leider nur durch probieren herausfinden kann, welche GUI der FW auf dem Copter entspricht - in meinem Fall sind das aktuell nur 6 Multicopter, aber wer mehr hat und aus welchen Gründen auch immer nicht jedesmal alle updatet bekommt irgendwann ein Problem....

Da wäre es toll wenn die jeweils aktuelle GUI zumindest eine gewisse Abwärts-Kompatibilität mit sich bringen würde. Dann könnte man mit der aktuellsten auch die älteren auslesen ( es würde auch shcon etwas helfen, wenn in den Sketches ind er Config.h. direkt in der Kopfzeile die Versionsnummer stehen würde - wenn man seinen Kram dann mit vernünftigem Namen speichert sieht man dort welche programmversion verwendet wurde - selber denkt man oft nicht dran, das noch einzufügen )

Hallo Crizz
das mit der abwertzkompatiblitä kann ich befürworten.
Zu Deinen Problem mit der Grafikkarte, hast Du mal eine andere Java Version probiert?
Gruß Ingo

Ingo, ich hab auf beiden Maschinen Java aktualisiert und alle sonstigen Updates eingepflegt, ebenso verfügbare HW-Treiber für die Geräte selber. Ich konnte die 0606 nur nutzen, nachdem mir Felix eine andere GUI geschickt hatte - die leider aber auch nur auf der 0606 funktioniert. Das Problem besteht auf beiden Maschinen, und da bei de Onboard-Graphics mit 128 MB RAM haben denke ich, das der Fehler damit zusammenhängen könnte.

Die GUI die ich bekam unterscheidet sich auf jeden Fall im Bereich Portscan - denn da brauht sie länger für die Ermittlung der möglichen Ports als die zur 0606DEV gehörige GUI. Mehr kann ich zumidnest derzeit leider nicht bzgl. dieses Problems sagen.