Tag zusammen,

hab ne frage, wie stellt ihr es an, mit dem mikrokopter-tool zu fliegen? Die daten werden bei mir net verarbeitet.
also im tool stehen unter menü 11 zwar die werte, die ich mit den schiebebalken einstelle, kommen also offensichtlich beim MK an und wieder zurück
aber was muss ich anstellen, damit er die auch tatsächlich VERARBEITET und befolgt?

Zur Info, der Motortest geht, allerdings hab ich keine fernsteuerung dran, dass soll alles ausschließlich seriell erfolgen und das wollte ich mit dem tool vorher testen.

muss ich vorher also irgendwelche sicherheitssperren umgehen, damit das auch ohne fernsteuerung seriell die steurungsdaten vom mikrokopter-tool frisst?

Noch ne Festellung am Rande: wenn der haken bei motortest DRIN ist, dann pullert der MK NICHT mehr die Seriellen daten für Gas, Gier usw. zurück an das Mikrokopter-Tool, wenn ich die Balken bei dem Reiter "Control" bewege.

Kann ich die Parametrierung vorher per Software in der main() anstoßen? sonst macht er die ja nie...

Danke schonmal!

Gruß

Nico

fliegen mit dem mk-tool geht nicht.
der motortest ist nur dafür da um die funktion der regler und motoren zu testen.

afaik gehts schon, aber man braucht dafuer ne funksteuerung die einen bestimmten userparameter setzt und quasi nen lehrer-schueler-betrieb mit dem MK-tool macht

@nicomputer naja du muesstest halt die Software von der flightctrl patchen..

Hallo,
es würde mich interessieren, ob denn schon jemand versucht hat (mit anderer Software als dem MK-Tool) nur über eine serielle Verbindung zu fliegen. Ginge das überhaupt von der Geschwindigkeit und der Verzögerung durch ein Bluetooth-Modul?

guckstu hier: http://mikrokopter.de/ucwiki/en/Riddim?action=show&redirect=Riddim

@Absurd-Mind
habe geguckt - vielen Dank. Ich nehme an, dass eine herkömmliche Fernbedienung Steuerbewegungen schneller überträgt als eine serielle Verbindung - stimmt denn das? Würdest du denn sagen, dass beide Steuerungsarten von der Verzögerung her gleichwertig sind?

wenns über den PC geht ist es natürlich immer langsammer.

folgende Dinge bremsen:
USB schickt nur alle 10ms daten
windows ist nicht echtzeitfähig

sobald die Daten aus dem Rechner ruasgeen bremst eigenltich nichts mehr. Das BT-Modul muss natürlich auch korrekt konfiguriert sein. Man kann dort einstellen ob nach jedem Byte gesendet werden soll oder wielange er seinen sendepuffer füllen soll bevors geschickt wird. Aber die Standard Einstellung funzt auch.

Zum Vergleich: Normale Fernsteuerungen senden alle 20ms ein Packet.

rasc1234 meinte

Ginge das überhaupt von der Geschwindigkeit und der Verzögerung durch ein Bluetooth-Modul?

Nunja, die Latenz ist über PC sicherlich etwas höher, aber fliegen kann man damit trotzdem, so siehtz zumindest in den Riddim-Videos aus.

Ich habe allerdings net von einem Bluetooth-Modul gesprochen, ich hänge direkt mit dem UMTS-Modem (80-100ms Ping) am Seriellen-Port der FlightControl. Mein Ziel ist auch garnet komplexe Manöver zu fliegen, ziel ist fast ausschließlich GPS-Hold und dann Videostream übertragen, solange Akku hält! Wenn Akku dann aber leer ist, würde ich gerne etwas in das Landemanöver eingreifen, also Gas/Gier Roll/Nick über das Mikrokopter-Tool senden...

Hierzu nun eine erweiterte Frage, habe schon angefangen den FC-Quellcode zu überarbeiten, hab ihn schon davon Überzeugt, dass der Empfang super ist und die Akkus immer voll sind, führe gerade alle Inits per software nacheinander durch, also ihr machts in der Reihenfolge wie hier beschrieben, richtig?:

1.ACC kalibrieren = PPM_in[EE_Parameter.Kanalbelegung[K_GIER]] > 75 && PPM_in[EE_Parameter.Kanalbelegung[K_GAS]] > 80

