Baseflight aka multiwii port to stm32

Post Reply
crazyal
Posts: 84
Joined: Tue Sep 04, 2012 11:25 pm

Re: Baseflight aka multiwii port to stm32

Post by crazyal »

My guess is that, the changes I suggested are all that's needed to make the pid time independent, I'll probably have time to test it this weekend.
Basically what you do with github is, go to the baseflight page and click the fork button on the top right, this will create a baseflight branch in your github account.
The next step is to use the github-windows-client and commit your stuff. This way github will show all the changes you made to the code.
If you have any questions feel free to join us on the #multiwii irc channel on freenode :)
Last edited by crazyal on Fri Feb 15, 2013 12:08 am, edited 1 time in total.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

github is pure sh** i will not waste time on this anymore. Using sources and picking good stuff is much better for me.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

yeah, git is fucking horrible, but the biggest problem with your patches is they're a shitfest of copypaste from all over the place, disregarding coding style, indentation, organization, etc. So it's nearly impossible to see what you added or what you changed or even changes between different versions.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

:lol: The shitfest goes on :lol:

I know i am terrible person :). I will give (sh)github another try anyway. If you load it into eclipse you can do some autoformat for the indentation. With this little program http://www.componentsoftware.com/products/csdiff/ it is really easy to see the changes.
BTW: I upload here the actual code (also on github) wich is improved for gps precision, wich was missing in original apm/mwii/bf versions. It is necessary to increase the precision to get the acc/gps CF running. Have a look at the gps.c, there is the main difference.
To get better benefit of the acc gps fusion the PH controller must be decoupled from the serial readout/gps data available.

Cheers Kraut Rob
Attachments
Harakiri07dHEX.zip
(68.78 KiB) Downloaded 2462 times
Harakiri07dSource.zip
ACC GPS Fusion is disabled. To enable it set gps_ins_cf to some value except 0. Start with 0.5 (max: 0.999) and you will see a smoother GPS response.
(117.57 KiB) Downloaded 2527 times

crazyal
Posts: 84
Joined: Tue Sep 04, 2012 11:25 pm

Re: Baseflight aka multiwii port to stm32

Post by crazyal »

yeah it can be a problem if you change whitespaces, github doesn't ignore that...
regarding indentation, you should set your editor not to use tabs, but 4 whitespaces instead. I think that's default in baseflight.
I'll probably try your stuff on my copter today. I will let you know how it went ;)
*edit:
I attached your now hopefully properly indented code, so you see what it should look like. another possibility is to use gnu indent with the parameters "indent -kr -nut -l400"
I also moved some variable declarations which caused compile errors.
Attachments
Harakiri7Dindented+pidchange.zip
(116.56 KiB) Downloaded 2468 times
Last edited by crazyal on Fri Feb 15, 2013 4:35 pm, edited 2 times in total.

fiendie
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: Baseflight aka multiwii port to stm32

Post by fiendie »

Crashpilot1000 wrote:github is pure sh** i will not waste time on this anymore. Using sources and picking good stuff is much better for me.

Releasing a zipped pile of code is better?
Like dongs said: One can't even tell what YOU changed let alone where you pulled it from.

Github has its flaws but it's almost perfect for this kind of scenario.

Do what crazyal suggested and then read up on how to use git properly ;)
http://git-scm.com/book

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

@fiendie: Then take my zips and put them in github and you see the changes, right? So do it yourself. I just publish code made for me, perhaps others can use it or benefit from it.

@crazyal: The weather here is too bad for a nice test. I would like to know how the gps stuff works now. I was just able to do a short test in the backyard. Perhaps you have the chance to give the gps_ins_cf a run?
Thank you for aligning the code!

Greetings
Kraut Rob

crazyal
Posts: 84
Joined: Tue Sep 04, 2012 11:25 pm

Re: Baseflight aka multiwii port to stm32

Post by crazyal »

