objektorientierung, uml und solche späße
-
- Beiträge: 40
- Registriert: 06.05.2012 11:25:41
#1 objektorientierung, uml und solche späße
ich weiß nicht, ob forum und topic richtig sind, trotzdem mal hier probiert :
ich möchte einen übersichtlichen (!!!) 4copter selberprogrammieren, von der achsregelung bis zum gps-waypoint. hardware (teuer, aber fertig) von mikrokopter.
schritt a :
in luna (c stinkt !),vor allem weil das objektorientierung bietet ( http://avr.myluna.de/doku.php?id=de:about ), hab ich mal rumgebastelt. achsregler, höhenregler mit baro, gier mit kompass, rc mit ppm. klappt soweit, fliegt wie ein gutmütiger heli (fast wie koax). man kann da viel lernen (regelungstechnik, sensorik, flugmechanik... mechatronik at its best !).
schritt b :
um das jetzt dem stand der technik anzupassen, sollte es auch modern entwickelt werden. also eine uml-modellierung und dann umsetzung in klassendiagrammen und so weiter. in luna sollte das möglich sein, bei c++ auf avr wirds schon enger. bervor ich alles nochmal von vorne anfange - und außerdem bin ich da selber relativ neu - frage ich mal, obs solche ansätze schon gibt. kann man ein uml-konstrukt für nen flugfähigen copter irgendwo bewundern ? (ich find nix...)
..blöde idee oder interessiert das jemanden ?
ich möchte einen übersichtlichen (!!!) 4copter selberprogrammieren, von der achsregelung bis zum gps-waypoint. hardware (teuer, aber fertig) von mikrokopter.
schritt a :
in luna (c stinkt !),vor allem weil das objektorientierung bietet ( http://avr.myluna.de/doku.php?id=de:about ), hab ich mal rumgebastelt. achsregler, höhenregler mit baro, gier mit kompass, rc mit ppm. klappt soweit, fliegt wie ein gutmütiger heli (fast wie koax). man kann da viel lernen (regelungstechnik, sensorik, flugmechanik... mechatronik at its best !).
schritt b :
um das jetzt dem stand der technik anzupassen, sollte es auch modern entwickelt werden. also eine uml-modellierung und dann umsetzung in klassendiagrammen und so weiter. in luna sollte das möglich sein, bei c++ auf avr wirds schon enger. bervor ich alles nochmal von vorne anfange - und außerdem bin ich da selber relativ neu - frage ich mal, obs solche ansätze schon gibt. kann man ein uml-konstrukt für nen flugfähigen copter irgendwo bewundern ? (ich find nix...)
..blöde idee oder interessiert das jemanden ?
#2 Re: objektorientierung, uml und solche späße
ganz klares neindollreiner hat geschrieben:..blöde idee oder interessiert das jemanden ?

Im Augenblick habe ich noch keinen Copter, somit bin ich auch noch nicht in Verlegenheit gekommen, an dem vorhanden Code zu schrauben. ABER da möchte ich noch hin.
Luna kannte ich bisher noch nicht, hört sich im ersten Anlauf super an, weil ich sehr viel mit VBA Programmiere. Früher habe ich sehr viel mit Turbo Pascal geschrieben, somit springt Luna mich gerazu an.

Allerdings "befürchte" ich, das es hier nur Wenige gibt, die da mitmachen würden.
Bei mir fehlt (noch) sämmtliches Wissen um einen micro-Controller zu programmieren.
Viele Grüße
Mirko




-
- Beiträge: 40
- Registriert: 06.05.2012 11:25:41
#3 Re: objektorientierung, uml und solche späße
wenn du gar nix über copter-programmierung weist, könnte es schwierig werden. basis für ne modellierung ist vermutlich ein guter überblick über die teilfunktionen, die dann ja als klassen möglichst universell einsetzbar "wasserdicht" realisiert werden müssen.
wenn es dir nicht auf die zeit ankommt, könntest du das zeitparallel zu projekten an meiner schule mitmachen. einen eindruck kannst du hier gewinnen :
http://portal.ts-muenchen.de/index.php? ... &catid=125
wenn du auf "projekte 2013/14" gehst, siehst du wie es weitergehen könnte. aber : das dauert rund ein jahr. dazu fehlt mir die geduld.
kurzfristiger würde ich versuchen (so als testphase quasi), selbst erstmal ein uml-klassendiagramm für die zentralen flugfunktionen hinzukriegen. da wären wohl der digitale pid-regler, die digitalen filter, die motoransteuerung und sowas zu nennen. ich denke, so ein großes faß ist das gar nicht ...
hardware ist die fc 2.1 von mikrokopter.de, ich mach das zunächst ja nicht privat sondern eben im schulumfeld, und da ist ne fertige, ausgetestete hardwarebasis ohne bastelei wichtiger als der günstigste preis. (klar wäre wii spannender und ein 16 o. 32-bittler einfacher bezüglich der auslastung.)
wesentlichste grundbedingung : es wird nicht gebastelt. der konsistente zusammenhang zwischen allen physikalisch/technischen grundlagen (nicht die fertige e-technik, also motor oder prozessorfunktion und so, das ist sicher als gegeben annehmbar, sondern die flugmechanik und vor allem die regelungstechnik) und der
dann ausgeführten realisierung muß stets erhalten bleiben. wenn das ding im versuch nicht das tut was die theorie (und optimal : die simulation) aussagt, dann muß da solange nachgedacht werden, bis die lücke gefüllt ist. anders langweilt das, dann kann ich gleich ne fertige maschine kaufen ...
noch interesse ?
du könntest auch wenn du magst teilfunktionen angehen. eine klasse für den pid-regler zum beispiel, der mal als kaskadenregler arbeitet und mal als reiner pid, auch das eine sehr lohnende übung für objektorientierung auf uC.
kann gar nicht glauben, daß es sonst niemand gibt, der mal mit dem superspielzeug copter (hab übrigens ne fpv-kamera drauf, und fliege - wenn man mein gehopse und in der luft rumstehen so nennen will - mit ner videobrille ... das ist obergeil !) ein wenig "moderne programmierung" spielen will.
wo sind denn die ganzen mechatroniker ?
wenn es dir nicht auf die zeit ankommt, könntest du das zeitparallel zu projekten an meiner schule mitmachen. einen eindruck kannst du hier gewinnen :
http://portal.ts-muenchen.de/index.php? ... &catid=125
wenn du auf "projekte 2013/14" gehst, siehst du wie es weitergehen könnte. aber : das dauert rund ein jahr. dazu fehlt mir die geduld.
kurzfristiger würde ich versuchen (so als testphase quasi), selbst erstmal ein uml-klassendiagramm für die zentralen flugfunktionen hinzukriegen. da wären wohl der digitale pid-regler, die digitalen filter, die motoransteuerung und sowas zu nennen. ich denke, so ein großes faß ist das gar nicht ...
hardware ist die fc 2.1 von mikrokopter.de, ich mach das zunächst ja nicht privat sondern eben im schulumfeld, und da ist ne fertige, ausgetestete hardwarebasis ohne bastelei wichtiger als der günstigste preis. (klar wäre wii spannender und ein 16 o. 32-bittler einfacher bezüglich der auslastung.)
wesentlichste grundbedingung : es wird nicht gebastelt. der konsistente zusammenhang zwischen allen physikalisch/technischen grundlagen (nicht die fertige e-technik, also motor oder prozessorfunktion und so, das ist sicher als gegeben annehmbar, sondern die flugmechanik und vor allem die regelungstechnik) und der
dann ausgeführten realisierung muß stets erhalten bleiben. wenn das ding im versuch nicht das tut was die theorie (und optimal : die simulation) aussagt, dann muß da solange nachgedacht werden, bis die lücke gefüllt ist. anders langweilt das, dann kann ich gleich ne fertige maschine kaufen ...
noch interesse ?
du könntest auch wenn du magst teilfunktionen angehen. eine klasse für den pid-regler zum beispiel, der mal als kaskadenregler arbeitet und mal als reiner pid, auch das eine sehr lohnende übung für objektorientierung auf uC.
kann gar nicht glauben, daß es sonst niemand gibt, der mal mit dem superspielzeug copter (hab übrigens ne fpv-kamera drauf, und fliege - wenn man mein gehopse und in der luft rumstehen so nennen will - mit ner videobrille ... das ist obergeil !) ein wenig "moderne programmierung" spielen will.
wo sind denn die ganzen mechatroniker ?
-
- Beiträge: 40
- Registriert: 06.05.2012 11:25:41
#4 Re: objektorientierung, uml und solche späße
mal den ball in die runde geworfen :
weil das ja keine informatiker-spielecke sein soll, denke ich, die uml-methode auf "industriestandard" zu beschränken. hier ein beispiel :
http://www.uni-kassel.de/upress/online/ ... t.frei.pdf
..so ab seite 39 wirds recht konkret. erster schritt (immer der schwerste, oder ?) : wie sehen attribute und methoden iregendeiner beispielklasse aus ?
ist "regler" eine klasse (dann als "höhe, "gier", "nick" usw... instanziert ?) ? wo ist dann der mischer für die regelgrößen ?
state-diagramme sind wohl unbrauchbar, weil wir ja keine statemachine haben, also nix sequentiell sondern alles gleichzeitig passiert. von den verschiedenen zeitrastern für abtastung und verschieden schnelle regler ganz zu schweigen ...
weil das ja keine informatiker-spielecke sein soll, denke ich, die uml-methode auf "industriestandard" zu beschränken. hier ein beispiel :
http://www.uni-kassel.de/upress/online/ ... t.frei.pdf
..so ab seite 39 wirds recht konkret. erster schritt (immer der schwerste, oder ?) : wie sehen attribute und methoden iregendeiner beispielklasse aus ?
ist "regler" eine klasse (dann als "höhe, "gier", "nick" usw... instanziert ?) ? wo ist dann der mischer für die regelgrößen ?
state-diagramme sind wohl unbrauchbar, weil wir ja keine statemachine haben, also nix sequentiell sondern alles gleichzeitig passiert. von den verschiedenen zeitrastern für abtastung und verschieden schnelle regler ganz zu schweigen ...
#5 Re: objektorientierung, uml und solche späße
Bedenke bei deinem Weg:
Microcontroller haben vor allem eines: Viel zu wenig Speicher! Wenn du alle aktuellen Funktionen abbilden willst, wirst du dir den Overhead, den du brauchst um sauber objektorientiert an Design-Modell lang zu implementieren, vielleicht nicht leisten können. Ich bin totaler Freund von sauberer und durchdachter Softwarearchitektur, aber manchmal muss das hinten anstehen, und zwar dann, wenn performance und speicher alles ist. Und das ist, meiner Erfahrung nach, der Fall bei nem Copter mit all den Funktionen.
Microcontroller haben vor allem eines: Viel zu wenig Speicher! Wenn du alle aktuellen Funktionen abbilden willst, wirst du dir den Overhead, den du brauchst um sauber objektorientiert an Design-Modell lang zu implementieren, vielleicht nicht leisten können. Ich bin totaler Freund von sauberer und durchdachter Softwarearchitektur, aber manchmal muss das hinten anstehen, und zwar dann, wenn performance und speicher alles ist. Und das ist, meiner Erfahrung nach, der Fall bei nem Copter mit all den Funktionen.
LG, Jens
Voodoo 700, Voodoo 600, Goblin 380
Diverse Schaumwaffeln und Multicopter
Jeti DS-16
Heli-Club Hamburg
Voodoo 700, Voodoo 600, Goblin 380
Diverse Schaumwaffeln und Multicopter
Jeti DS-16
Heli-Club Hamburg
-
- Beiträge: 40
- Registriert: 06.05.2012 11:25:41
#6 Re: objektorientierung, uml und solche späße
sehe ich nicht so.
ich hab den atmega128 (mikropkopter) eingesetzt, und kann mit 200 hz : achsen regeln (kaskade), höhe regeln (druck), gier regeln (externer kompass), rc decodieren, gps decodieren und uart bedienen ... und hab noch massig speicher frei. rechenleistung (ohne groß optimiert) ist auch noch da, ich schätze die auslastung (grob gemessen) auf rund 50 %
neuorganisation in oo/uml-struktur ist glaube ich weniger eine ressourcen-frage, als ein problem in meinem kopf.
der springt immer ins alte muster zurück
ich hab den atmega128 (mikropkopter) eingesetzt, und kann mit 200 hz : achsen regeln (kaskade), höhe regeln (druck), gier regeln (externer kompass), rc decodieren, gps decodieren und uart bedienen ... und hab noch massig speicher frei. rechenleistung (ohne groß optimiert) ist auch noch da, ich schätze die auslastung (grob gemessen) auf rund 50 %
neuorganisation in oo/uml-struktur ist glaube ich weniger eine ressourcen-frage, als ein problem in meinem kopf.
der springt immer ins alte muster zurück

#7 Re: objektorientierung, uml und solche späße
Wenn du das durchziehst, würd ich mich sehr über "Messdaten" freuen. Also einmal Berechnungszeiten vorher und nacher tracken usw. Normal bringt OOP sehr wohl einen gewissen Overhead mit, der definitiv messbar ist.
LG, Jens
Voodoo 700, Voodoo 600, Goblin 380
Diverse Schaumwaffeln und Multicopter
Jeti DS-16
Heli-Club Hamburg
Voodoo 700, Voodoo 600, Goblin 380
Diverse Schaumwaffeln und Multicopter
Jeti DS-16
Heli-Club Hamburg
#8 Re: objektorientierung, uml und solche späße
Mal so als einwurf am Rande, wenn etwas schnell und extrem optimiert sein soll kommt man an Assembler oft nicht vorbei da selbst Compiler die mehrere Tausend Euro kosten nicht immer den schnellsten Code für die Maschine erzeugen.
Objektorientierte programmierung braucht viel Overhead! d.h. es wird auch viel Maschinencode erzeugt der auch abgearbeitet werden muss. Objektorientierung kannst du dir nur auf guten Compilern und dafür optimierten Architekturen wirklich zielführend verwenden. In der Industrie verwendet man meist einfach C und Assembler und kein C++ wenn es um hardware nahe Sachen geht.
Soll dich jetzt aber nicht abhalten dein Projekt umzusetzen. denn wenn du es geschickt anstellst kannst du auch so schnellen code erzeuen der aber einer harwarenahen Implementierung immer noch unterlegen ist aber denoch für das was angestrebt schnell genug ist.
nur ein paar Gedanken und erfahrungen von mir.
Grüße,
Stefan
Objektorientierte programmierung braucht viel Overhead! d.h. es wird auch viel Maschinencode erzeugt der auch abgearbeitet werden muss. Objektorientierung kannst du dir nur auf guten Compilern und dafür optimierten Architekturen wirklich zielführend verwenden. In der Industrie verwendet man meist einfach C und Assembler und kein C++ wenn es um hardware nahe Sachen geht.
Soll dich jetzt aber nicht abhalten dein Projekt umzusetzen. denn wenn du es geschickt anstellst kannst du auch so schnellen code erzeuen der aber einer harwarenahen Implementierung immer noch unterlegen ist aber denoch für das was angestrebt schnell genug ist.
nur ein paar Gedanken und erfahrungen von mir.
Grüße,
Stefan
Grüße,
Stefan
mCPX, nano CPX, mSRX, trex 450 mutant (nicht flugbereit), trex 450 pro v2 FBL , Dx6i, Dx18, nochAurora 9 mit Spektrum Modul (ist aber abzugeben demnöchst), Sim: Heli-X
Stefan
mCPX, nano CPX, mSRX, trex 450 mutant (nicht flugbereit), trex 450 pro v2 FBL , Dx6i, Dx18, nochAurora 9 mit Spektrum Modul (ist aber abzugeben demnöchst), Sim: Heli-X
-
- Beiträge: 40
- Registriert: 06.05.2012 11:25:41
#9 Re: objektorientierung, uml und solche späße
also los, ein uml-modell muß her.
ich denke, ein "normales" klassendiagramm wär schon mal was. die echtzeit-erweiterungen, die es da gibt, sind vielleicht im ersten schritt mal noch unnötig.
gehts schon los : wie denkt man da jetzt ?
ist der ursprung eine klasse, die als flugobjekt beliebiger ausgestaltung als eigenschaften angeflogene raumkoordinaten hat...
oder ist das (enger am konventionellen) eine darstellung, die halt ein paar raumachsen hat, welche dann drunter mit ner reglerklasse und drunter sensorik usw. gestaltet wird ?
ich denke, ein "normales" klassendiagramm wär schon mal was. die echtzeit-erweiterungen, die es da gibt, sind vielleicht im ersten schritt mal noch unnötig.
gehts schon los : wie denkt man da jetzt ?
ist der ursprung eine klasse, die als flugobjekt beliebiger ausgestaltung als eigenschaften angeflogene raumkoordinaten hat...
oder ist das (enger am konventionellen) eine darstellung, die halt ein paar raumachsen hat, welche dann drunter mit ner reglerklasse und drunter sensorik usw. gestaltet wird ?
-
- Beiträge: 40
- Registriert: 06.05.2012 11:25:41
#10 Re: objektorientierung, uml und solche späße
ist das müll oder ein allererster schritt ?

das ziel wäre, unter einer ide (hier : sisy) eben keinen c++ - code aus der uml zu generieren, sondern aus effizienzgründen in den durch die uml erzeugten rahmen (incl. doku) den ganzen code selber reinzuschreiben. ich denke daß schon allein die übersicht was bringt. allerdings fehlt mir leider massig know-how
wie bring ich z.b. den vererbten pid-reglern bei, welche sensoren sie (mit welchen filtern dazwischen) benutzen sollen ?
ist das polymorphie ??

das ziel wäre, unter einer ide (hier : sisy) eben keinen c++ - code aus der uml zu generieren, sondern aus effizienzgründen in den durch die uml erzeugten rahmen (incl. doku) den ganzen code selber reinzuschreiben. ich denke daß schon allein die übersicht was bringt. allerdings fehlt mir leider massig know-how

ist das polymorphie ??
- the-fallen
- Beiträge: 1976
- Registriert: 07.03.2011 14:20:47
- Wohnort: zwischen Augsburg und Landsberg a.L.
#11 Re: objektorientierung, uml und solche späße
Das ist auf jeden Fall eine Spezialisierung.dollreiner hat geschrieben:wie bring ich z.b. den vererbten pid-reglern bei, welche sensoren sie (mit welchen filtern dazwischen) benutzen sollen ?
ist das polymorphie ??
Dein PID-Regler ist eine generalisierte -ggf sogar abstrakte- Klasse.
Zumindest glaube ich, dass du das meintest. Wenn du das so meintest sind die Pfeile falsch herum (aber es sind zumindest die richtigen Pfeile).
Der Pfeil geht imemr von derspezielleren zur abstrakteren Klasse ("Ich erbe Zeugs von...").
Ausserdem kapselst du deine Daten nicht.
Leit deinem diagramm sind alle Attribute ("Werte") der Klasse PID-Regler public. Das kann man machen, sollte man aber nicht, sondern lieber getter/setter verwenden. Gerade bei deiner Form der spezialisierung wirst du vermutlich den selben Gültigkeits-Prüfcode für Werte immer wieder verwenden. Der gehört dann in eine setter-Methode den akke Spezialisierten Objekte gleichermaßen benutzen.
Weiterhin sehe ich das Problem, dass du PId für Roll, Nick und Gier zwar getrennt berechnen kannst, aber irgendwo musst du das dann ja wieder mischen.
Da fehlt also noch irgendwas das die Werte mischt. Wenn z.b. Roll und Nick gleichzeitig betätigt werden muss sich der Steuerwert für die einzelnen Motoren irgendwo aus einem Zwischenwert berechnen.
Und dann noch vieles mehr.
- Prôtos FBL -stretched- a un motor 5+4D 1.13mm 14P de torro [V-Stabi]|[V-Gov] | [YGE90LV] | [UweG-Taumelscheibe] | [ZyclicMod]
- SuziJanis 700 UltraLight 3570g Abfluggewicht
- Besessen: T-Rex 250SE, T-Rex 450L, T-Rex600EFL, TDR, Blade mSRX
- nur Gebaut und eingeflogen: Blade700, Goblin500, TRex150 RKH, Blade 130X RKH, Vibe90
- Heizkoffersteuerung "HeatBox"
[" 99 little bugs in the code | 99 little bugs in the code | Take one down, patch it around | 117 little bugs in the code "] - Alex Shchepetilnikov
-
- Beiträge: 40
- Registriert: 06.05.2012 11:25:41
#12 Re: objektorientierung, uml und solche späße
... vieles, vieles mehr ! (momentan ist die lernkurve steil
diagramm hab ich modifiziert)
klar, der mischer (+begrenzer usw.) ist, dachte ich, teil der antriebs-klasse. mit prioritäten, welche aktion bei grenzwertiger last wichtiger (achslage vor höhe oder so) ist usw..
kapselung, dachte ich mr, brauchts nicht, weil keine "fehleingaben" oder so möglich sind. hier wollte ich aufwand sparen.
schwierig wirds, wenn die zeitbedingungen dargestellt werden sollen. z.b. nick/roll läuft bei mir im orginal mit 200hz, höhe mit 50hz und gps mit 10hz.
was besseres, als die klassen farbig zu machen (für zyklusrate) ist mir noch nicht eingefallen.

klar, der mischer (+begrenzer usw.) ist, dachte ich, teil der antriebs-klasse. mit prioritäten, welche aktion bei grenzwertiger last wichtiger (achslage vor höhe oder so) ist usw..
kapselung, dachte ich mr, brauchts nicht, weil keine "fehleingaben" oder so möglich sind. hier wollte ich aufwand sparen.
schwierig wirds, wenn die zeitbedingungen dargestellt werden sollen. z.b. nick/roll läuft bei mir im orginal mit 200hz, höhe mit 50hz und gps mit 10hz.
was besseres, als die klassen farbig zu machen (für zyklusrate) ist mir noch nicht eingefallen.
- acanthurus
- Beiträge: 3348
- Registriert: 21.10.2008 08:39:59
- Wohnort: Kreis Ludwigsburg
#13 Re: objektorientierung, uml und solche späße
Hi..
Hoi.. ich lese hier mit großem Interesse mit...
Erst mal Danke für den Hinweis auf Luna, das klingt für mich (damals Ende der 80er sehr TurboPascal-fleissig) äußerst interessant. Ich hab zwar auch immer wieder mal C programmiert (speziell auch WinAVR), aber irgendwie werde ich mit dieser Sprache nicht so recht warm.
gruß
andi
Hoi.. ich lese hier mit großem Interesse mit...
Erst mal Danke für den Hinweis auf Luna, das klingt für mich (damals Ende der 80er sehr TurboPascal-fleissig) äußerst interessant. Ich hab zwar auch immer wieder mal C programmiert (speziell auch WinAVR), aber irgendwie werde ich mit dieser Sprache nicht so recht warm.
gruß
andi
I told my mom when I grow up I want to be an Engineer, she told me I can't do both!
-
- Beiträge: 14
- Registriert: 06.02.2013 18:32:26
- Wohnort: Bestensee
#14 Re: objektorientierung, uml und solche späße
dollreiner hat geschrieben:ich weiß nicht, ob forum und topic richtig sind, trotzdem mal hier probiert :
ich möchte einen übersichtlichen (!!!) 4copter selberprogrammieren, von der achsregelung bis zum gps-waypoint. hardware (teuer, aber fertig) von mikrokopter.
..blöde idee oder interessiert das jemanden ?
Hi,
Also ich arbeite gerade an einem ähnlichen Projekt.
Komplette Stabilisierungssystem 9DOF mit GPS. Wobei noch eine komplettes Telemetrie-System mit Sensoren für Strom/Spannung/Temp/Rpm via 433MHz Funk integriert ist.
Die Hardware ist schon fertig, alles auf einer kleinen Platine. Erste Software Module laufen auch schon.
Ich selber habe "Luna" auch schon getestet . Finde ich ebenfalls ganz toll. Ist soon Mix aus Basic und Pascal.
Also wenn du willst, können wir ja mal was zusammen machen....
Gruß
Oliver
www.flightcommand.de
LAMA-315B, 22Kg, 2,75m Rotor
-
- Beiträge: 40
- Registriert: 06.05.2012 11:25:41
#15 Re: objektorientierung, uml und solche späße
wie machst du die 433 mhz ?
ich habe ein modul in der warteschleife auf der werkbank : rfm12bp (von pollin). dachte mir, damit ne bidirektionale rs232-funkstrecke zu bauen, telemetrie runter (um z.b. einen künstlichen horizont zu ermöglichen) und steuersignale rauf. steuerung aus dem laptop über joystick. dazu brauchts gps, weil der copter den ort selber halten muß (sonst stört die latenz in der steuerung).
zum gps : mein "venus" liefert prima nmea-daten, allerdings bislang nur mit 1 hz, was aber vielleicht ausreicht. problem ist die stabiliserung damit, weil ein pid sehr schwer zu parametrieren/testen ist (rumlaufen im garten .. die nachbern lachen sich tot). wie machst du das mit der regelung aus dem gps .. ein pid-regler ?
ich habe ein modul in der warteschleife auf der werkbank : rfm12bp (von pollin). dachte mir, damit ne bidirektionale rs232-funkstrecke zu bauen, telemetrie runter (um z.b. einen künstlichen horizont zu ermöglichen) und steuersignale rauf. steuerung aus dem laptop über joystick. dazu brauchts gps, weil der copter den ort selber halten muß (sonst stört die latenz in der steuerung).
zum gps : mein "venus" liefert prima nmea-daten, allerdings bislang nur mit 1 hz, was aber vielleicht ausreicht. problem ist die stabiliserung damit, weil ein pid sehr schwer zu parametrieren/testen ist (rumlaufen im garten .. die nachbern lachen sich tot). wie machst du das mit der regelung aus dem gps .. ein pid-regler ?