NAZE32 - alternative Software

Ja, das kann gut sein:
"dankers" (OP-Chef ?)im OP-Froum:

Im gleichen Thema kann man auch Jürgens feinste Englisch-nicht-Kenntnisse bewundern

btw. Prozessor der CC3D und der Naze32 ist identisch.

Mit Geld hatte es auf jeden Fall zu tun, kann mich an Vorwürfe erinnern die in Richtung Diebstahl gingen und für Anwälte wurde auch Kohle gesammelt.


Dafür kann Juergen bestimmt besser Russisch als wir!

auskennen wäre zu viel gesagt.
aber die Umbenennung wäre wohl das kleinere Problem, und ob MPU mit I2C statt SPI,
sollte auch kein Problem darstellen.

für ein Betriebssystem brauchst du aber zusätzlichen Speicher.
und ob das bei einem STM32F103R8 Sinn ergibt, wage ich doch stark zu bezweifeln.

da gibt es nach 3 Jahren inzwischen geignete Prozessoren.

Vielleicht hat auch schon jemand irgendwo Hirn gesammelt und openpilot auf den Naze32 gepackt. Ich fresse einen Besen, wenn das nicht schon irgendwo gemacht wurde. Den sourcecode habe ich jetzt runtergezogen, die verwenden ein sog. "FreeRTOS". Schrecklich kompliziert das ganze.
EDIT: Speicher hin oder her, die CPU ist GLEICH.

nun komma, ich habe nie behauptet das es das gibt, dafür hat Google das aber brauchbar gemacht.

leider ist das bei französisch oder oder spanisch, mehr als spanisch.

naja, was wollen wir mit zusätzlich Magnetometer, Barometer, oder gar GPS ?

wenn wir "FreeRTOS" haben können.

@Roberto

Hehehe jetzt bist du angefixed

Aber ich muß Juergen da recht geben.
Beim OP ist der ACC zwar super, aber der HH Mode gefällt mir bei der Naze besser!
Vorteilhaft wäre das nur wenn man vom Funflieger ganz weggeht um die mitverschenkten Sensoren zu tunen und für GPS Coming home und solche Geschichten zu benutzen, bzw. weitere Peripherie.

Gruß

Nach googlen und Forenquerlesen ist eines sicher: um den NAZE32 und openpilot wird gekreist, wie die Katze um den heissen Brei. Wobei der heisse Brei Naze32 ist. Es wird häufiger die "Openpilot-Lizenz" erwähnt, die ich mir mangels Interesse nicht angeschaut habe. Wenn man auch hier die Posts mit zusammengetragenen Forenbeiträgen so liesst, habe ich den Eindruck: Man hat Angst, dass sich Timecop eine goldene Nase verdienen könnte. Das er das nicht macht, liegt natürlich nur daran, dass er ein Gutmensch ist. Ist ja klar! Das Verwenden, der deutlich schlechter ausgestatteten, Discoveryboards ist nämlich plötzlich überhaupt kein Problem, da verdient schliesslich ein anonymer Konzern direkt. So viel zur openpilot/naze Psychose. Bei der Hardware scheint die Openpilot-Busanbindung wohl per SPI und nicht I2C zu erfolgen (wie APM/Crius). Beim Umschiffen dieses Problems http://forums.openpilot.org/topic/13432-diy-openpilot-based-flightcontrol/#entry121948 spielt irgendwie das FreeRTOS eine Rolle. Schade, dass ich zu doof bin.

LG
Rob

EDIT: ps.: Jürgen taucht verdächtig häufig in den Foren auf, der gehört zu dem gut informierten Personenkreis!

EDIT,EDIT: Hat jemand mal geschaut, ob harakiri2 mit acc_hardware 2, also der MPU 6050 funktioniert?

wieso scheint?
lesen sie denn keine Schaltbilder ?
-> http://wiki.openpilot.org/download/....pdf?version=1&modificationDate=1306203868000
-> http://git.openpilot.org/browse/~ra...pterControl 3D/CopterControl 3D Schematic.pdf


