Baseflight aka multiwii port to stm32

[hinkel]

Hi Crashpilot

I test Harakiri 8b and your solution for the GPS . I arrived has a point where the quadro was very stable in GPS pos hold, the solution of the baro is good also but it seems to lose of the height after 2 or 3 minutes of flight it is variable can be the outside temperature it makes -4 °C, or the drift of the baro. RTL tested on small distance also works failsafe not tested. Between 7 and 10 sats during the test and you what are your results ?

Very good work Mr Kraut !

Greetings

hinkel

[Crashpilot1000]

@jy0933: Here you can see, where you can connect the Sonar: http://code.google.com/p/afrodevices/so ... v_hcsr04.c (line 69). But besides displaying the measured hight in some debug, it will not do anything else.

@hinkel: Thank you very much! Instead of decreasing the "G" i am currently trying to work with no hardware LPF on the mpu (currently set to 42Hz). The MS Baro stuff is still some I2C baro initialization stuff. You can test it in your room: Connect naze to the gui and you will see rising altitude. Now exit gui, enter the cli and exit the cli by typing "exit" that will also reset the naze. Now reconnect to the gui and you will see, that rising alt is gone. My attempt to the reset the baro on init a few times, seems to help a little. Normally the baro pressure is compensated by temperature on every read but when you produce wacky delta Temp it may cause problems in the first few minutes (rushing out from the house into the cold). I think there were some changes in the main/lib (not src) folder i haven't already assimilated in 8b, maybe they will fix it. It is just a tiny thing, but it's hard to find for me, because the baro readout works most of the time very well and this issue doesn't arise with the old BMP085. I will check it out with the changed files from Timecop. At least he knows this stuff .
My gps experience has also increased dramatically comparing to original mwii. PH didn't work in the backyard before at all ... I think increasing the call rate of the gps controller also helped things (APM: 25Hz-50Hz, Multiwii: 5Hz-10Hz, Naze: > 300Hz)
Did you set both factors to 0.5? Have you had a chance to fiddle with them, i know -4C is hardcore for the fingers...

Cheers Kraut Rob

[jy0933]

so basically the sonar feature does nothing at all( except the displaying measurement)

[timecop]

Sonar is useless.

[hinkel]

@ Crashpilot

gps_ins_vel = 0.5
gps_ins_pos = 0.1 seems a good value for my copter

And i play with gps_pos_p and gps_posr_p seems that your change reduces or constrain their influence .
I must say that with original timecop baseflight i had good results too !

Greetings

hinkel

[Crashpilot1000]

Thank you for sharing your experience!
Very interesting! I wouldn't have dared to lower gps_ins_pos to that value because i would have feared to loose the correction of actual GPS positions. Yes, with lowered delta time it is also expected that the influence of P is reduced, so increasing it is the way to go.
BTW are you using ublox? Because i couldn't get decent gps functions with my mtk3329 before.. .
Greets
Rob

I post here one of the core parts, to see the influence of the parameters:

Code: Select all

Real_GPS_speed[GPS_X] = (float)(Real_GPS_coord[LON] - Last_Real_GPS_coord[LON]) * MagicEarthNumber * CosLatScaleLon * gpsHz; // To rad, include Earthradius and Time 5Hz
Real_GPS_speed[GPS_Y] = (float)(Real_GPS_coord[LAT] - Last_Real_GPS_coord[LAT]) * MagicEarthNumber * gpsHz; // To rad, include Earthradius and Time
Last_Real_GPS_coord[LON] = Real_GPS_coord[LON];
Last_Real_GPS_coord[LAT] = Real_GPS_coord[LAT];
VelNorth = VelNorth * cfg.gps_ins_vel + Real_GPS_speed[GPS_Y] * (1.0f - cfg.gps_ins_vel);  // CF: GPS Correction
VelEast  = VelEast  * cfg.gps_ins_vel + Real_GPS_speed[GPS_X] * (1.0f - cfg.gps_ins_vel);  // CF: GPS Correction
GPS_coord[LAT] = GPS_coord[LAT] + cfg.gps_ins_pos * (float)(Real_GPS_coord[LAT] - GPS_coord[LAT]);
GPS_coord[LON] = GPS_coord[LON] + cfg.gps_ins_pos * (float)(Real_GPS_coord[LON] - GPS_coord[LON]);