---> Also obere rechte Ecke

2.Gyros kalibrieren = && PPM_in[EE_Parameter.Kanalbelegung[K_GIER]] < -75 && PPM_in[EE_Parameter.Kanalbelegung[K_GAS]] > 80

---> Also obere linke Ecke


danach sollte ich mit gas>140 schub geben können und der MC sollte fliegen, oder??
Geht das dann über das Mikrokopter Tool?

Danke schonmal!!


Gruß

Nico

Mal vom gesetzlichen Rahmen abgesehen würde ich sagen mutig ;-)

Technisch ist das realisierbar. Auf jeden Fall must du die Software auf der FC erweitern.
Den das was bereits eingebaut ist, funktioniert nur in der Kombination mit einer normalen RC-Fernsteuerung.

Siehe hier:

 StickNick += (int) ExternControl.Nick * (int) EE_Parameter.Stick_P;
 StickRoll += (int) ExternControl.Roll * (int) EE_Parameter.Stick_P;
 StickGier += ExternControl.Gier;

ExternControl.xxxx wird über das kopter tool gesetzt


Also wenn du Empfang und die Startsequenz in den Code programmiert hast und das ding beim einschalten sofort die motoren startet und loslegt. Dann könntest du über das koptertool fliegen.

Ich persönlich würde aber zu meiner eigenen Sicherheit und Sicherheit von unbeteiligten Personen aufjedenfall eine normale Fernsteuerung dranhängen. Dann kannst du von Hand starten und Landen und den Rest dann per Laptop/Handy usw. machen.

Hast du eigentlich schon Erfahrung wie man den Mikrokopter steuert? Oder wilst du gleich mit Laptop und UMTS anfangen?


Falls du noch fragen hast nur her mit. klingt nämlich ganz intresannt

Mfg

nicomputer meinte

Ich habe allerdings net von einem Bluetooth-Modul gesprochen, ich hänge direkt mit dem UMTS-Modem (80-100ms Ping) am Seriellen-Port der FlightControl. Mein Ziel ist auch garnet komplexe Manöver zu fliegen, ziel ist fast ausschließlich GPS-Hold und dann Videostream übertragen, solange Akku hält!

Das klingt sehr interessant - ich hätte ein paar Fragen:

Was für ein UMTS-Modem hängst du denn an die Flight-Ctrl, was für eins an den PC? Liegt die Frequenz von UMTS auch im überlichen 2.4GHz-Bereich von Funkkameras?

rasc1234 meinte

Was für ein UMTS-Modem hängst du denn an die Flight-Ctrl, was für eins an den PC? Liegt die Frequenz von UMTS auch im überlichen 2.4GHz-Bereich von Funkkameras?

Also UMTS hat folgende Eckdaten:

Frequenzbereich: 1,9 - 2,17 GHz in je 5 MHz Kanälen

Vorläufer:
GPRS - bis zu 55,6 kBit/s
EDGE - bis zu 200 kBit/s

UMTS ohne Erweiterung „3G“– bis zu 384 kBit/s

HSDownlinkPA – bis zu 7,2 MBit/s, schneller als ADSL 6000-Down
HSUplinkPA – bis zu 5 MBit/s, vergl. ADSL2+ 16000 (hat 5 MBit/s-Upstream)

HSUPA ist laut Vodafone bei mir in Bocholt ca. Jahresende verfügbar. Dann geht auch der Kamerastream durch die Leitung.

geschafft 0.2:

Habs jetzt soweit, dass ich über seriell die Motoren initialisiere und auch ein/ausschalte (Hab einfach ne Abfrage gemacht, sodass der GAS-Schiebebalken gleichzeitig Ein/Ausschalter ist) und das tut auch soweit:

1) Schalte Quadcopter ein: Automatische Init, Kalibrierung ACC und Rest. TUT!

2.1)
Übertragung zum MC-Tool beginnt: sobald ich jedoch GAS-Schiebebalken bewege, werden keine Sensordaten mehr übertragen. Das kann ich auch verstehen, der 644P ist net so flott alles seriell einzupacken und gleichzeitig ne PID-Regelung zu berechnen, aber wenigstens ein Feedback der aktuellen GAS/Gier bzw. Nick/Roll Werte und der GPS-Koordinaten wäre wünschenswert. Frage an Entwickler MC-Tool: MACHBAR?