ich hatte zumindestens das Glück, keinen OP-CC damals abzubekommen.
nun kann es mir gestohlen bleiben. auch ein NAZE32 fliegt nur der Prozessor mit IMU
(was mich am NAZE32 noch stört, ist das USB, braucht man bei blauzahn nicht)


bei mir liegt die Kunst, im weglassen. AERODUINO
jedes Bauteil (auch Code) zu viel, kann nur eine zusätzliche Störquelle sein.

Mir hat gestern leider aufgrund der langen feuchten Samstagnacht die ruhige Hand für solche Tests gefehlt.
In der Wohnung kann ich mir keine 2Meter Sprünge leisten , ist ja die dunkle Jahreszeit, aber ich machs gern am kommenden Wochenende.

Gruß

@Komma: Das ist doch mal ein Wort! Bis dahin habe ich vielleicht auch Post aus Japan. Mal sehen, ob mich der Weihnachtsmann schon vorher ein Geschenk auspacken lässt.. Tja, den Code habe ich noch mal angestarrt aber irgendwie sieht das ok aus, wo ist bloss der Känguru - Teil? Da war bestimmt Hüpfstrom im Lipo!
Ach, ja im mwii Forum hat sich noch keiner gemeldet.
Mit der Kunst des Weglassens hat Jürgen sicher nicht ganz unrecht, selbst wenn man einen 1000% korrekten C code zusammenstricken würde, kann der Compiler immer noch Hackfleisch draus machen. Ein zusätzliches Betriebssystem mit zig 1000 Programmzeilen ist dann auch nochmal eine Fehlerquelle.
Mit dem zweiten ACC könnte man vielleicht auch noch etwas anfangen, wenn man eine deutlich unterschiedliche Empfindlichkeit einstellt.

LG
Rob

@Roberto

Wie das mit der Neugierde so ist, konnte ichs nicht lassen und hab in der Bude mal Trockentests gemacht.
Um einen Vergleich zu haben erst mit der R235 dann mit der Harakiri2 die wie ich sagen muß ihren Namen verdient!
Kann das Känguru das meine Vorgänger so betitelt haben bestätigen.

Nach einschalten des Baro sackt er erstmal ordentlich durch, um anschließend mit nem heftigen Sprung nach oben zu schießen und das bei Gasstellung 20%
Der gefühlte Gaswert war bestimmt bei 70%.

(Hat mir den Flieger natürlich aus der Hand gerissen, zuerst den Unterarm touchiert um dann mit 3 Propellern ne Notlandung zu versuchen!) Nix weiter passiert!

Nu ist das jetzt nicht so aussagekräftig, weil der Flieger ja locker freischwebend festgehalten wurde, aber ich hab ja den Vergleich mit der Originalsoft.
Direkt am Tisch festgehalten mit eingeschaltetem Baro macht er zuerst was er soll, nämlich beim Gasgeben keins annehmen.
nach ein paar Sekunden ohne änderung der Gasstellung jedoch heftige kurze Gasstöße.

Ich weiß jetzt nicht, ob du damit was Anfangen kannst, aber wenn ich mit meinem Leichtgewicht so fliegen würde,wären die
Kängurusprünge wahrscheinlich 4m weit und ich würde sicher Crashen.
Dazu muß ich noch sagen das der Baro mit Originalsoft mittlerweile bei mir schon einigermaßen zufriedenstellend funktioniert.

Danke für Deinen Test, Komma!
Gottseidank ist nichts passiert !!!!
Das hier:
Klingt verdächtig nach verdrehter Sensorachse (Acc Z), kann aber eigentlich auch nicht sein, wenn das Original funktioniert....hmmm alles SEHR merkwürdig. Ich denke, da muss irgendwo noch eine Eigenheit im Timecop code beim ACC Auslesen und der acc1_G Bestimmung sein. Wenn Die Hardware da ist, kann ich dem Code mal auf den Zahn fühlen.
Nach Deinem Testergebnis, nehme ich das Hexfile jetzt raus, ich will hier niemanden verletzen!


LG
Rob

Der lässt sich unter anderem auch von zuvielen Leuten in die Software pfuschen und übernimmt dann teilweise komische Fragmente...bin gespannt ob der auch dein code mit rein nimmt wenn er vollendet ist