I just tested your software on my copter and my changes to the pid regulator.
So far the copter flies well, but with the bmp085 I still don't get a decent althold and for pos hold(1-2m fluctuations).
And I also experienced the copter dropping down when activating althold, this is probably due to the temperature change going outside. The acc tends to change offsets when the temperature changes, in my branch I used this "fix" https://github.com/luggi/baseflight/com ... 9f4#L3L436 it measures earths acceleration until takeoff and compensates for that temperature drift you can experience in winter, when you calibarate your acc inside and go outside flying. I know it probably would be better to calibrate the acc every time, but that's tiresome and you need an even surface.
Next issue is, the copter doesn't disarm when it's in althold mode, this could be fatal if it crashes or hits something..
(don't know if intended or bug)
I couldn't really test gps, somehow with the bad weather I didn't get a decent fix, will try again some other time.
Another thing I noticed is, when I look at the cycletime in the gui, there are fluctuations from 2500µs to 3500µs,
with baseflight it's way more stable. (2900µs-3100µs max)

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

Hi! Thank you very much for your feedback! crazyal!
When you pull down the thr stick in althold completely, you trigger the autolandfunction. It will disarm the copter when motors run 3sec on idle speed. So it is a feature and yes it might be dangerous in the wrong hands. I really love it that way, in the meantime i just do autolandings, they are so smooth. The BMP gets the job not so good done than the ms5611 of course. The weather keeps me from gps testing as well :(. An improved acc calibration might be beneficial in the future.
The cycletime is more jumpy than in mwii because the baro/altholdstuff is done every time.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

DAMN, THE GPS INS IS WORKING NOW! I will post the code later, still fiddeling with some variables.

ABL
Posts: 72
Joined: Tue Dec 25, 2012 12:12 pm
Location: Lithuania

Re: Baseflight aka multiwii port to stm32

Post by ABL »

You probably wanted to say "commit to GIT" instead of "post the code"? :P

User avatar
mr.sneezy
Posts: 109
Joined: Sat Jan 12, 2013 12:00 pm
Location: Adelaide, Australia

Re: Baseflight aka multiwii port to stm32

Post by mr.sneezy »

Crashpilot1000 wrote:DAMN, THE GPS INS IS WORKING NOW! I will post the code later, still fiddeling with some variables.


Hey Rob, what's the difference in the GPS usage between your code and the last one of TC's ?
The reason I ask is I now have the GPS working with Baseflight, and am fitting a mag sensor this week sometime. I'd like use RTH to avoid the embarrassment of landing out (again) when visibility is bad.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

GPS INS D O N E - Harakiri08

Post by Crashpilot1000 »

mr.sneezy: I haven't flown the original TC/Mwii stuff.

Hi!

In this version the GPS/ACC integration works nicely. Since i reworked the gps code a great deal (found some errors etc) it seems like i introduced an error in the ublox initialization/support. Since i own just an mtk 3329 with 3drobotics 1.9 FW i can not fix it so find the problem on your own, if you want. How does the GPS INS work?
1.: Get good Mag readings as fast as possible (is done every cycle now)
2.: Get prefiltered ACC values and rotate them according to the mag to North/East accelerations and sum them up to get cm/s. So North and East speed.
3.: Get GPS positions/filter them if necessary (below 7 sats on mtk) and derieve cm/s from them. Now correct acc values by a "complementary filter" factor with gps data. Now feedback the corrected acc data to the gps loop, wich runs now on every cycle. CM/S is feed back and a newly generated LAT/LON datapair calculated from the ins/gps speed. That is something like a leadfilter deluxe.
4.: Be happy

The current CF factor in the hexfile is: gps_ins_cf = 0.995 . It may be a little high, so you might want to reduce it to 0.9. A value of 0 disables GPS INS.
Don't Github me or scream about my coding style, just take it or leave it. I am no programmer.
Maybe this can be also done on poor arduino multiwii but only with severe cycletimeincrease.

Cheers
Kraut Rob
Attachments
Harakiri08Source.zip
(117.6 KiB) Downloaded 2558 times
Harakiri08HEX.zip
(69.09 KiB) Downloaded 2524 times
Last edited by Crashpilot1000 on Mon Feb 18, 2013 6:58 am, edited 6 times in total.

Gimbal
Posts: 146
Joined: Tue Jul 24, 2012 7:14 pm
Location: Sweden

Re: Baseflight aka multiwii port to stm32

Post by Gimbal »

thnx mate, appreciate it ;-)

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

@Gimbal: Thanks, you are welcome! I think, this is the first time of a working gps ins on a lowcost platform. By submitting this code here i want to push things ahead, perhaps others will pick up this stuff and improve it.

User avatar
mr.sneezy
Posts: 109
Joined: Sat Jan 12, 2013 12:00 pm
Location: Adelaide, Australia

Re: GPS INS D O N E - Harakiri08

Post by mr.sneezy »

Crashpilot1000 wrote:mr.sneezy: I haven't flown the original TC/Mwii stuff.
Hi!
In this version the GPS/ACC integration works nicely.
Cheers
Kraut Rob

Hi Rob,

Sounds like what you've done is impressive, although I'm not up with the subject enough to be any sort of judge of that. I'm just glad your happy to share your successes and post HEX files for guys like me to try.

A couple of questions if I can stretch your patience a bit more.

I have a MT3329 GPS module on my quad (an FMP04 actually). I flashed it recently from the OEM firmware to what I think was labelled as version 1.6 from the Arducopter site.
In your opinion, could I benefit from the version you use (3DRobotics 1.9) as well, and does it loose any features I might need for the regular Baseflight builds (that you know of) ?

Also , will your version firmware for the flight board support what is effectively a Naze32 Ver2 platform (a FF 1.31 board with BMP085 and now mag sensor as well) ?

Thanks,
Martin

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

Hi, mr sneezy!

I am currently using this board http://abusemark.com/store/index.php?ma ... 3560af23c9 and i have an older one with bmp baro that also works. The original FW just understood nmea or ublox. So the benefit with mtk fw 1.9 just comes with this version, because it understands the binary protocol of 1.9 (set gps_type = 3 /// GPS_NMEA = 0 (default), GPS_UBLOX = 1, GPS_MTK16 = 2, GPS_MTK19 = 3 ) The 1.9 FW for mtk is highly recommended see this post: http://diydrones.com/xn/detail/705844:Comment:1131611. When selecting set gps_type = 3 the mtk is configured automatically (with a timeout of 10secs) so you don't have to set a baudrate, just make shure that it is connected the right way with rx/tx switched.
Besides that i think i found the problem with ublox and my code. Some reported that ublox sometimes works, well it seems that the gps initialization delay is to short by 200ms. The APM waits 1200ms and I wait 1000ms for the gps to initialize. I would suggest to set the "delay(1000);" in line 42 in gps.c of my version to 2000 to adress this ublox problem.

Cheers
Kraut Rob
Attachments
Harakiri08 - 2SekGPSiniDelay.zip
(68.98 KiB) Downloaded 2510 times

User avatar
mr.sneezy
Posts: 109
Joined: Sat Jan 12, 2013 12:00 pm
Location: Adelaide, Australia

Re: Baseflight aka multiwii port to stm32

Post by mr.sneezy »

Hi Rob,

I read the whole GPS thread. Interesting testing. I see that V1.9 firmware makes quite a step improvement.
Actually, I also have a uBlox NEO-6M module I could use. Which would you suggest I should use (given I can reflash the MTK easily enough) ?

One other question you might be able to answer. If I reflash the MTK to V1.9, do you think will it still work with TC's Baseflight MTK type GPS setting, or only with your version ?

Cheers,
Martin

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

ublox >>>> mtk any day.
mtk is cheap arducopter-sponsored crap.

Lapino
Posts: 84
Joined: Tue Aug 16, 2011 10:01 am

AW: Baseflight aka multiwii port to stm32

Post by Lapino »

Hi TC,
do I have to upload or configure the ublox neo6m prior to hooking it up to the naze or is it done automatically?
It's there something else to consider else than the connecting to the right pin or crossing tx/rx?

Thanks in advance ;)