2.2)
Insgesamt würde mich der Quellcode zum Mikrokopter-Tool interessieren, weil ich auch ein Kamerabild einbinden und folgendes aktuallisieren würde:

Sobald ich die Datenübertragung über UMTS (virtueller COM-Port) beginne, schmiert das MC-Tool nach ca. 10 Sekunden Datenübertragung ab. Auch werden nicht die korrekten Sensornamen angezeigt (wie bei direkter serieller Übertragung), sondern nur Analog 1, Analog 2, Analog 3 usw... Mögliche Ursache meiner Meinung nach ist:

Die Baudrate wird vom MC-Tool auf 57600 gestellt:

Profile: RealPort
Baud Rate: 57600 bps
Data Bits: 8
Parity: None
Stop Bits: 1
Flow Control: None

ich habe andere Geräte mit geringerer Baudrate erfolgreich über UMTS steuern können. Kann ich die irgendwo im MC-Tool einstellen?

3)
Gaswert > Schwellwert: alle motoren drehen an, Quadcopter hebt aber nicht ab?
Hier die zweite Frage:
Hält der QC eine bestimmte Regelreserve ein und merkt, dass er die bei meinem Gewicht net hat? Beim Motortest hebt der Quad bei etwa 70% Schub ab -> sind 30% genug Regelreserve?
Oder muss ich das Eingabefeld für Höhe auch mit Werten füttern? Spielt der Wert ne Rolle? Hab noch net ausführlich in den Regelungstechnischen Teil des Quellcodes geschaut.

Für alle Tips schonmal danke, auch im Voraus!

Greedz

Nico

Hallo BlackKing,

die rechtliche Lage ist berücksichtigt: Hierarchisch liegt ein I2C zu 433MHz Wandler am Quadcopter und ein 433MHz zu USB Wandler über der Flight-Control Platine und schaltet diese ab und übernimmt den Notlande Modus auf dem I2C Bus -> NOTAUS. Das habe ich als erstes implementiert und auch nur aus fertigen Bausätzen realisiert. Tut also 99%ig! Für Sicherheit ist also gesorgt.

Ich will den Quadcopter eigentlich nur insofern "fliegen", als dass ich nur GPS-Hold nutzen möchte. Die Steuerung über Mikrokopter-Tool ist sozusagen nur ein niceTOhave, bis ich differential GPS mit SIRF3-Chipsatz (Genauigkeit bis zu 1cm) ordentlich zum laufen bekomme.

Aber lieb, dass Du dir Sorgen um mein und Dein Blumenbeet machst ;-)

so far

Nico

Hi Nico,
wie machst du das differential GPS?
Es werden ja allgemein Daten gesendet, aber die sind z.B. in der der CH verschlüsselt und kostenpflichtig.

Gruss Martin

Hoi Martin,

martinchzh meinte

Hi Nico,
wie machst du das differential GPS?
Es werden ja allgemein Daten gesendet, aber die sind z.B. in der der CH verschlüsselt und kostenpflichtig.

Na, wenn er eine serielle Steuerung hat, kann er da auch noch ein paar GPS Daten rueberschicken und theoretisch so das DGPS selber bauen...
... ne Herausforderung, zugegebenermassen. Aber machbar sollte das sein... selbst ueber UMTS und die lange Latency.

Gruss
- Amir

Absurd-Mind meinte

guckstu hier: http://mikrokopter.de/ucwiki/en/Riddim?action=show&redirect=Riddim

Der fliegt nich mit dem "Mikrokopter-Tool" sondern benutzt lediglich das gleiche Protokoll.

Hi Amir,
ja klar, aber die Eigenbauvariante des DGPS hat wohl den Nachteil dass der Referenzempfänger sehr gut positioniert sein muss.
Aber dass man so eine Genauigkeit bis zu 1cm erreichen soll...?

Man könnte ja auch 3 GPS Empfänger in den MK einbauen und dann mitteln

Gruss Martin

tycho-x meinte

Absurd-Mind meinte

guckstu hier: http://mikrokopter.de/ucwiki/en/Riddim?action=show&redirect=Riddim

