Autopilot - Ardupilot
- Themenstarter Rangarid
- Beginndatum
Was waren denn die negativen Eigenschaften? Vielleicht hilft es uns die zu beseitigen.
@Skydiver, sollen wir morgen nachmittag mal telefonieren? Dann können wir auch mal über die Struktur reden.
Übriegns, ich habe bei DIYdrones mal nachgefragt, ob es ok ist wenn wir das alles auf deutsch machen, Code ändern usw und das ganze dann veröffentlichen, in zum Beispiel einem Wiki oder als Google Code Project. Hier ist die Antwort:
Wir werden also auf den ihrer Seite dann verlinkt. Sollte also gut werden
Hat dann natürlich noch einen positiven Effekt für die FPV-Community Seite
@Skydiver, sollen wir morgen nachmittag mal telefonieren? Dann können wir auch mal über die Struktur reden.
Übriegns, ich habe bei DIYdrones mal nachgefragt, ob es ok ist wenn wir das alles auf deutsch machen, Code ändern usw und das ganze dann veröffentlichen, in zum Beispiel einem Wiki oder als Google Code Project. Hier ist die Antwort:
Wir werden also auf den ihrer Seite dann verlinkt. Sollte also gut werden
Hat dann natürlich noch einen positiven Effekt für die FPV-Community Seite
Rangarid hat gesagt.:
Was waren denn die negativen Eigenschaften? Vielleicht hilft es uns die zu beseitigen.
@Skydiver, sollen wir morgen nachmittag mal telefonieren? Dann können wir auch mal über die Struktur reden.
Übriegns, ich habe bei DIYdrones mal nachgefragt, ob es ok ist wenn wir das alles auf deutsch machen, Code ändern usw und das ganze dann veröffentlichen, in zum Beispiel einem Wiki oder als Google Code Project. Hier ist die Antwort:
Wir werden also auf den ihrer Seite dann verlinkt. Sollte also gut werden
Hat dann natürlich noch einen positiven Effekt für die FPV-Community Seite
@Skydiver, sollen wir morgen nachmittag mal telefonieren? Dann können wir auch mal über die Struktur reden.
Übriegns, ich habe bei DIYdrones mal nachgefragt, ob es ok ist wenn wir das alles auf deutsch machen, Code ändern usw und das ganze dann veröffentlichen, in zum Beispiel einem Wiki oder als Google Code Project. Hier ist die Antwort:
Wir werden also auf den ihrer Seite dann verlinkt. Sollte also gut werden
Hat dann natürlich noch einen positiven Effekt für die FPV-Community Seite
Finde ich wirklich klasse!
Ich denke das wird dann meine nächste Investition werden.
Und wenn der Code dann auch noch in Deutsch verständlich ist.....PRIMA!
Ich freu mich drauf!
So heute erste Debugging Tests durchgeführt. Die sind echt fantastisch...
Man kann sich z.B. ausgeben lassen in welcher Position man sich gerade für den Controlhebel befindet:
Ist gut gemacht find ich. Vereinfacht die Konfiguration sehr, da man dafür das Flugzeug nicht braucht.
So habe jetzt soweit alles fertig. Mir ist etwas seltsames aufgefallen, wenn ich den ArduPilot auf Stabilize Modus umstelle, dann stabilisiert er ja das Flugzeug.
Dabei machen die Servos aber komische Geräusche und zucken ein bisschen. Nur minimal, also fast nicht störend. Wundert mich aber schon, ist das bei euch auch so?
//EDIT
Hab mal ne andere Firmware getestet, da laufen sie flüssig, dafür machen sie andere komische Sachen
Man kann sich z.B. ausgeben lassen in welcher Position man sich gerade für den Controlhebel befindet:
Code:
Begin Debug: Control Switch Test
Position 2
Position 3
Position 2
Position 1 - ManualSo habe jetzt soweit alles fertig. Mir ist etwas seltsames aufgefallen, wenn ich den ArduPilot auf Stabilize Modus umstelle, dann stabilisiert er ja das Flugzeug.
Dabei machen die Servos aber komische Geräusche und zucken ein bisschen. Nur minimal, also fast nicht störend. Wundert mich aber schon, ist das bei euch auch so?
//EDIT
Hab mal ne andere Firmware getestet, da laufen sie flüssig, dafür machen sie andere komische Sachen
Guten Abend!
@ Rainer: Also ich glaube schon, dass großes Interesse an diesem Systen besteht, jedoch sind zu wenige Leute hier im deutschsprachigen Raum im Besitz des Systems, mich eingeschlossen.
Ich denke, wir sollte erst einmal weiter machen und die Struktur planen. Dann können Arbeitspakete erstellt werden. Dort kann dann jeder Interessierte schauen, wo er etwas zu beisteuern kann.
Das Planungsthema werde ich wohl morgen eröffnen, da können wir uns dann etwas abseits unterhalten
Beste Grüße
Heiko
@ Rainer: Also ich glaube schon, dass großes Interesse an diesem Systen besteht, jedoch sind zu wenige Leute hier im deutschsprachigen Raum im Besitz des Systems, mich eingeschlossen.
Ich denke, wir sollte erst einmal weiter machen und die Struktur planen. Dann können Arbeitspakete erstellt werden. Dort kann dann jeder Interessierte schauen, wo er etwas zu beisteuern kann.
Das Planungsthema werde ich wohl morgen eröffnen, da können wir uns dann etwas abseits unterhalten
Beste Grüße
Heiko
Skydiver, du hattest gemeint IMU usw beim debuggen vorhin...ich wollte nurmal durchgucken, was man da so an Werten bekommt. Ich find z.B. die min/max Geschichte sehr nett, weil man dann die Werte gleich in den Code schreiben kann.
Hier mal meine Bestandsliste:
Ardupilot
XY und Z Sensor von FMA
Airspeedsensor von DIYdrones
GPS vom Remzibi (MediaTek) <--benutze hier aber nur GND und TX damit ich es am OSD lassen kann vorerst
Ich benutze weder Shield noch IMU, da ich meinen Piloten möglichst klein haben will. GPS signal wird beim Remzibi OSD abgegriffen. XYZ wird direkt an den Ardupilot angeschlossen, Airspeed hab ich auf nem Evaluationsboard, wird auch direkt an den Ardupilot angeschlossen (Analog3).
Dann benutze ich einen RP8D1, habe mir da eingestellt, dass er im Falle eines Signalverlustes auf Flugmodus 3 geht (wird dann RTH wenn die Stabi und FlyByWire Tests erfolgreich waren). Umsprung von Funke aus auf 3. Modus dauert ca 1s. Wenn videobild also weg ist schnell Funke aus und es sollte keine Probleme geben.
Und hier noch meine später geplante Anschaffung:
ArduStation mit Google live Tracking und AntennenTracking (hoffentlich findet sich eine Lösung mit Telemetrie über Audio). Sollte an sich keine große Sache sein, da es kleine Audiomodems gibt, die über serielle Schnittstelle angesprochen werden.
Hier mal meine Bestandsliste:
Ardupilot
XY und Z Sensor von FMA
Airspeedsensor von DIYdrones
GPS vom Remzibi (MediaTek) <--benutze hier aber nur GND und TX damit ich es am OSD lassen kann vorerst
Ich benutze weder Shield noch IMU, da ich meinen Piloten möglichst klein haben will. GPS signal wird beim Remzibi OSD abgegriffen. XYZ wird direkt an den Ardupilot angeschlossen, Airspeed hab ich auf nem Evaluationsboard, wird auch direkt an den Ardupilot angeschlossen (Analog3).
Dann benutze ich einen RP8D1, habe mir da eingestellt, dass er im Falle eines Signalverlustes auf Flugmodus 3 geht (wird dann RTH wenn die Stabi und FlyByWire Tests erfolgreich waren). Umsprung von Funke aus auf 3. Modus dauert ca 1s. Wenn videobild also weg ist schnell Funke aus und es sollte keine Probleme geben.
Und hier noch meine später geplante Anschaffung:
ArduStation mit Google live Tracking und AntennenTracking (hoffentlich findet sich eine Lösung mit Telemetrie über Audio). Sollte an sich keine große Sache sein, da es kleine Audiomodems gibt, die über serielle Schnittstelle angesprochen werden.
Wieso Telemetrie weg? Wenn du ein xbee nehmen würdest kannst du die selben Daten übertragen wie wenn du das über Audiomodem machst. Klar, du hast dann vielleicht eine geringere Baudrate, aber die Sachen für Telemtrie sind eh schon geschrieben und müssten nur ein bisschen angepasst werden.
Und wenn man das OSD auf eine kleine Platine mit extra Prozessor auslagert kann man die Daten, die man über das Modem schickt mit einem Y-Kabel gleichzeitig an das OSD Modul schicken. Man muss ja sowieso Höhe, Position usw übertragen. Die kann man dann am OSD Modul auswerten.
Dann kann man sich auch gleich aussuchen, ob man Telemetrie überträgt, oder nur das Modem anschließt. Oder man würde sich ein kleines Modul zusammenbasteln, was gleichzeitig OSD und Modem ist. Bekommt die Daten über die serielle Schnittstelle vom ArduPilot und hat einen Audioausgang und einen Videoausgang.
Wäre doch eine ziehmlich simple Lösung für wenn man beides benutzen möchte.
Ich dachte die Version, das OSD direkt aus dem ArduPilot zu holen wäre schon verworfen wurden?
Und wenn man das OSD auf eine kleine Platine mit extra Prozessor auslagert kann man die Daten, die man über das Modem schickt mit einem Y-Kabel gleichzeitig an das OSD Modul schicken. Man muss ja sowieso Höhe, Position usw übertragen. Die kann man dann am OSD Modul auswerten.
Dann kann man sich auch gleich aussuchen, ob man Telemetrie überträgt, oder nur das Modem anschließt. Oder man würde sich ein kleines Modul zusammenbasteln, was gleichzeitig OSD und Modem ist. Bekommt die Daten über die serielle Schnittstelle vom ArduPilot und hat einen Audioausgang und einen Videoausgang.
Wäre doch eine ziehmlich simple Lösung für wenn man beides benutzen möchte.
Ich dachte die Version, das OSD direkt aus dem ArduPilot zu holen wäre schon verworfen wurden?
mit den long range xbee´s gibt es noch probleme.zumindest bei den 868 mhz modulen.diese haben eine duty cycle limitierung von 10%.
nach 10 minuten ist dann funkstille.
die xbee pro 2,4 gehen mit einer kleinen 5 elem. yagi bis zu 6 km ! getestet.sie sind sehr schmalbandig.ob es mit dem videolink zusammen hinhaut, bleibt zu testen... müsste eigentlich gehen.
olli
nach 10 minuten ist dann funkstille.
die xbee pro 2,4 gehen mit einer kleinen 5 elem. yagi bis zu 6 km ! getestet.sie sind sehr schmalbandig.ob es mit dem videolink zusammen hinhaut, bleibt zu testen... müsste eigentlich gehen.
olli
Hi,
@skydiver:
Nö, Schreiner bin ich nicht. Und Schwabe auch keiner. Ich wohn' bloß da und das hat abgefärbt.
Der Grund weshalb ich das so "ausführlich" gebaut habe, war weil ich "Testflüge" auf dem Fahrrad damit machen und beobachten wollte.
Mein Chef hat den AP in seinen Easystar gebaut und beim Einschalten des AP in etwa 30m Höhe einen sofortigen Absturz erzielt. Ich hab' mich dann entschlossen pragmatischer vorzugehen.
Ich habe Nachrichtentechnik studiert und habe mehrere Jahre Software für realtime und embedded Systeme entwickelt. Jetzt bin ich "nur noch" Projektleiter.
Aktuell habe ich einen Praktikanten. Der programmiert an einem AP Mega und soll einen Quadrokopter zum fliegen bringen. -> Man darf keine losen Zettel auf dem Schreibtisch liegen lassen
Die GPS oben:
Alle werden vom AP unterstützt.
Das Mediatek enthält ein spezielles binäres Kommunikationsprotokoll, kann aber auch über NMEA angesprochen werden.
Generell kann jedes GPS Modul, welches NMEA spricht an den AP angeschlossen werden.
Welches nun besser oder schlechter geeignet ist, hängt vom Chipsatz ab.
Z.B.:
Manche Module geben die aktuelle Position ständig aus, manche nur, wenn eine Geschwindigkeit > etwa 2 km/h erreicht ist.
Letztere sind für Navi's gut, und für Quadcopter schlecht.
´Viele Grüße
Achim[/align]
@skydiver:
Nö, Schreiner bin ich nicht. Und Schwabe auch keiner. Ich wohn' bloß da und das hat abgefärbt.
Der Grund weshalb ich das so "ausführlich" gebaut habe, war weil ich "Testflüge" auf dem Fahrrad damit machen und beobachten wollte.
Mein Chef hat den AP in seinen Easystar gebaut und beim Einschalten des AP in etwa 30m Höhe einen sofortigen Absturz erzielt. Ich hab' mich dann entschlossen pragmatischer vorzugehen.
Ich habe Nachrichtentechnik studiert und habe mehrere Jahre Software für realtime und embedded Systeme entwickelt. Jetzt bin ich "nur noch" Projektleiter.
Aktuell habe ich einen Praktikanten. Der programmiert an einem AP Mega und soll einen Quadrokopter zum fliegen bringen. -> Man darf keine losen Zettel auf dem Schreibtisch liegen lassen
Die GPS oben:
Alle werden vom AP unterstützt.
Das Mediatek enthält ein spezielles binäres Kommunikationsprotokoll, kann aber auch über NMEA angesprochen werden.
Generell kann jedes GPS Modul, welches NMEA spricht an den AP angeschlossen werden.
Welches nun besser oder schlechter geeignet ist, hängt vom Chipsatz ab.
Z.B.:
Manche Module geben die aktuelle Position ständig aus, manche nur, wenn eine Geschwindigkeit > etwa 2 km/h erreicht ist.
Letztere sind für Navi's gut, und für Quadcopter schlecht.
´Viele Grüße
Achim[/align]