Gimbal
Posts: 146
Joined: Tue Jul 24, 2012 7:14 pm
Location: Sweden

Re: Baseflight aka multiwii port to stm32

Post by Gimbal »

hm TC I bought myn from PV-Electronics GB don't think they are bagging with rducopter, have a box of em and I'm quite happy with it
, uBlox r a bit better but here in Scandinavia the sky is clearer to so it makes no difference ;-)

http://www.pvelectronics.co.uk/index.ph ... ucts_id=64 /// 17:95£

User avatar
mr.sneezy
Posts: 109
Joined: Sat Jan 12, 2013 12:00 pm
Location: Adelaide, Australia

Re: AW: Baseflight aka multiwii port to stm32

Post by mr.sneezy »

Lapino wrote:Hi TC,
do I have to upload or configure the ublox neo6m prior to hooking it up to the naze or is it done automatically?
It's there something else to consider else than the connecting to the right pin or crossing tx/rx?

Thanks in advance ;)
To save TC's code entry finger :)
I think you just 'set' the GPS_type in the CLI terminal like when you set the baud rate. I asked a very similar question a month ago. Once the type number is set the Naze32 should initialize the uBlox correctly for whatever way TC's uses it.

Martin

Lapino
Posts: 84
Joined: Tue Aug 16, 2011 10:01 am