Der fliegt nich mit dem "Mikrokopter-Tool" sondern benutzt lediglich das gleiche Protokoll.

hat auch den Vorteil das parallel zum fliegen nicht mehr die ganzen sensorwerte angefordert werden. Dann sinkt auch die Auslastung auf dem AVR

der vorteil des DGPS ist ja eben,
das der referenzempfänger feststehend ist und die koordinaten bekannt sind,
und die differenz zum signal berechnet werden kann.

die abweichung wird gösser wenn das ziel in bewegung ist.


.

JUERGEN_ meinte

der vorteil des DGPS ist ja eben,
das der referenzempfänger feststehend ist und die koordinaten bekannt sind,
und die differenz zum signal berechnet werden kann.

die abweichung wird gösser wenn das ziel in bewegung ist.

Hi zusammen,

genauso mach ich das! Ich stelle an den Startpunkt direkt unter den Quad nen zweiten GPS-Empfänger und mache den Rest dann per Software auf dem Steurungs-PC, gerade AUFGRUND der zurückgesendeten Daten vom MC-Tool.

Gegen mein größtes Sorgenkind, im Mikrokopter-Tool die Baudrate runterzusetzen, damits nemmer abschmiert hat keiner nen Vorschlag?

Danke schonmal!

Greedz

Nico

@nicomputer:
Ich hab gerde mal versucht deine Gedanken nachzuvollziehen:

Bei DGPS ist ein Funkstation, deren Koordinaten exakt bekannt sind, mit einem GPS Empfänger ausgestattet. Dieser bestimmt jetzt die GPS-Koordinaten. Jetzt wird die Abweichung zwischen exakten und gemessenen Koordinaten ermittelt.

Da man annehmen kann, das die Abweichung im Umkreis von einigen Kilometern zu exakt diesem Zeitpunkt alle GPS Empfänger annähernd gleich betrifft, werden diese Offset-Werte per Funk an den GPS Empfänger im mobilen DGPS Wert geschickt. Umso höher die Frequenz der empfangenen Offset-Werte, umso besser ist die Genauigkeit

Dieser bestimmt jetzt wieder über einen normalen GPS Empfänger seine Position, rechnet dann den empfangen Offset drauf und kann so seine Position auf wenige Zentimeter genau berechnen.

Mit einem 2.GPS Gerät, dessen Position du nicht kennst, kannst du also keine exakte Positionsbestimmung vornehmen - das willst du ja auch nicht.

Die Schwankungen in dem GPS Signal kannst du allerdings ausfiltern, indem du ersteinmal den Mittelwert der GPS Position um ca. über 5 Minuten ermittelst. Ab dann wird der Offset-Wert zu diesem Mittelwert errechnet und als Offset Wert an den Mikrokopter übermittelt.

Das könnte sogar funtionieren... oder hast du dirs anders vorgestellt?

Fry3199 meinte

@nicomputer:
Ich hab gerde mal versucht deine Gedanken nachzuvollziehen:

Bei DGPS ist ein Funkstation, deren Koordinaten exakt bekannt sind, mit einem GPS Empfänger ausgestattet. Dieser bestimmt jetzt die GPS-Koordinaten. Jetzt wird die Abweichung zwischen exakten und gemessenen Koordinaten ermittelt.

Da man annehmen kann, das die Abweichung im Umkreis von einigen Kilometern zu exakt diesem Zeitpunkt alle GPS Empfänger annähernd gleich betrifft, werden diese Offset-Werte per Funk an den GPS Empfänger im mobilen DGPS Wert geschickt. Umso höher die Frequenz der empfangenen Offset-Werte, umso besser ist die Genauigkeit

Dieser bestimmt jetzt wieder über einen normalen GPS Empfänger seine Position, rechnet dann den empfangen Offset drauf und kann so seine Position auf wenige Zentimeter genau berechnen.

Mit einem 2.GPS Gerät, dessen Position du nicht kennst, kannst du also keine exakte Positionsbestimmung vornehmen - das willst du ja auch nicht.

Die Schwankungen in dem GPS Signal kannst du allerdings ausfiltern, indem du ersteinmal den Mittelwert der GPS Position um ca. über 5 Minuten ermittelst. Ab dann wird der Offset-Wert zu diesem Mittelwert errechnet und als Offset Wert an den Mikrokopter übermittelt.

