Autoquad M4 kompatible FC für Brushless Motoren (kein Clone)
- Themenstarter meister
- Beginndatum
Zitat OlliW: "...der Punkt ist das man FREIEN Zugang zu allen Code-Teilen welche es braucht um den AQ Firmware Objectcode zu erstellen braucht, das bezieht sich nicht auf die Tools, aber wohl auf die Teile welche in die finale Hex eingebunden werden!" http://fpv-community.de/showthread....n-(kein-Clone)&p=800547&viewfull=1#post800547
Außerdem: "D.h. die CrossWork und Quantos müssten nach 5c&6 zur Verfügung gestellt werden, und sobald sie Jemand hat müsste sie/er sie ohne Probleme auch kostenlos an jeden Anderen weiterverteilen dürfen."
http://fpv-community.de/showthread....n-(kein-Clone)&p=800495&viewfull=1#post800495
Also erzähl jetzt keinen Stuss und behaupte, man hätte Dir das Wort verdreht.
Sorry, aber wer so daher kommt, hat sich in meinen Augen als OS Experte völlig demontiert.
[video=youtube;rq68A07CDcM]https://www.youtube.com/watch?v=rq68A07CDcM[/video]
Zu Quatos hast Du ja auch eine eindeutige, unumstößliche "Meinung":
http://fpv-community.de/showthread....n-(kein-Clone)&p=800972&viewfull=1#post800972
Punkt, Punkt, Komma, Strich. GPL schützt in erster Linie die Freiheitsrechte der Endnutzer - das is offenbar immer noch nich bei Dir durchgesickert...
Dein Rechtsempfinden find ich gelinde gesagt seltsam:
Du willst also allen Ernstes dem Urheber verbieten, Zusätze wie Quatos zu seinem eigenen GPL Code zu kommerzialisieren?
1. ist der Urheber zufällig derjenige, der "was Schönes" daraus macht und
2. wird nicht der Source Code geschlossen gehalten, sondern der Zusatz - was den "Fall" komplett obsolet macht und keiner weiteren Diskussion bedarf. Case closed, Punkt!
Egal, spinnen wir mal weiter:
Streng genommen dürfte nach Deinem "Empfinden" (denn was anderes is Deine unausgegorene Rechtskenntnis nich) z.B. Tilman (oder irgendwer sonst) den Code nicht nehmen und "was Schönes" draus machen, z.B. Copter in Serie bauen und verkaufen. Und er hat noch nicht einmal den Aufwand, Beiträge mit einer gewissen Schöpfungshöhe zu erbringen, geschweige denn zu publizieren. Danach richtet sich nämlich das "geistige Eigentum", das Du als Urheber doch auch geschützt haben möchtest, oder???
Zu dieser Form des Rechtsempfindens gehört wohl auch, dass sich der Angeschuldigte hier erstmal auf eine Umkehr der Beweislast gefasst machen muss: eine bloße Behauptung ("verstößt gegen GPL, Punkt!") reicht, um den Delinquenten dingfest zu machen. Punkt? Au warte...
Jaja, genau das muss wohl der Grund sein, warum Dein Code closed source ist:
http://www.olliw.eu/2013/storm32bgc/#termsofusagefirmware
The o323BGC firmware is free (but not open source).
Darf jeder anfassen - aber nich kucken! LOL
Cleverer Ansatz: da kann man ja auf andere eindreschen, die sich die Blöße einer freien Softwarelizenz geben - man hat ja selber keine Probleme damit. LOL
Und Du willst andere über Lizenzrecht belehren? Klar, man kann auch den Bock zum Gärtner machen, LOLLOLLOL!!!
Außerdem: "D.h. die CrossWork und Quantos müssten nach 5c&6 zur Verfügung gestellt werden, und sobald sie Jemand hat müsste sie/er sie ohne Probleme auch kostenlos an jeden Anderen weiterverteilen dürfen."
http://fpv-community.de/showthread....n-(kein-Clone)&p=800495&viewfull=1#post800495
Also erzähl jetzt keinen Stuss und behaupte, man hätte Dir das Wort verdreht.
Sorry, aber wer so daher kommt, hat sich in meinen Augen als OS Experte völlig demontiert.
[video=youtube;rq68A07CDcM]https://www.youtube.com/watch?v=rq68A07CDcM[/video]
Zu Quatos hast Du ja auch eine eindeutige, unumstößliche "Meinung":
http://fpv-community.de/showthread....n-(kein-Clone)&p=800972&viewfull=1#post800972
Punkt, Punkt, Komma, Strich. GPL schützt in erster Linie die Freiheitsrechte der Endnutzer - das is offenbar immer noch nich bei Dir durchgesickert...
Dein Rechtsempfinden find ich gelinde gesagt seltsam:
Du willst also allen Ernstes dem Urheber verbieten, Zusätze wie Quatos zu seinem eigenen GPL Code zu kommerzialisieren?
1. ist der Urheber zufällig derjenige, der "was Schönes" daraus macht und
2. wird nicht der Source Code geschlossen gehalten, sondern der Zusatz - was den "Fall" komplett obsolet macht und keiner weiteren Diskussion bedarf. Case closed, Punkt!
Egal, spinnen wir mal weiter:
Streng genommen dürfte nach Deinem "Empfinden" (denn was anderes is Deine unausgegorene Rechtskenntnis nich) z.B. Tilman (oder irgendwer sonst) den Code nicht nehmen und "was Schönes" draus machen, z.B. Copter in Serie bauen und verkaufen. Und er hat noch nicht einmal den Aufwand, Beiträge mit einer gewissen Schöpfungshöhe zu erbringen, geschweige denn zu publizieren. Danach richtet sich nämlich das "geistige Eigentum", das Du als Urheber doch auch geschützt haben möchtest, oder???
Zu dieser Form des Rechtsempfindens gehört wohl auch, dass sich der Angeschuldigte hier erstmal auf eine Umkehr der Beweislast gefasst machen muss: eine bloße Behauptung ("verstößt gegen GPL, Punkt!") reicht, um den Delinquenten dingfest zu machen. Punkt? Au warte...
Jaja, genau das muss wohl der Grund sein, warum Dein Code closed source ist:
http://www.olliw.eu/2013/storm32bgc/#termsofusagefirmware
The o323BGC firmware is free (but not open source).
Darf jeder anfassen - aber nich kucken! LOL
Cleverer Ansatz: da kann man ja auf andere eindreschen, die sich die Blöße einer freien Softwarelizenz geben - man hat ja selber keine Probleme damit. LOL
Und Du willst andere über Lizenzrecht belehren? Klar, man kann auch den Bock zum Gärtner machen, LOLLOLLOL!!!
Zuletzt bearbeitet:
Wieder eine unreflektierte Behauptung...
Die beiden Versionen liegen 16 Jahre(!) auseinander. Insbesondere bei den hier im Disput stehenden Aspekten hat es drastische Veränderungen gegeben, siehe hier:
http://www.gnu.org/licenses/quick-guide-gplv3.html
Zitat: "The new definition also makes it clear that you can combine GPLed software with GPL-incompatible System Libraries, such as OpenSolaris' C library, and distribute them both together. These changes will make life easier for free software distributors who want to provide these combinations to their users."
Meister Olli: im Übrigen steht es Dir frei, Administratoren von FPVC zu bitten, den Thread zu verschieben, z.B. hierhin:
http://fpv-community.de/forumdisplay.php?21-Copter-Allgemein
An Deiner Stelle würd ich mich hier bei den GPL-Verletzern äußerst unwohl fühlen...
Die beiden Versionen liegen 16 Jahre(!) auseinander. Insbesondere bei den hier im Disput stehenden Aspekten hat es drastische Veränderungen gegeben, siehe hier:
http://www.gnu.org/licenses/quick-guide-gplv3.html
Zitat: "The new definition also makes it clear that you can combine GPLed software with GPL-incompatible System Libraries, such as OpenSolaris' C library, and distribute them both together. These changes will make life easier for free software distributors who want to provide these combinations to their users."
Meister Olli: im Übrigen steht es Dir frei, Administratoren von FPVC zu bitten, den Thread zu verschieben, z.B. hierhin:
http://fpv-community.de/forumdisplay.php?21-Copter-Allgemein
An Deiner Stelle würd ich mich hier bei den GPL-Verletzern äußerst unwohl fühlen...
Ja und? Es ist trotzdem "GPL-inkompatibel"!
Für mich is das Thema jetzt durch. Beschwer Dich bei Richard Stallman oder der FSF, wenn´s Dir nich passt.
Oder konsultier mal einen Fachanwalt in Lizenzrecht - der erklärt Dir und der geifernden Bagage, die Du hier angelockt hast mal, wo der Hammer hängt.
Und viel Glück mit Deiner inkompatiblen Hardware - den Threadtitel solltest Du für Deine ungetestete v0.91 auch mal ändern. Durch die Änderung der Pinbelegung entspricht das auch nicht mehr den Tatsachen!
Für mich is das Thema jetzt durch. Beschwer Dich bei Richard Stallman oder der FSF, wenn´s Dir nich passt.
Oder konsultier mal einen Fachanwalt in Lizenzrecht - der erklärt Dir und der geifernden Bagage, die Du hier angelockt hast mal, wo der Hammer hängt.
Und viel Glück mit Deiner inkompatiblen Hardware - den Threadtitel solltest Du für Deine ungetestete v0.91 auch mal ändern. Durch die Änderung der Pinbelegung entspricht das auch nicht mehr den Tatsachen!
Das Thema hier war echt spannend bis ihr mit GPL-Lizenzen ( was immer auch sein mag) angefangen habt. Ich würde sagen macht doch wegen dem Problem einen extra Thread auf (Den Thread lese ich dann nämlich nicht) Im Leben hat jeder manchmal ein wenig mehr recht. Ich hab jedoch lieber meine Ruhe dann kann der andere auch Recht haben.
Das Projekt von Meister ist jedenfalls sehr spanend.
Das Projekt von Meister ist jedenfalls sehr spanend.
also die 0.91 ist noch pinkompatibel zur M4, is im Prinzip die 0.90 nur mit paar bugfixes und einem inverter für S-BUS.
Im Moment warten wir aber noch auf die Platinen von oshpark, ich denke jedoch nicht das es zu großen Problemen kommen sollte da nicht viel geändert wurde.
Die 'comming soon Platine' wird zwar noch kompatibel zu AQ sein jedoch nicht mehr Pinkompatibel zur M4, da ich so ein paar mehr PWM's und Serial-Port's frei machen konnte.
Aber dafür kann ich ja einen frischen Thread starten
Ich versuche auch mal Cleanflight auf der OpenFC zum laufen zu bringen, damit ein wenig mehr auswahl in sachen Firmware besteht.
Gruß,
Olli
Im Moment warten wir aber noch auf die Platinen von oshpark, ich denke jedoch nicht das es zu großen Problemen kommen sollte da nicht viel geändert wurde.
Die 'comming soon Platine' wird zwar noch kompatibel zu AQ sein jedoch nicht mehr Pinkompatibel zur M4, da ich so ein paar mehr PWM's und Serial-Port's frei machen konnte.
Aber dafür kann ich ja einen frischen Thread starten
Ich versuche auch mal Cleanflight auf der OpenFC zum laufen zu bringen, damit ein wenig mehr auswahl in sachen Firmware besteht.
Gruß,
Olli
Zuletzt bearbeitet:
Achso, mit der portierung von AQ auf einen freien gcc bin ich einen schritt weiter gekommen, anscheind scheint es kein reines compiler problem zu sein,
sondern auch schon vorher ein speicher-problem in der AQ-Firmware zu existieren was sich nur durch den anderen compiler stärker bemerkbar macht.
Zumindest habe ich, wenn ich ein original binary für den M4 runterlade und auf die openfc lade ähnliche phänomene die nach einen 'buffer-overflow' ausschauen, ich glaube nicht das es nur durch die andere hardware kommt.
Werde das morgen auch mal mit dem org. AQ6-Board testen.
Gruß,
Olli
sondern auch schon vorher ein speicher-problem in der AQ-Firmware zu existieren was sich nur durch den anderen compiler stärker bemerkbar macht.
Zumindest habe ich, wenn ich ein original binary für den M4 runterlade und auf die openfc lade ähnliche phänomene die nach einen 'buffer-overflow' ausschauen, ich glaube nicht das es nur durch die andere hardware kommt.
Werde das morgen auch mal mit dem org. AQ6-Board testen.
Gruß,
Olli
Zuletzt bearbeitet:
Also der Bug existiert auch auf der AQ6:
serial-ausgaben auf AQ6 mit firmware: aqv7.0.r442.b1848-hwv6.1-dimu1.1.hex
serial-ausgaben auf OpenFC mit firmware: aqv7.0.r442.b1848-hwv8.6-ext_esc.bin
Ich denke mal es fällt schnell auf das dort ausgaben existieren die dort nicht sein dürften, da werden anscheind Speicherbereiche mit gesendet die außerhalb des gewollten bereichs liegen.
Beobacht man nur die ausgaben von mavlink sieht man es nicht, da dort alles in mavlink-messages verpackt ist, wenn man jedoch direkt am serial hört erkennt man das problem.
Unter linux:
cat /dev/ttyUSB0 | strings
Wer es nicht auf den ersten blick erkennt, es geht um zeilen wie diese:
Der dazu passende string im Code:
dürfte so nie ausgegeben werden.
Gruß,
Olli
EDIT: will nochmal hervorheben falls unklar, ausgabe 1 ist ein Original AQ6 mit Original Binary von der AQ-Website, das hat soweit nichts mit OpenFC oder freien gcc/libs zu tun, ist mir dort nur das erstemal aufgefallen
serial-ausgaben auf AQ6 mit firmware: aqv7.0.r442.b1848-hwv6.1-dimu1.1.hex
Code:
Mavlink init
ADC init
Battery cells: %d
InitializationRk
ADC task started
ADC init
Battery cells:5C
Supervisor task started
Disarmed
Armed
DIMU: read calibration parameters from EEPROM
Battery cells: 2
Warning: Low battery stage 1
Warning: Low batte!
Warning: Low battery stage 2
Radio init
WARNING: Invalid radio type!
CYRF69Y
GPS init
$Revision: 442 $
$Revision: %ld
Nav init
Command interface init
config: Loaded default par
Q2BFLOW_GYRO_COM
Q2USB_SEND_VIDEO
Motors init
Motors: ERROR! Predefined frame tyVJ
Control init
CAN: Found %d node type %s
NONE
Control task started
Control init
CAN: Found
Gimbal init
Gimbal functions disabled.
GimbalY3
AQ S/N: ---------------------------
Mavlink SYS ID: 191
SYS Clock: 168 MHz
8212/8212 heap used/high water
32932 of 40960 CCM heap used
Radio task started
Radio init
WARNING: Invalid r(
Run task started
BFLOW_GYRO_COM
USB_SEND_VIDEO
AQ FW ver: 7.0 - BETA rev442 b1848, HW ver: 6 rev1I
Disarmed
Armed
Arm motors failed - disarmed
Initialization complete, READY.
INIT
FILER
Code:
Mavlink init
Supervisor task started
Disarmed
Armed
DIMU: read calibration parameters from EEPROM
Battery cells: 1
Warning: Low battery stage 1
Warning: Low batte
Warning: Low battery stage 2
AutoQuad.org
Radio init
WARNING: Invalid radio type!
CYRF69!~
GPS init
$Revision: 442 $
$Revision: %ld
Nav init
Command interface init
config: Loaded default par
Q2BFLOW_GYRO_COM
Q2USB_SEND_VIDEO
Motors init
Motors: ERROR! Predefined frame ty
Control init
CAN: Found %d node type %s
NONE
Control task started
Control init
CAN: Found
Gimbal init
Gimbal functions disabled.
Gimbal
AQ S/N: ---------
Mavlink SYS ID: 104
SYS Clock: 168 MHz
7608/7608 heap used/high water
32372 of 40960 CCM heap used
Radio task started
Radio init
WARNING: Invalid rPk
Run task started
BFLOW_GYRO_COM
USB_SEND_VIDEO
AQ FW ver: 7.0 - BETA rev442 b1848, HW ver: 8 rev6"
Disarmed
Armed
Arm motors failed - disarmed
Initialization complete, READY.
INIT
FILERBeobacht man nur die ausgaben von mavlink sieht man es nicht, da dort alles in mavlink-messages verpackt ist, wenn man jedoch direkt am serial hört erkennt man das problem.
Unter linux:
cat /dev/ttyUSB0 | strings
Wer es nicht auf den ersten blick erkennt, es geht um zeilen wie diese:
Code:
GPS init
$Revision: 442 $
$Revision: %ld
Nav init
Code:
sscanf(REVISION, "$Revision: %ld", &rev);Gruß,
Olli
EDIT: will nochmal hervorheben falls unklar, ausgabe 1 ist ein Original AQ6 mit Original Binary von der AQ-Website, das hat soweit nichts mit OpenFC oder freien gcc/libs zu tun, ist mir dort nur das erstemal aufgefallen
Zuletzt bearbeitet:
Vllt. hilft das hier?
https://github.com/mpaperno/aq_flight_control/commit/a95db4f9d613cb8b3b9060fa98ff8544f93b833a
"Fixes a memory alignment problem which may also affect scanf()"
Und dann noch das:
"GCC ARM linker needs a special directive in order to be able to handle floats/doubles in printf/scanf"
https://github.com/mpaperno/aq_flight_control/commit/a95db4f9d613cb8b3b9060fa98ff8544f93b833a
"Fixes a memory alignment problem which may also affect scanf()"
Und dann noch das:
"GCC ARM linker needs a special directive in order to be able to handle floats/doubles in printf/scanf"