AW: Baseflight aka multiwii port to stm32

Post by Lapino »

Ok thank you very much ;)

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

Hehe, I FU**ED it up!

The gps-ins core still has a big logical error, i am currently fixing it, right now it is a better lpf with a little acc influence... stand by....
Cheers
Kraut Rob

Gimbal
Posts: 146
Joined: Tue Jul 24, 2012 7:14 pm
Location: Sweden

Re: Baseflight aka multiwii port to stm32

Post by Gimbal »

think I've got it but better safe than sorry, going to use this setup:
PPM
Y6
GPS
Bluetooth
Cam Gimbal
Sonar
so question are where to connect it ?

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Harakiri8b GPS INS Test Nr.2 :)

Post by Crashpilot1000 »

@Gimbal: Don't connect the sonar, it is not supported and of no use anyway, Autolanding is perfect with harakiris anyway without sonar. (For the rest: RTFM!)

So, i reworked the GPS INS part completely and it SHOULD work better now. There still have to be some factors figured out to make it actually usable but the code looks very ok to me now.

gps_ins_vel = 0.700 [0-1.0] This is the most important factor. The higher the value (max 1.0) the HIGHER the acc influence is and the lower is the GPS correction on acc measured speed.

gps_ins_pos = 0.350 [0-1.0] The LOWER this value is (min: 0) the higher is the influence of the acc for getting absolute GPS Position. Because the acc position is gathered by acc speed assumptions, it is dependent on gps_ins_vel. The HIGHER this value is, the more the GPS position corrects the acc position estimation

gps_acc_lpf = 2 [1-10] Is the acc lowpassfilter for the acc/gps integration. It is compareable to the lpf factor for accz/althold integration there it is 10. But 10 is too much filtering for position, so you can configure it here. A value of 1 disables the filtering 10 is too much in my opinion.

The ublox support is also reworked.
gps_type = 0 [GPS_NMEA = 0, GPS_UBLOX = 1, GPS_MTK16 = 2, GPS_MTK19 = 3, GPS_UBLOX_DUMB = 4]

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. This mode just parses the ublox binary output)

So with type 4 you will have to/can configure ublox with the ublox center on your own. It will just parse the binary output (not nmea, thats mode 0).
The INS Code accepts GPS data at the rates: 4Hz, 5Hz and 10Hz.

Recommended setting for GPS (if manual setting is desired/required):
Stay away from 10Hz with current mtk/ublox GPS, they screw up! Stay away from NMEA - if possible.
Use 5HZ binary protocol at 57K Baud (57600).
If you use MTK3339 in crap NMEA mode, use a 5Hz FW. The advertised 10Hz stuff simply sucks, it is just marketing. 10Hz will loose GPS precision, plus you loose the last digit of precision with NMEA mode anyway. 10Hz maybe beneficial with the old mwii approach (and BF up to this version) because the gps stuff was just executed when new gps data arrived. That gave twice the execution time and may have things look smoother. With this harakiri8b the GPS stuff is done all the time, so it is smooth anyway. When new gps data arrive they are taken to correct acc assumptions wich feed the navigation continiously.