Das könnte sogar funtionieren... oder hast du dirs anders vorgestellt?

Ist es denn notwendig, die Position des stationären GPS am Startpunkt genau zu kennen? Um an einer Stelle zu schweben sollte es doch genügen einfach eine Aussage der Art "5m links, 5 m vorne, 5 m höher".

Ein Problem könnte vielleicht sein, wenn die beiden GPS-Empfänger Signale unterschiedlicher Satelliten auswerten.

Ein zweites Problem erscheint mir, dass GPS-Empfänger meines Wissens nach nur mit eher geringer Frequenz ihre Daten melden (ich denke so 5 x pro Sekunde?)

jedenfalls muss irgendeine Position festgelegt werden, sonst kann ja kein Offset-Wert errechnet werden, oder? Ich hab den Mittelwert vorgeschlagen. Sollte aber auch mit jedem Fix-bestimmten Wert gehen. Allerdings kann man dann natürlich nicht mehr Koordinaten von Google Earth anfliegen, das muss dann auch klar sein

nicomputer meinte

geschafft 0.2:

Habs jetzt soweit, dass ich über seriell die Motoren initialisiere und auch ein/ausschalte (Hab einfach ne Abfrage gemacht, sodass der GAS-Schiebebalken gleichzeitig Ein/Ausschalter ist) und das tut auch soweit:

1) Schalte Quadcopter ein: Automatische Init, Kalibrierung ACC und Rest. TUT!

ich hoff du hast dazwischen nen delay gemacht - direkt beim einschalten wackelts ja meist

nicomputer meinte

2.1)
Übertragung zum MC-Tool beginnt: sobald ich jedoch GAS-Schiebebalken bewege, werden keine Sensordaten mehr übertragen. Das kann ich auch verstehen, der 644P ist net so flott alles seriell einzupacken und gleichzeitig ne PID-Regelung zu berechnen, aber wenigstens ein Feedback der aktuellen GAS/Gier bzw. Nick/Roll Werte und der GPS-Koordinaten wäre wünschenswert.

eigentlich kommen auch im Flug Debug Daten. Was meinst du genau mit gas-schieberegler/balken?

ligi meinte

eigentlich kommen auch im Flug Debug Daten. Was meinst du genau mit gas-schieberegler/balken?

Servus Ligi!! Bei mir kommen da leider keine... aber ich bin dabei im Quellcode rauszufinden, warum...

Der Gas-Schieberegler ist im Mikrokopter Tool der Regler ganz rechts im Reiter "Control", der oberste Wert in den Nummernfeldern ist übrigens die Höhe, die größer dem aktuellen Höhenwert sein muss, damit überhaupt was passiert...

Fry3199 meinte

Bei DGPS ist ein Funkstation, deren Koordinaten exakt bekannt sind, mit einem GPS Empfänger ausgestattet. Dieser bestimmt jetzt die GPS-Koordinaten. Jetzt wird die Abweichung zwischen exakten und gemessenen Koordinaten ermittelt.
untionieren... oder hast du dirs anders vorgestellt?

Genauso läuft das, du suchst dir nen schönen eindeutigen Startpunkt aus, legst nen GPS-Empfänger hin und holst dir die exakten Koordinaten des Empfängers aus Google-Earth. Nun kannste davon ausgehen, dass der Offset dieses Empfängers ne Weile Lang etwa derselbe ist, wie der, den man beim Sirf3-Chip im Quadcopter sieht...

Ist auch bei mir bisher theoretisch, sollte aber gehen, denke ich!

Muss immernoch die Baudrate vom Mikrokopter-Tool unter 57600 setzen... jemand ne Idee?

Greedz

Nico

nicomputer meinte

Nun kannste davon ausgehen, dass der Offset dieses Empfängers ne Weile Lang etwa derselbe ist, wie der, den man beim Sirf3-Chip im Quadcopter sieht...

Wie meinst du das, ne Weile lang? Der Offset ist zwar zu einem beliebigen Zeitpunkt gleich, wird aber von Sekunde zu Sekunde sich verändern.

Dadurch ist es ja auch so wichtig, den Offset so häufig wie möglich an den Mikrokopter zu übertragen - am besten natürlich in der gleichen Frequenz wie das GPS Signal reinkommt.