[hinkel]

Yes Ublox with gps_type=1 in Putty no interest in gps_type=4,
eventually you can set Pesdestrian in the autoconfig i dont know if it is better, i saw a file from pm1 on github ?
How precise is your copter Gps pos hold in your test ?

Greetings
hinkel

[fiendie]

so basically the sonar feature does nothing at all( except the displaying measurement)

Take a look at Luggi's github repository: https://github.com/luggi/baseflight/tree/sonar
He implemented Sonar ALT hold.
I think his forum nick is "crazyal".

[Crashpilot1000]

@hinkel: I got it to 2m circle in my gps difficult backyard, where the original code wouldn't work at all. My other quad is equipped with apm2.0 that also fails there (mtk1.9 and 2.9.1 and 2.8.1 - with patched gps lib for mtk1.9), my dji naza does def. better (ublox) there. Currently i replaced my naza with naze - it seems crazy but the naze is the better overall option for me.

@fiendie: If sonar is implemented it is a possible point of severe failure. You can't just say "ohh i got sonar contact, that must be earth and so i correct all barovalues to that offset to 0" that will do a serious trouble when flying over a 20 m tree. Perhaps the sonar correction could be constrained to a scaled down change of targethight? For example: Sonar contact 1-5m is scaled down to 1m relative change of targethight. That could be useful when flying over water with some waves on it. The copter will keep the hight without doing a jump on every wave. Sonar is not necessary for autolanding anymore and that was its main purpose on many other copter systems.

Cheers Kraut Rob

[fiendie]

@fiendie: If sonar is implemented it is a possible point of severe failure. You can't just say "ohh i got sonar contact, that must be earth and so i correct all barovalues to that offset to 0" that will do a serious trouble when flying over a 20 m tree. Perhaps the sonar correction could be constrained to a scaled down change of targethight? For example: Sonar contact 1-5m is scaled down to 1m relative change of targethight. That could be useful when flying over water with some waves on it. The copter will keep the hight without doing a jump on every wave. Sonar is not necessary for autolanding anymore and that was its main purpose on many other copter systems.

Cheers Kraut Rob

I don't know any details of his implementation. I don't find ALT hold particularly useful at all, regardless of how it's achieved
Just wanted to note that there is example code for doing more than displaying values.

[jy0933]

so basically the sonar feature does nothing at all( except the displaying measurement)

Take a look at Luggi's github repository: https://github.com/luggi/baseflight/tree/sonar
He implemented Sonar ALT hold.
I think his forum nick is "crazyal".

cool

thanks

[Crashpilot1000]

@hinkel:

Based on your findings i set the parameters to this, and it works! I haven't expected that by giving the ACC so much authority!
gps_ins_vel = 0.9
gps_ins_pos = 0.1

I set the lpf to OFF (gps_acc_lpf = 1).

Cheers Kraut Rob

[hinkel]

@ Crashpilot

I made new test and after has good value for gps_pos_p and gps_posr_p,
I increase gps_ins_pos from 0.1 to 0.5 and the result is remarkable less than 1m
drift with 8 sats, most time no drift at all.

Greetings
hinkel

[Crashpilot1000]

NICE! I am still waiting for my ublox...

I tested the acc with differen LPF settings (recompile) - that is no good, so the default 42Hz lpf seems the way to go.
It's a pain finding the right parameters.
In the meantime i wonder if it might be useful to think/treat both parameters as one like this:
gps_ins_vel + gps_ins_pos = 1

That would reduce it to one parameter perhaps "gps_ins" [0.001 - 0.999] The greater the number the more acc you get. So
gps_ins_vel = 0.9 + gps_ins_pos = 0.1 = 1 would fit into that scheme.
In the mean time we will have to do more tests here to judge upon this. But the nice conclusion is, that this stuff actually works . I am still keen on what the apm ins will look like.
Cheers Kraut Rob

[hinkel]

