Hi,

ich habe gestern mein neues Board bekommen ( Multiwii and Megapirate AIO Flight Controller w/FTDI (ATmega 2560) V2.0 - http://hobbyking.com/hobbyking/store/uh ... duct=46540 ) und angeschlossen. Multiwii 2.3 klappt auch soweit. GPS fubktioniert, Blutooth Modul funktioniert, OELD Display funktioniert (macht nur nicht das was ich will )

Im GUI geht alles so, wie es sein soll. AUSSER: Wenn ich die Motoren "scharf" schalten will, gehen die auf "ARM" in der GUI und fangen auch nicht an sich zu drehen. In der GUI werden aber die Werte für die Motoren angezeigt, je nachdem wie ich die Knüppel bewege. Ich habe den selben Sketch genommen, wie vorher auf meinem Paris V4 Board mit dem AT328 Pro Mini (ausser dem Display Teil, der war ja für den 328 zu groß) - Das Board habe ich natürlich im Sketch angepasst auf das #define CRIUS_AIO_PRO_V1

Was muß ich machen, damit ich beim scharf schalten der Motoren über die Knüppel an der Funke nicht "ARM" aktiviere?

[Edit]: wenn ich das Blutooth Modul abziehe, lassen sich die Motoren scharf schalten und drehen, lassen sich aber nur schwer abschalten. Wenn der Knüppel unten in die Ecke geht, geht manchmal die Drehzahl rauf, anstatt die Motoren aus gehen. Muss den Knüpel erst in die "an" Position und dann langsam in d.ie "aus" Position Will aber Blutooth auch im Flug haben. Die Knüppel sind alle perfekt kallibriert

Dann habe ich versucht, die NAV Version von EOSBandi auszuprobieren. Die unterstützt aber nicht mein I2C Board zwischen Board und GPS Empfänger. Da geht das nur seriell. Also Kabel beastelt und GPS direkt am Board/seriellen Anschluß angeschlossen. Geht nicht. Da mein FTDI Adapter ja kaputt ist (der Grund für die ganze Wechsel und "mach neu Aktion"), kann ich den GPS Empfänger auch nicht umkonfigurieren, dass er direkt am Board läuft.

Auch scheint er in der GUI den Copter nicht zu erkennen. Er zeigt zumindest keine Werte an. Klappt also auch nicht.

Dann habe ich MegaPirateNG ausprobiert. Alles nach den Anleitungen auf der HK Seite zu meinem Board eingestellt und geflasht. Geht auch irgendwie nicht. Kein Connect mit der GUI.

ICH WILL DOCH NUR WEGPUNKTE ABFLIEGEN UND RTH

Weitere Fragen:

- am Paris Board war ein Anschluß für die Masse der LED Stripes, die die LED Signale (scharf schalten, programmieren usw) auf die LED Stripes an den Auslegern gegeben hat. Hat das neue Board das auch? Oder wie mache ich das? Wenn ich die Masse auf Masse von z.B. ESC lege, leuchten die ja dauerhaft. Auch wäre "Low Bat" usw. schön über die LED Bänder zu sehen.
- muss man das BARO wieder mit Schaumstoff abdecken?
- Headfree heißt, dass Copter mit egal welcher Seite von einem weg zeigt, er immer steuert, als wäre "Vorne" auch von einem weg und "Heck" zeigt zu einem hin?
-Headadj heißt, Copter bleibt immer mit "Vorne" von einem weg?

Wäre schön, wenn einer Licht ins Dunkle bringen kann.

Viele Grüße

Udo

P.S. Wenn einer seine PID Werte bei diesem Board und einem 450er Quad posten könnte, wäre ich sehr zu Dank verpflichtet.

Hi,

hier mal ein Update:

Der Copter ist immer noch nicht geflogen, aber ich komme der Sache näher: Sowohl mit der MultiWii 2.3, als auch mit der "MultiWi2_3-navi-b5-baro_fix" kann ich das GPS Teil an den Serial 3 Ausgang anschliessen (ohne das I2C Breakoutboard), wenn ich an dem Crius Board eine externe Stromversorgung anschließe und den Jumper für die Stromversorgung per BEC entferne. Wie ich gelesen habe, ist kein Strom am Serial Port, wenn die Stromversorgung über die BEC realisiert wird. Zum testen habe ich erstmal 4 x 1,5 V Akkus genommen. Als ich 11,...V vom Balancer Anschluß genommen habe, hat es heftig am GPS Teil gequalmt. Das GPS Teil hat das aber augenscheinlich überlebt

Wenn ich den GPS am Serial 0 /FTDI Anschluß anschließe, lassen sich die Motoren wieder nicht disarmen. Überlege jetzt, den Strom vom I2C Anschluß per Y-Kabel abzugreifen, damit ich die externe Versorgung nicht brauche. Mit der Batterie zum testen initiallisieren die Regler nämlich nicht . Oder ich nehme ein Simprop 3A BEC ( http://www.derkum-modellbau.com/index.p ... ec_3a.html )

Das OLED läuft unter MultiWii, wenn auch die Steuerung per Stick nicht so ist, wie man per Anleitung findet (fliege Mode 2 mit invertiertem YAW). Mit dem "MultiWi2_3-navi-b5-baro_fix" hab ich jetzt noch nicht darauf geachtet, ob es geht.

Jetzt muß ich nur noch hinbekommen, dass die Regler disarmen, wenn das Blutooth dran ist und dass das disarmen per Knüppel zuverlässig geht. Wenn das alles geht, kann ich Ding zum einfliegen mitnehmen und mich an die einzelnen PID Werte rantasten. Am liebsten auf der Wiese per Blutooth und Android Handy.

Ich werde berichten.

MegapirateNG geht per Flash Tool, aber die Knüppelkommandos werden falsch umgesetzt. Braucht man aber nicht, wenn "MultiWi2_3-navi-b5-baro_fix" geht.

Viele Grüße

Udo

Ich kenn das Board nicht, kann daher nicht wirklich helfen. Was du aber unbedingt beachten solltest : bevor du Komponenten anschließt, check mal welche Betriebsspannung die haben und was an den entsprechenden Ports für eine Versorgungsspannung ausgegeben wird. Wenn du ein Modul das mit 3,3 V arbeitet an 5 V betreibst kann das schon für Qualmerei sorgen. Und oft heißt Qualm auch das irgendwas in den Silizium-Himmel abgewandert ist. Das wird sich letztlich nur beurteilen können wenn das Ding mal flugtauglich wird. Ich würde zur Sicherheit eine niedrigere MWC-Version mal installieren die das Board unterstützt und nicht gleich auf die neueste gehen, sofern mehrere SW-Varianten das Board unterstützen. Damit lassen sich zumindest die Möglichkeiten von SW-Bugs eingrenzen.

Was muß ich machen, damit ich beim scharf schalten der Motoren über die Knüppel an der Funke nicht "ARM" aktiviere?

Den Satz versteh ich nicht. "Arm" heißt "scharf". Wenn du meinst das du keinen Schalter sondern Stickmoves verwenden willst, dafür gibt es einen Parameter in der Config.h - eigentlich braucht man den nicht extra setzen, ist Standard das MWC über Stickmoves die Motoren armed / disarmed. Definiert man einen Schalter in der GUI wird die Stick-Funktion zum arming automatisch deaktiviert.

Hi Crizz,

danke für die Info. Ich denke, dass das Board die Spannung einer externen Quelle 1:1 an den Serial Port durchgibt und nicht auf 5V runter regelt. Das Board kann wohl 5V-12V. Die Serial Komponenten aber wohl nicht . Das GPS Modul geht aber noch trotz Rauchzeichen. Im GUI gibt es alle Daten korrekt wieder.

Das mit dem "ARM" hab ich vielleicht etwas unklar beschrieben:

Ist ein Akku dran und das USB Kabel, kann ich per "Stick down and left" die Motoren starten (habe bei mir YAW in der Funke invertiert, daher nicht "right"). Habe ich irgendetwas an Serial0/FTDI angeschlossen, geht bei "Stick down and left" im GUI die grüne "ARM" Markierung in der GUI an und die Motoren drehen sich nicht. Im GUI sieht man aber rechts die Regelung, dass die Motorsteuerung die Befehle "ausführt".

Das Board erkennt also, dass etwas da angeschlossen ist und verhindert das Disarmen per Knüppel. Auch initialisieren die Regler nicht, wenn was angeschlossen ist.

Ich kauf mir gleich mal das externe BEC und versuche es dann mal. Wie ich gelernt habe, werden die serial Ports auf dem Board nicht über das ESC BEC versorgt.

Viele Grüße

Udo

Dann hast du da noch irgendwo nen Bockschuss drauf, nämlich das die FC vom USB-Port mit Saft versorgt wird - das würde ich auf jeden Fall ändern. Gibts garantiert nen Jumper für, entweder Solderjumper oder Socketjumper ( also Löt- oder Steckbrücke). Denn wenn deine FC bereits versorgt wird und danach ein Akku angesteckt wird ist die Init-Phase der Regler bereits durch, da kann nix mehr initialisieren. Oder du machst es andersrum : erst den Akku dran, dann den USB. Trotzdem würde ich schaun das ich die Versorgung über USB für diese Variante getrennt bekomme.

Hi nochmal,

das geht auch nicht, wenn ich ohne USB nur das Blutooth Modul angeschlossen habe. Sowie irgendetwas am Serial0/FTDI hängt,

Grüße

Udo

Hi,

ich habe es hin bekommen: einfach an serial2 angeschlossen und alles ist gut. VCC und GND kommen weiter vom serial0/FTDI Port , TX und RX gehen an serial2.

Nun kann ich die Motoren disarmen bei angeschlossenem Blutooth.

Viele Grüße

Udo

Hallo Udo,

ich habe grade quasi das Gleiche Problem mit meinem "Multiwii and Megapirate AIO Flight Controller". Muss aber zugeben, dass ich nach dem Zusammenbau der Hardware mich noch nicht sehr intensiv mit Software und der Verkabelung des FC beschäftigt habe (GPS und Bluetooth sind noch nicht angeschafft, sollen aber später folgen). Außerdem ist das bisher auch mein erstes RC Projekt und ich habe wohl noch viel zu lernen Daher bin ich froh wenn Beiträge wie den deinigen finde...

Ein erster, simpler Test mit Steuerung über einen Poti hat aber zumindest bestätigt das die Motoren, Regler und Baterien richtig Verkabelt sind... Danach habe ich den FC per USB an den PC angeschlossen und geschaut das die Signale der Funke (Turnigy 9x) ankommen. Auch das funktionierte nach etwas Zeit im Menü der Funke...

Könntest du mir vllt mal ein Bild deiner Verkabelung an der Platine zukommen lassen? Dann kann ich das nochmal mit meinem Anschluss überprüfen...

Vielen Dank
Stephan

Ps: Der Beitrag ist ja schon etwas älter... hast du inzwischen Erfahrungen mit deinem GPS gemacht? Und könntest du mir noch verraten welches GPS und Bluetooth Modul du verwendest?

Redzone hat geschrieben:Nun kann ich die Motoren disarmen bei angeschlossenem Blutooth.

aber sicherlich keine Werte ändern, wenn doch dann wäre das aber höchst interessant weil Serial 2 ja eigentlich der Telemtrie oder GPS Port ist

Wenn du den Bluetoothdongle an Serial 0 hängst und USB einsteckst haste "doppelgemoppelt" da der FTDI auf der FlightControl ja mit Serial 0 "hartverdrahtet" ist. Und das BT Modul nix anderes als ein Weiterer serieller Anschluß auf demselben Port. Das kann nicht gutgehen ...

korrekt, es sollte nur FTDI oder BT angeschlossen sein wenn man Daten ändern will, sonst gibt das ne ganz böse Falle. Ist beim VStabi auch so. Es darf nur eine Serielle Schnittstelle für bidirektionale Kommunikation aktiv sein.

Seriell und bidirektional scheidet per Definition aus


Sent from Teufelsapparätle

Seit wann ? Dann dürfte via USB nur lesen oder nur schreiben möglich sein. Ebenso FTDI, dafür haste ja TxD und RxD. Alles serielle Kom.-Systeme. Bidirektional heißt ja nicht das gleichzeitig beide Geräte senden und empfangen sondern gibt nur an das beide Funktionen auf dem Bus stattfinden. Eine reine unidirektionale serielle Übertragung haste z.b. bei vielen I2C oder OneWire Anwendungen wenn Sensoren ausgelesen werden.

Öhm hast natürlich Recht man sollte so spät nix schreiben


Sent from Teufelsapparätle

Ach, macht doch nix, Micha - ich hab ja selber auch schon einige Böcke geschossen . Das macht uns eben aus