Warning: When doing a RTH/RTL this version will climb to 20m, if it was lower than that. It will not descent to 20m when RTH was engaged at 30m etc. This can be adjusted with the parameter: gps_rtl_minhight = 20 [0-200]
It will do an autolanding when RTH is done.

Have fun testing out, looking at the code etc...

Cheers
Kraut Rob

EDIT:
Hehe, i just did a test flight and found that my default parameters are not ok, so i set them both to 0.5 to have a starting point with default gps pids - and bingo! Very nice for the first test! gps_acc_lpf was turned off with a value of 1. So it works, it's a parameter job now :) . I would suggest setting/keeping gps_ins_pos to 0.5 and start fiddeling with gps_ins_vel starting with 0.5.
Attachments
Harakiri8bSourceShort.zip
(118.57 KiB) Downloaded 2559 times
Harakiri8bHEX.zip
(69.3 KiB) Downloaded 2454 times

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

@TC:
The supported Acc are all set to 8G in mwii/bf. What is your experience with acc experiments? Are 8G necessary for the level mode or is maybe 4G also ok? I just ask because i want to increase precision of motionestimation. I think there are several ways to achive that on naze.
1.: Set detected acc to higher resolution i.e 4G
2.: Read out detected acc 2 times with different resolution i.E 8G and 2 or 4G
3.: Turn on the secondary acc with higher resolution (2G?) and read it out in parallel with the main one and "CF" the result together?
Will the change of precision help, or just lead to more jittery and useless data? Do you, or anyone else have data/experience on that?

Cheers
Kraut Rob

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

I've been meaning to look at acc shit, especially in mpu6k for quite a while now.
I have a feeling its wrong because I initially only tested it with the really old revision that had half acc resolution or something.
also, we have this to re-add:

Code: Select all

    /* Check product revision. */
    if (i2c_read(st.hw->addr, st.reg->accel_offs, 6, data))
        return -1;
    rev = ((data[5] & 0x01) << 2) | ((data[3] & 0x01) << 1) |
        (data[1] & 0x01);

    if (rev) {
        /* Congrats, these parts are better. */
        if (rev == 1)
            st.chip_cfg.accel_half = 1;
        else if (rev == 2)
            st.chip_cfg.accel_half = 0;
        else {
            log_e("Unsupported software product rev %d.\n", rev);
            return -1;
        }
    } else {
        if (i2c_read(st.hw->addr, st.reg->prod_id, 1, data))
            return -1;
        rev = data[0] & 0x0F;
        if (!rev) {
            log_e("Product ID read as 0 indicates device is either "
                "incompatible or an MPU3050.\n");
            return -1;
        } else if (rev == 4) {
            log_i("Half sensitivity part found.\n");
            st.chip_cfg.accel_half = 1;
        } else
            st.chip_cfg.accel_half = 0;
    }

hinkel
Posts: 109
Joined: Sun Sep 09, 2012 7:24 am

Re: Baseflight aka multiwii port to stm32

Post by hinkel »

Hi timecop !

i flashed Naze32 rev4 with baseflight R276, set acc_hardware=2 and set mpu6050_scale=1
now acc z in Multiwiiconfg is on 512 (befor 1000 with R263),
my question which rev is my mpu6050 ?
and is mpu6050_scale=1 OK ?
or is this overwrite from Software ?
or must be set to another constant ?

Greetings
hinkel

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Scale is no longer needed. 512 is correct value (256 on very old revisions).
Please re-calibrate acc after this.
I will remove mpu6050_scale var in next patch.

hinkel
Posts: 109
Joined: Sun Sep 09, 2012 7:24 am

Re: Baseflight aka multiwii port to stm32

Post by hinkel »

So old mpu6050 have a value 256 ?

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

It might, but I don't remember having any with wrong scalefactor.
If you see 512, you're fine.

hinkel
Posts: 109
Joined: Sun Sep 09, 2012 7:24 am

Re: Harakiri8b GPS INS Test Nr.2 :)

Post by hinkel »

Crashpilot1000 wrote:

The ublox support is also reworked.
gps_type = 0 [GPS_NMEA = 0, GPS_UBLOX = 1, GPS_MTK16 = 2, GPS_MTK19 = 3, GPS_UBLOX_DUMB = 4]