@hinkel:

Based on your findings i set the parameters to this, and it works! I haven't expected that by giving the ACC so much authority!
gps_ins_vel = 0.9
gps_ins_pos = 0.1

I set the lpf to OFF (gps_acc_lpf = 1).

Cheers Kraut Rob

Hi Crashpilot!

I saw your post to late, I think starting with gps_ins_vel .._pos =0.5 is a good starting point and after play with gps_pos_p
and gps_posr_p (increase), but there are so many parameter to play with !!!

Greetings
hinkel

[Crashpilot1000]

Yes 0.5 for gps_ins_pos is always save, because you are sure to get enough correction from gps. And the "vel" should be the first value that should be tuned (in theory) because the acc can actually measure acceleration over time (=speed). So the position derieved is a function of that.

[hinkel]

@Crashpilot

Info:
during the test I set :
nav_speed_max=120
gps_wp_radius=100

Greetings
hinkel

[Crashpilot1000]

nav_speed_max=120 is a good idea! So many parameters....
gps_wp_radius=100 Is just for detection if a waypoint is reached, it is not used in position hold.

[hinkel]

gps_wp_radius=100 Is just for detection if a waypoint is reached, it is not used in position hold.

Ok, I was not sure of the influence !

[Crashpilot1000]

Thank you for helping me (and probably others) figuring/testing out stuff!!
The parameter nav_speed_max is also used just for computation of WP - navigation speed. When doing pos hold there is also a speed calculated based on the actual location error. Sorry that i mixed that up! I should always look into the code before posting stuff .....
Keep it up!!

[hinkel]

Hi Crashpilot !
I make a little change in your mw.c file to better count number of Satellites !
for 5 sats it blinks 1 time , for 6 sats it blinks 2 times , for 7 sats it blinks 3 times etc..........
and no LED fast blinking between !
I hope i don't make an Error ? I am not a programmer .(It is running on my Naze32)

REPLACE THIS somewhere in mw.c

### blinkblock = GPS_numSat;

### cnt = 150; // 1.5s Break before next flickerblock

### if (f.ANGLE_MODE || f.HORIZON_MODE) {
LD1_ON(); //LED1_ON; Crashpilot
} else {
LD1_OFF(); // Crashpilot LED1_OFF;
}


WITH THIS


### blinkblock = GPS_numSat - 4;

### cnt = 200; // 2s Break before next flickerblock

### if ( GPS_numSat <= 3) {
if(f.ANGLE_MODE || f.HORIZON_MODE ) {
LD1_ON(); //LED1_ON; Crashpilot
} else {
LD1_OFF(); // Crashpilot LED1_OFF;
}
}

Greetings
hinkel

[Crashpilot1000]

Thats a very good idea because below 5 Sats it is uninteresing anyway and boring counting all of them. I will look at the code in detail later, perhaps it is time for 8c with timecops acc scaling and the default parameters set to 0.5 and your LED idea? I would like to let "gps_wp_radius" be 200 on default, so it is easier to hit an actual waypoint. A reduction of "nav_speed_max" default (300) seems reasonable, perhaps to "200" as default. 120 seems too close to "nav_speed_min = 100".
Cheers Kraut Rob

[hinkel]

Crashpilot thank you for integrate the LED idea !

PS: gps_wp_radius or nav_speed_max values was just for your info

[Crashpilot1000]

So, here is harakiri8c.
- The GPS Code is unchanged. But the default values for gps inertial integration are set both to 0.5 to start with.
The new mpu6050 scale code from Timecop is implemented, but the scale is not shown in cli with (o)ld or (n)ew. You will notice that the acc values are 512 after calibration if you have the new revision or if it is just 255 if you have bought the crappy mpu.
- Hinkels sat-count-led-idea is implemented. Normally the "red" led shows that you are in angle or horizon mode but it also shows satnumbers by blinking them for you to count. This idea was originally from Helste . So how is that solved when two functions rival one led? When you don't have a gps nothing changes. If you have a gps the led will work as normal up to 4 sats. After 5 sats it will quit showing "i am in an acc mode" and blink down the satnumber starting with 5. So one blink are 5, 2 blinks are 6 sats....

