NAZE32 - alternative Software
- Themenstarter JUERGEN_
- Beginndatum
- Status
Harakiri08
Hi!
Ich bin absolut abgenervt von dem heutigen Tag, nach einer durchprogrammierten Nacht, ein paar Stunden Schlaf und dann das Sonntagsprogramm bei schönem Wetter, leider ohne Copter. Zu den LED's: Die blinken unabhängig von der Cycletime. Zu Ublox: Da ich keines habe, kann ich es nicht supporten. Ich schaue mir gern nochmal den Source an, aber sonst müsst Ihr einfach mal selbst das Ublox Problem suchen und beheben (GPS.c am Ende). Der Source ist frei.
So die GPS/ACC Fusion ist fertig und funktioniert. Bisher konnte ich nur Poshold testen, das läuft geil. RTH sollte aber auch funktionieren. Im GPS Code habe ich diverse Initialisierungsprobleme behoben, die ggf. 0-Koordinaten geliefert haben - und damit einen rasanten Abflug nach Westen. Die GPS Routine wird jetzt bei jedem Durchlauf aufgerufen und regelt schnell und feinstufig. Bei meinem letzten Testflug hatte ich das gps_ins_cf = 0.995, das ist schon sehr hoch. Dieser Wert ist auch im compilierten Hex voreingestellt. Wenn er zu hoch sein sollte, könnt ihr ihn erst auf gps_ins_cf = 0.900 herunter nehmen, und euch dann hocharbeiten. GPS INS ist also per default an, weil es läuft
.
LG
Rob
Hi!
Ich bin absolut abgenervt von dem heutigen Tag, nach einer durchprogrammierten Nacht, ein paar Stunden Schlaf und dann das Sonntagsprogramm bei schönem Wetter, leider ohne Copter. Zu den LED's: Die blinken unabhängig von der Cycletime. Zu Ublox: Da ich keines habe, kann ich es nicht supporten. Ich schaue mir gern nochmal den Source an, aber sonst müsst Ihr einfach mal selbst das Ublox Problem suchen und beheben (GPS.c am Ende). Der Source ist frei.
So die GPS/ACC Fusion ist fertig und funktioniert. Bisher konnte ich nur Poshold testen, das läuft geil. RTH sollte aber auch funktionieren. Im GPS Code habe ich diverse Initialisierungsprobleme behoben, die ggf. 0-Koordinaten geliefert haben - und damit einen rasanten Abflug nach Westen. Die GPS Routine wird jetzt bei jedem Durchlauf aufgerufen und regelt schnell und feinstufig. Bei meinem letzten Testflug hatte ich das gps_ins_cf = 0.995, das ist schon sehr hoch. Dieser Wert ist auch im compilierten Hex voreingestellt. Wenn er zu hoch sein sollte, könnt ihr ihn erst auf gps_ins_cf = 0.900 herunter nehmen, und euch dann hocharbeiten. GPS INS ist also per default an, weil es läuft
.LG
Rob
Moin zusammen,
finds klasse, was ihr hier (und allen voran Roberto) leistet. Nachdem ich meinen Kopter letztes Jahr unauffindbar im Feld versenkt hab, hab ich mir letzten Montag die Teile für einen neuen bestellt. Rahmen und Motoren sind schon da, jetzt fehlen nur noch Naze und Regler. Mal sehen wann die Sachen ankommen. Bin sehr gespannt, wie das Teil fliegt
Bis dahin werde ich mich mal in den Code einarbeiten und kann dann vielleicht auch das ein oder andere beitragen
An welchen Stellen gibt es denn im Moment noch Optimierungsbedarf, hab ein wenig den Überblick verloren in der letzten Zeit, ihr seid zu schnell
Gruß,
/photos
finds klasse, was ihr hier (und allen voran Roberto) leistet. Nachdem ich meinen Kopter letztes Jahr unauffindbar im Feld versenkt hab, hab ich mir letzten Montag die Teile für einen neuen bestellt. Rahmen und Motoren sind schon da, jetzt fehlen nur noch Naze und Regler. Mal sehen wann die Sachen ankommen. Bin sehr gespannt, wie das Teil fliegt
Bis dahin werde ich mich mal in den Code einarbeiten und kann dann vielleicht auch das ein oder andere beitragen
An welchen Stellen gibt es denn im Moment noch Optimierungsbedarf, hab ein wenig den Überblick verloren in der letzten Zeit, ihr seid zu schnell
Gruß,
/photos
@slashphotos: Danke!! Und schön, dass Du mit einsteigst!
Probleme gibt es noch wohl bei der Ublox Initialisierung, vielleicht sollte da ein Delay rein, oder vielleicht sollte man das Senden des Konfigurationsblocks abschaltbar machen. So wie ich das verstehe, gibt es verschiedene ubloxe. Wenn man alles mit dem ublox center richtig eingestellt hat und im ublox gespeichert hat, ist das Überschreiben mit diesem "Block" wahrscheinlich kontraproduktiv? APM und Mwii machen das, aber das muss nichts heissen. Ich werde mal die delays und den "Block" nochmal mit dem aktuellen APM und mwii und eosbandi abgleichen, vielleicht liegt da der Hund begraben.
Der MSBaro Treiber braucht m.E immer noch eine Überarbeitung im Bereich I2C Initialisierung, als Interimslösung schicke ich den MS Baro nach dem Einschalten zig mal in den Reset. Komischerweise funktioniert der BMP Treiber problemfrei, obwohl gleiches Strickmuster.
cGiesens, Erweiterungen sind auch noch nicht drin, ich wollte erstmal die GPS Baustelle beackern.
LG
Rob
Probleme gibt es noch wohl bei der Ublox Initialisierung, vielleicht sollte da ein Delay rein, oder vielleicht sollte man das Senden des Konfigurationsblocks abschaltbar machen. So wie ich das verstehe, gibt es verschiedene ubloxe. Wenn man alles mit dem ublox center richtig eingestellt hat und im ublox gespeichert hat, ist das Überschreiben mit diesem "Block" wahrscheinlich kontraproduktiv? APM und Mwii machen das, aber das muss nichts heissen. Ich werde mal die delays und den "Block" nochmal mit dem aktuellen APM und mwii und eosbandi abgleichen, vielleicht liegt da der Hund begraben.
Der MSBaro Treiber braucht m.E immer noch eine Überarbeitung im Bereich I2C Initialisierung, als Interimslösung schicke ich den MS Baro nach dem Einschalten zig mal in den Reset. Komischerweise funktioniert der BMP Treiber problemfrei, obwohl gleiches Strickmuster.
cGiesens, Erweiterungen sind auch noch nicht drin, ich wollte erstmal die GPS Baustelle beackern.
LG
Rob
Hi, Carsten!
Vielleicht kannst Du mit dem Ublox mal das probieren, was ich damal mit dem MS Baro gemacht habe.
1.: Naze starten.
2.: GPS macht Probleme (bei mir ms zählt die Höhe hoch)
3.: Mit terminal Prg connecten "#" und exit, naze geht in den Soft reset.
4.: Ms Baro ist dann geheilt, vielleicht auch das Ublox?
Vielleicht ist es auch ein Problem in \lib\CMSIS\CM3\DeviceSupport\ST\STM32F10x\ und meinem Compiler? Das MS Baro Verhalten ist auf jeden Fall merkwürdig.
LG
Rob
Edit: "Klasse finde ich den ToDo am Ende vom Init" hat da TC wieder ein F-Wort geschrieben?
OMG jetzt habe ich es gesehen:
Vielleicht kannst Du mit dem Ublox mal das probieren, was ich damal mit dem MS Baro gemacht habe.
1.: Naze starten.
2.: GPS macht Probleme (bei mir ms zählt die Höhe hoch)
3.: Mit terminal Prg connecten "#" und exit, naze geht in den Soft reset.
4.: Ms Baro ist dann geheilt, vielleicht auch das Ublox?
Vielleicht ist es auch ein Problem in \lib\CMSIS\CM3\DeviceSupport\ST\STM32F10x\ und meinem Compiler? Das MS Baro Verhalten ist auf jeden Fall merkwürdig.
LG
Rob
Edit: "Klasse finde ich den ToDo am Ende vom Init" hat da TC wieder ein F-Wort geschrieben?
OMG jetzt habe ich es gesehen:
Code:
uint16_t i2cGetErrorCounter(void)
{
// TODO maybe fix this, but since this is test code, doesn't matter.
....
Zuletzt bearbeitet:
Also wenn ich das richtig sehe, ist der ublox Initialisierungsblock von irgendwoher, vielleicht sollte man mal überprüfen, was genau da eigentlich für Befehle gesendet werden. Guck ich mir nach meiner Klausur am Mittwoch mal an. Das Datenblatt ist ja irgendwie nicht sonderlich übersichtlich
Theoretisch kann man ja die Konfiguration auslesen und sie nur dann überschreiben, wenn da Blödsinn drinsteht. Aber wie erkennt man sowas?
Ich seh schon, damit kann man sich länger beschäftigen, schön
Wenn ich die I2C-Routinen richtig verstehe, wird im Moment nicht auf das ACK vom Baro gewartet, oder übersehe ich das. Könnte das Reset-Problem lösen. Reset senden, auf ACK warten, falls ACK nach x Versuchen nicht da -> Reset, sonst weiter im Code.
Gruß,
/photos
Theoretisch kann man ja die Konfiguration auslesen und sie nur dann überschreiben, wenn da Blödsinn drinsteht. Aber wie erkennt man sowas?
Ich seh schon, damit kann man sich länger beschäftigen, schön
Wenn ich die I2C-Routinen richtig verstehe, wird im Moment nicht auf das ACK vom Baro gewartet, oder übersehe ich das. Könnte das Reset-Problem lösen. Reset senden, auf ACK warten, falls ACK nach x Versuchen nicht da -> Reset, sonst weiter im Code.
Gruß,
/photos
Das wäre SUPER, wenn Du das Problem lösen könntest!
@Carsten: Vielleicht ist das wirklich so eine 5V Sache bei Dir, wie Rosewhite meinte?
@Mike@Jingei: Euer Ublox läuft, oder macht das auch zicken? Hat das vielleicht eine andere Hardware/FW Revision als die Problemfälle? Neu muss vielleicht nicht unbedingt besser sein.
LG
Rob
@Carsten: Vielleicht ist das wirklich so eine 5V Sache bei Dir, wie Rosewhite meinte?
@Mike@Jingei: Euer Ublox läuft, oder macht das auch zicken? Hat das vielleicht eine andere Hardware/FW Revision als die Problemfälle? Neu muss vielleicht nicht unbedingt besser sein.
LG
Rob
J
meins läuft generell, wird halt manchmal initialisiert und manchmal scheinbar nicht
hatte ich samstag - akku dran... eeeewig auf sats gewartet... nix... nach dem 3. oder 4. akku anstecken (und 2 flügen zwischendurch) warn auf einmal nach "normaler" zeit satelliten da und es blinkerte die rote LED entsprechend (dann ging auch das pos hold wie schon beschrieben - also es ging mal und mal wollte er sonstwo hin - aber das hast ja mit 08 behoben...)
edit: es ist ein crius CN-06 V2.0
hatte ich samstag - akku dran... eeeewig auf sats gewartet... nix... nach dem 3. oder 4. akku anstecken (und 2 flügen zwischendurch) warn auf einmal nach "normaler" zeit satelliten da und es blinkerte die rote LED entsprechend (dann ging auch das pos hold wie schon beschrieben - also es ging mal und mal wollte er sonstwo hin - aber das hast ja mit 08 behoben...)
edit: es ist ein crius CN-06 V2.0
@ slashphotos: Das wäre wirklich nett, weil ich kann den ms code nicht mehr sehen...
@Jingej:
Schau mal bei gps.c am Anfang, da steht:
Das delay steht auf 1s (1000ms) vielleicht muss man das für manche ublox hochdrehen? 2Sek? Das Timeout verkürzt sich dann auch, kann man aber auch umdrehen, also z.B so
@Jingej:
Schau mal bei gps.c am Anfang, da steht:
Code:
...
void gpsInit(uint32_t baudrate) // Called in Main
{
uint8_t i;
uint32_t timeout;
GPS_set_pids();
timeout = micros()+10000000; // 10 sec timeout
GPS_Present = 0;
delay(1000); // let it init
while (GPS_Present == 0){ // Repeat while no GPS Data
if (micros()>timeout) break;
....
Code:
...
void gpsInit(uint32_t baudrate) // Called in Main
{
uint8_t i;
uint32_t timeout;
GPS_set_pids();
GPS_Present = 0;
delay(2000); // let it init
timeout = micros()+10000000; // 10 sec timeout
while (GPS_Present == 0){ // Repeat while no GPS Data
if (micros()>timeout) break;
....
Zuletzt bearbeitet:
Bei mir das selbe, muß erst wieder ausschalten und neu starten dann gehts.
Kann auch die Aussage von JinGej bestätigen!
Nach jedem Neustart anderes Scenario.
4 Sat/ 10Sat/ 6Sat/9Sat 4x gestartet.
Nachdem ich mir das in der Map angeschaut habe, siehts so aus wie JinGej sagte.
1 x funktionierts gut (360° Drehung alles OK), beim nächsten Versuch haut er beim gieren plötzlich ab, oder er macht einfach so nen Tourirundflug.
Unabhängig von der Anzahl der Sat.
In der Luft das selbe Spiel wie in der Wohnung am Rechner.
Ich denke irgendwas liegt da mit der Initialisierung noch im argen.
Am schlechtesten ist es nach dem ersten einschalten, dann wirds immer besser.
Kann das noch jemand bestätigen?
Das Haus ist ca. 20m lang.
Kann auch die Aussage von JinGej bestätigen!
Nach jedem Neustart anderes Scenario.
4 Sat/ 10Sat/ 6Sat/9Sat 4x gestartet.
Nachdem ich mir das in der Map angeschaut habe, siehts so aus wie JinGej sagte.
1 x funktionierts gut (360° Drehung alles OK), beim nächsten Versuch haut er beim gieren plötzlich ab, oder er macht einfach so nen Tourirundflug.
Unabhängig von der Anzahl der Sat.
In der Luft das selbe Spiel wie in der Wohnung am Rechner.
Ich denke irgendwas liegt da mit der Initialisierung noch im argen.
Am schlechtesten ist es nach dem ersten einschalten, dann wirds immer besser.
Kann das noch jemand bestätigen?
Das Haus ist ca. 20m lang.
Zuletzt bearbeitet:
- Status