gps_type = 1 GPS_UBLOX (does autoconfig, sends the "block", you set baudrate)


gps_type = 4 GPS_UBLOX_DUMB (You have to set baudrate, You have to configure ublox with ublox center on your own. This mode just parses the ublox binary output)

So with type 4 you will have to/can configure ublox with the ublox center on your own. It will just parse the binary output (not nmea, thats mode 0).




Hi Crashpilot1000 !

type 1 or type 4 ?

Which is the best methode and which is the advantage of type 4 ?
I did not well understand what it brings ? :?:
or is autoconfig software type1 not complet or failed ?

Greetings
hinkel

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

Since i don't own an ublox it is hard to say what is the best for you. When selecting type 1 the ublox is autoconfigured with the configurationblock of multiwii/bf. When selecting type 4 it will just parse the ublox binary protocol. You will have to set parameters with the ublox center yourself (select binary protocol, Hz, baudrate etc) or use config files like these: http://code.google.com/p/ardupilot-mega ... 253Dclosed http://www.multi-rotor.co.uk/index.php?topic=1177.0
Cheers Kraut Rob

hinkel
Posts: 109
Joined: Sun Sep 09, 2012 7:24 am

Re: Baseflight aka multiwii port to stm32

Post by hinkel »

thanks for your reply Crashpilot1000 !

the type 4 seem to be hazardous for me, i prefer the autoconfig !

Greetings
hinkel

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

@TC:
Sincerely i didn't understand your last post with the MPU stuff. I loaded up your current version of the mpu6050 driver - now i get it. Holy sh**! Thank you VERY much for doing so much research on that! What i gather from your code is that invense really screwed that up, and finding a proper detection sequence must have been a nightmare.
Thanks!
Kraut Rob

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Yeah, the problem is it wasn't documented anywhere.
It was known that some revision of MPUs had half-scale accel, but determining WHAT revision it was is not disclosed in "public" docs.
So when Invensense released eMPL few weeks ago, I checked there, and they have the proper revision detection.

What this means is I will remove mpu6050_scale variable from cli, and I will add some text under 'status' command to report mpu6050 revision. Technically, as far as I know, I haven't made any afroboards with old mpu6k, so the only people seeing it might be people who soldered their own 6050 on top of a freeflight, or maybe those german "clones" :)

Now you can try playing with acc settings other than 8g and not have to worry about scalefactor.

electro
Posts: 2
Joined: Mon Feb 18, 2013 8:10 am

Re: Baseflight aka multiwii port to stm32

Post by electro »

TC I hope you have made an error in your latest code as my mpu6050 comes up as an "o" and I have only had the board 2 days!

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Yeah, I did.
Oops. the meaning is reversed from commit message. I'll change it to something else in next one.

jy0933
Posts: 180
Joined: Wed Jun 27, 2012 4:24 pm

Re: Baseflight aka multiwii port to stm32

Post by jy0933 »

I wonder .... if I use it on FF1.31(the white board) where should I connect sonar (sr 04) to? cppm is enabled

thanks

hinkel
Posts: 109
Joined: Sun Sep 09, 2012 7:24 am

Re: Baseflight aka multiwii port to stm32

Post by 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

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by 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
Last edited by Crashpilot1000 on Sun Feb 24, 2013 10:45 am, edited 1 time in total.

jy0933
Posts: 180
Joined: Wed Jun 27, 2012 4:24 pm

Re: Baseflight aka multiwii port to stm32

Post by jy0933 »

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

:(

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Sonar is useless.

hinkel
Posts: 109
Joined: Sun Sep 09, 2012 7:24 am

Re: Baseflight aka multiwii port to stm32

Post by 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

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by 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
Posts: 109
Joined: Sun Sep 09, 2012 7:24 am

Re: Baseflight aka multiwii port to stm32

Post by 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
Last edited by hinkel on Sun Feb 24, 2013 4:11 pm, edited 1 time in total.

fiendie
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: Baseflight aka multiwii port to stm32

Post by fiendie »

jy0933 wrote: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".

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by 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
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: Baseflight aka multiwii port to stm32

Post by fiendie »

Crashpilot1000 wrote:@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.

Post Reply