Here is a breakdown of preconfigured and new parameters:

Code: Select all

mag_declination = 105   (You will want to change that !!!)
acc_hardware = 2 (MPU6050)
acc_lpf_factor = 100
looptime = 3000
accz_vel_cf = 0.985 (don't change)
accz_alt_cf = 0.940 (don't change)
acc_lpf_for_velocity = 10
nazedebug = 0
deadband = 10
yawdeadband = 15
maxthrottle = 1950
gps_type = 0 (crappy nmea)
gps_baudrate = 115200
gps_ins_vel = 0.500 (the higher the higher acc influence)
gps_ins_pos = 0.500 (the higher the higher the gps influence)
gps_acc_lpf = 1 (1 means off)
nav_speed_max = 200  (was 300 before)
gps_rtl_minhight = 20  (in meters)

Cheers
Kraut Rob

[mahowik]

Hi Rob!

Appreciate it! Amazing job!

Have you tried this solution on windy condition?

thx-
Alex

[Crashpilot1000]

@Mahowik: Thank you very much! But the idea was generated on basis of your thread and your althold implementation. Due to the weather i was not able to do much testing, but i expect this code to cope better with wind than the original.. Perhaps some of this code if useful for the mwii project as well?
Greets Rob

[mahowik]

I have already tried to to use acc for position hold stabilization, but only quick tests and w/o correction by gps viewtopic.php?f=8&t=2929#p29088
You solution looks full and I'm going to play with that on mega2560 board. But yes, I suppose it will be time consuming issue... so need to try... Even if cycle time will increase to 10ms I think that 100hz loop it's more than enough for still good stabilization... so tests tests tests
Also you have mentioned that "3drobotics is currently working on that". Where it's possible to look through the code from 3drobotics?

thx-
Alex

[Crashpilot1000]

Hi! You can look for that arducopter stuff here: https://github.com/diydrones/ardupilot/ ... nertialNav. I think they must be doing basically something similar than this?
Today i had the chance to test the code again and noticed some slight circeling manner. I don't think it's my mag (this time;)) but maybe there could be a slight bearingerror at play i may introduced in "GPS_distance_cm_bearing" will check it over again.
Cheers Rob

[Crashpilot1000]

@Timecop: Do you know if "double" is correctly handled on stm? I ask because on arduino double was treated as float and google couldn't really help me on that.

Cheers Rob

[timecop]

All calculations should be done using floats + "f" variants of the functions, to avoid pulling in double equivalents.
But yes, "double" type properly works, not get downgraded to float.

[hinkel]

Hi timecop !

Have you an idea how to fix the MS Baro Bug describe from Crashpilot1000 ?

Greetings
hinkel

The MS Baro stuff is still some I2C baro initialization stuff. You can test it in your room: Connect naze to the gui and you will see rising altitude. Now exit gui, enter the cli and exit the cli by typing "exit" that will also reset the naze. Now reconnect to the gui and you will see, that rising alt is gone. My attempt to the reset the baro on init a few times, seems to help a little. Normally the baro pressure is compensated by temperature on every read but when you produce wacky delta Temp it may cause problems in the first few minutes (rushing out from the house into the cold). I think there were some changes in the main/lib (not src) folder i haven't already assimilated in 8b, maybe they will fix it. It is just a tiny thing, but it's hard to find for me, because the baro readout works most of the time very well and this issue doesn't arise with the old BMP085. I will check it out with the changed files from Timecop. At least he knows this stuff .

[timecop]

Does it occur in my code? I have no idea where he copypasted that bug from

[hinkel]

Yes it occur in your code, I just try it with Baseflight and the baro value after 2 minutes begin to rise from alt 143,5 to 144,3 and it still rising. I also saw the problem in flight (Baseflight) in baro mode the copter lose height after a while.

[Crashpilot1000]

@timecop: Thank you for clearing up that "double" question! The MS barostuff still needs some attention, i am still clueless
Meanwhile i have done further fiddeling the gps code and i think it has some severe shortcomings when calculating loiter with the current approach. Much work to do ..
Cheers Kraut Rob

[Crashpilot1000]

Hi!

I reworked the gps code a little. The "doubles" are back to floats again. And i removed the slight bearingerror i introduced . That slight bearing error lead to circeling in PH, like you would see with a mag-problem. I also increased the delay on initialization of ublox, sometimes my ublox didn't understand the right baudrate. Harakiri9 will be last version with the conventional gps code. I think, I will have to rework PH and perhaps the current acc calibration.

Cheers
Kraut Rob

P.s.: I did a complete description of all new functions/parameters in German here: http://fpv-treff.de/viewtopic.php?f=18&t=1368#p20577

EDIT:
Use:
gps_ins_vel = 0
gps_ins_pos = 1
gps_acc_lpf = 10
That reduces acc usage just for the time between gps reads but works very good!
Here are 2 shabby videos from me:
http://fpv-treff.de/viewtopic.php?f=18&p=21360#p21395

[hinkel]

Hi Crashpilot !

I fly your Harakiri 9 (and read the german forum ) ,
I set gps_ins_vel = 0 and gps_ins_pos = 1 and default GPS PID.( like your advice )
I can say yes it works, but not very fine for me.
I also test gps_acc_lpf with 10 and 50 but I saw no significant result.
so I put gps_acc_lpf = 1 . I push looptime to 5000 but it was worse.
In fact I set gps_ins_vel =0.5 and gps_ins_pos =0.5 and change gps_pos_p and gps_posr_p like in Harakiri 8b and this was
for me the very best results . PH and RTH are very fine !

Greetings
hinkel

[Crashpilot1000]

@Hinkel: Thank you very much for your feedback!
Your info on the parameters is also very interesting. I would love to have a BT line and put out some inflightdata in debug to figure stuff better out....
Cheers
Kraut Rob

[mr.sneezy]

Guy's, not sure if I'm missed something, but I can't install TC's new HEX file from today. I get a message from the STM loader saying it can't use the file, and I've noticed the file size of the .HEX is 397Kb instead of around 150kb for previous versions.
I used the same 'save file as' method as previously to download the file.
Not sure where my problem lies ?

Thanks,
Martin

[lld]

Hello Crashpilot,

I tried your Harakiri9 yesterday (also I am following the progress on the German forum). Actually started with 8 version but switched to version 9.

It was VERY windy and I was using a tricopter which was quite new and a bit unknown to me. It was also not the most vibration free platform

Alt hold was working well although I would like to have the reaction to the throttle stick a bit stronger. When giving a command with the stick it takes quite while before the copter reacts.

Pos hold was so so. I did not make the last changes as suggested as I was already out on the field. Sometimes it held position within 1 meter, sometimes it was making big circles with a diameter of about 6-8 meter. If I then made a correction with the stick it held the position much better.

Return to home was working well but VERY slow.

I am not sure when I can test the settings as you proposed, but I hope next weekend.

- what can I do to make the reaction to the throttle stick a bit stronger when in alt hold mode ?
- how to increase the speed while in rth mode ?

Ro

[timecop]

Guy's, not sure if I'm missed something, but I can't install TC's new HEX file from today. I get a message from the STM loader saying it can't use the file, and I've noticed the file size of the .HEX is 397Kb instead of around 150kb for previous versions.
I used the same 'save file as' method as previously to download the file.
Not sure where my problem lies ?

Thanks,
Martin

works here - the file isn't much bigger, and googlecode reports it as correct size.
You sure you didn't rightclick the html page instead of raw hex?

[Crashpilot1000]

@lld
Hi! Thank you very much for your feedback. I know the reaction on althold relative to throttlestick middle is not so crisp but it's a compromise between BMP and MS Baro. I made no variables directly accessible to change the behaviour on purpose . But you can change the code mw.c line 860 " AltRCTimer0 = currentTime+100000;" you could reduce that value to let's say 80000 but i would leave it that way. I wanted to do it as simple as possible without an extra pid controller to maintain a certain speed. Way more confusing parameters so i took the user friendlier route of basically 2 parameters to tune (Alt P & "I") and the D is just a tiltangle correction. The downside is, it is not so crisp as it could be.
Yeah, the RTL is really slow. That is the cli parameter nav_speed_max = 200 you should increase it (was 300 before, i thought it could be too much - wrong idea) so perhaps 300 or 400 are suiting better. The "GPS_INS" parameters are still unclear, i suggest to limit them basically to the time between gps reads, but hinkel has better experience with "0.5/0.5". Here are the latest videos (2 new!) including the settings i used: http://fpv-treff.de/viewtopic.php?f=18& ... =40#p21395
Circeling can also be a symptom of motor influence on MAG, but that is nothing new, i just wanted to mention it.

Cheers
Kraut Rob

[mr.sneezy]

Guy's, not sure if I'm missed something, but I can't install TC's new HEX file from today. I get a message from the STM loader saying it can't use the file, and I've noticed the file size of the .HEX is 397Kb instead of around 150kb for previous versions.
I used the same 'save file as' method as previously to download the file.
Not sure where my problem lies ?

Thanks,
Martin

works here - the file isn't much bigger, and googlecode reports it as correct size.
You sure you didn't right click the html page instead of raw hex?

Thanks for verifying the file size for me. Yep, your right, I was trying a 'save as' on html page. Wasn't familiar with the HEX editor screen that opens up and has the 'raw' button on the right side. Got it sussed out now

[mr.sneezy]

Guy's. I've reflashed my MKT3329 gps to the V1.9 fw from 3Drobotics. I want to set Baseflight's gps_type correctly for it. Did TC add a new type for that gps fw like Crashpilots below ??

gps_type = 0 GPS_NMEA
gps_type = 1 GPS_UBLOX (does autoconfig, sends the "block", you set baudrate)
gps_type = 2 GPS_MTK16 (old MTK binary protocol, 3drob. 1.6, baud is set automatically)
gps_type = 3 GPS_MTK19 (new MTK binary protocol, 3drob. 1.9, baud is set automatically)
gps_type = 4 GPS_UBLOX_DUMB (You have to set baudrate, You have to configure ublox with ublox center on your own.

(I asked a question a few weeks ago about V.1.9 fw and it's use in Baseflight, but didn't get a response either way)

Also, is there a way to list the available gps_type values in the CLI ? (I tried ? and help etc)

Thanks again,
Martin

[timecop]

I haven't touched GPS for months since that code wasn't originally written by me anyway.
Perhaps some of these GPS changes from 2.2 will make it in once its released.

[mr.sneezy]

I haven't touched GPS for months since that code wasn't originally written by me anyway.
Perhaps some of these GPS changes from 2.2 will make it in once its released.

OK understood.
Thanks,
Martin

[timecop]

And as far as GPS_Type goes, it's here:
[code]
typedef enum {
GPS_NMEA = 0,
GPS_UBLOX,
GPS_MTK,
} GPSHardware;

[mr.sneezy]

LOL.
I found your reply and the code in the board.h file at about the same time

[mr.sneezy]

I got a bit of time to do stuff with the quad today. I swapped the GPS to the uBlox Neo-6M from the MTK3329 and set Baseflight for uBlox type.

Now that I have mag, gps and baro senors working I have a couple of questions for the guys using those here.

Is it necessary to re-calibrate the mag and acc after a firmware update ?
I ask this because it 'seems' like calibration didn't change at all between firmware updates, but I could be wrong.

Secondly. Now that I have all those sensors, how to best set the AUX switches (see image) ?
I suspect that mag should be selected all the time and baro should be selected when gps hold or gps home is selected, but can somebody confirm or deny that for me.

Maybe Crashpilot could show me what he sets up to get the best use of the sensors.
Thanks,
Martin

[hinkel]

Just a video showing Naze32 rev4 GPS Position hold with Baseflight r225 and Harakiri 9 !

http://vimeo.com/61104943

[JollyJoker]

Looks damn good. Would you mind to share your settings?

Exactly the same video made today with 8+ sattelites in view. Only harakiri9 with recommended settings.
http://www.youtube.com/watch?v=KQKLCzhovmQ

Regards Peer