na,
das wollen wir doch ganz stark hoffen ?

Mit meinem X-BL Spielzeug kann da ausser ein paar Kratzern nicht viel passieren!
Der 0845 EPP ist an meinem Unterarm zerschellt!

Codegefummel

Danke, für eure aufmunternden Worte!

Da ich bislang noch nie Kontakt zu einer echten Software - Entwicklungsumgebung hatte, und die Kompilierungsanleitungen zu Baseflight mich nicht zum Ziel brachten, wollte ich hier mal schreiben wie es bei mir geklappt hat. Die Anleitung wird bei Programmierern wahrscheinlich Lachkrämpfe provozieren, aber wenn etwas falsch ist - bitte melden !!
Timecop verwendet Keil u vision. Entweder kauft man es sich, oder lädt die freie Version herunter.
http://www.keil.com/uvision/
Man kann sich da schnell mit Unfug registrieren (wer macht schon sowas...).
Den aktuellen Baseflight Quellcode kann man z.B mit dem Programm: http://downloadsvn.codeplex.com/releases/view/54881 unter Angabe dieser Adresse http://afrodevices.googlecode.com/svn/trunk/baseflight/ herunter laden. Alternativ gibt es den hier https://github.com/fiendie/baseflight/tree/master auch direkt als zip-Datei.
So, wir haben jetzt den Quellcode zum basteln und die beschränkte Frei-Version (Leute mit der Vollversion sind jetzt fertig).

Die freie Keil u vision Version ist auf eine, schnell erreichte, Kompilatgrösse beschränkt. Von Jürgen kam der wertvolle Tip mit der freien "px4 toolchain" (https://github.com/PX4/Toolchain/downloads). Die installiert man in "C:\px4". Da habe ich aus Tippfaulheit den Ordner "bf" erstellt, und den Baseflight code hinkopiert. Wenn man "baseflight.uvproj" aufruft, öffnet sich u-vision und man bekommt den Quellcode schön übersichtlich dargestellt. Jetzt kann man editieren und speichern. Zum Probecompilieren reicht es auch, und man hat schnell Fehler gefunden, im letzten Schritt vor der Hexdatei, dem "Linker", steigt es dann mit der Meldung "kauf mich" aus. Dann kann man die PX4 toolchain console öffnen und wechselt mit "cd bf" in das Verzeichnis und führt "make" aus - bingo, unter "obj" ist das ersehnte Hex file. Das funktioniert aber nur 1 mal, da (warum auch immer) die Datei C:\px4\bf\src\baseflight_startups\startup_stm32f10x_md_gcc.S gelöscht wird! Die muss man jedes mal wieder reinkopieren .
Die Pfadnamen kurz und ohne r/Sonderzeichen halten. Also PX4 nicht in "Program Files (x86)", oder so, installieren.
So weit meine erste Begegnung mit einer echten Entwickleroberfläche und "make" ......

LG
Rob

EDIT:
Komma, ein Mann aus Stahl

Wohl eher aus Holz
Wildschweine wetzen sich oefter mal dran.

Respekt wie du dich hier reinkniest

Moin Roberto,

ich benutz eclipse, aber damit du deine Datei nicht immer kopieren musst, nimm doch einfach eine Batchdatei, siehe Anhang.
Leg die einfach in den Ordner in dem du sonst make ausführst, leg unter bf noch einen Ordner "backup" an und kopier die startup_stm32f10 x_md_gcc.S dort hin.
Mit dem Ausführen der Batchdatei kopiert er die Datei in den startups folder und führt make aus, so haste nur einen Mausklick und das auch direkt aus'm Explorer und musst nicht immer in die Konsole wechseln

Gruß

mag ja sein das die zum anfixen von professionellen Softwareschnitzern taugt.
aber ich bin mit so etwas durch.

ECLIPSE und die verschiedenen freien Toolchain, haben sich inzwischen gut entwickelt.
und eine gute Anlaufstelle war bisher immer noch hier.
-> http://www.mikrocontroller.net/articles/ARM