Baseflight aka multiwii port to stm32

gena_g
Posts: 3
Joined: Wed Jan 30, 2013 9:29 am

Re: Baseflight aka multiwii port to stm32

Post by gena_g »

Tell me please. As the firmware r260 mode triсoptera can include Gimbal (servo_tilt).

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

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Not unless you want to use PPM input and change driver to allow more servos (well, actually, change should be minimal, but whatevers).
Too much effort otherwise.

gena_g
Posts: 3
Joined: Wed Jan 30, 2013 9:29 am

Re: Baseflight aka multiwii port to stm32

Post by gena_g »

I use the PPM-sum. And you can adjust the gimbal with cmix . The board free PWM5-PWM8. They can be used for Gimbal

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

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Right.
Feel free to contribute a patch that makes use of additionally available servos in that mode.
Its certainly doable.

whakahere
Posts: 20
Joined: Wed Jan 30, 2013 9:17 pm

Re: Baseflight aka multiwii port to stm32

Post by whakahere »

I am having a hell of a time find the looptime variable. I'm using the lastest version of baseflight and the naze32 android app. I thought it would be under sets in the cli but I can't find it in there.

I want to improve the level of my quad and from what I understand I need to increase looptime. Is it under a different name or in a different location in the app?

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

AW: Baseflight aka multiwii port to stm32

Post by Lapino »

Looptime should be in the set accessible via cli ;)
Just have a closer look at it...

whakahere
Posts: 20
Joined: Wed Jan 30, 2013 9:17 pm

Re: Baseflight aka multiwii port to stm32

Post by whakahere »

I know it can be changed by the cli ... If I could plug in my board but I built my current quad with the board sealed within the body (it's a battle style, all weather quad). This means I can't plug it in by usb. I do have access through bluetooth but for the life of me I have no idea how to access that through a mac. So I was hoping since all functions were meant to be in the app I would do all my updating through that. (no need to add to the firmware as I just need rate and level mode).

Of course I updated the lastest baseflight before putting it in.

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

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

Hi!
Currently i am implementing the new eos bandi code into my nazeproject. Due to my limited c coding abilities, i am experiencing severe problems with the new leadfilter and its' "class" definition. I always get compile errors with the class definition of the mwii gps code (http://code.google.com/p/multiwii/sourc ... 321&r=1321) what is the secret?
Cheers
Kraut Rob

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

Re: Baseflight aka multiwii port to stm32

Post by timecop »

uh, wow, why the fuck would they go back to class-based C++ failcode...
Well, just rewrite the class garbage in C and problem solved.

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

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

Hahaha actually it is arducopter gps leadfilter class "failcode" LOL !
I am too stupid to do that but i will try :)

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

Re: Baseflight aka multiwii port to stm32

Post by timecop »

i.e. class Crap { int foo; int bar; void trash(); void param(int lol); }
rewrite as
typedef struct crapStruct { int foo; int bar; } crapStruct;

crapStruct c_static_data;
c_crap_ctor(crapStruct *this) { /* init stuff */ this->foo = 42; this->bar = 10; }
c_crap_trash(crapStruct *this) { /* do crap */ print(this->foo); }
c_crap_params(crapStruct *this, int lol) { /* do stuff */ this->foo += lol; }

then use like
c_crap_ctor(&c_static_data);
c_crap_trash(&c_static_data);
c_crap_params(&c_static_data, 133);
etc.

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

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

@Timecop: Thank you very much for your info!!! I haven't looked into this subject already but meanwhile i improved BF very much.

- Althold relative to throttlestick middle with Autoland (put thr stick completely down in althold) and Disarm after Landing
- RTH with Autoland and minimal hight for Return feature
- Showing Satnumbers with red LED Blinkcode. So you know how many Sats you have while Arming (setting Homepos)
- PosHold Override. Pos hold is only engaged when you let go the stick, so you can fly around and PH is engaged. PH only possible with 7 Sats to prevent flyaway
- Failsafe: RTL and Autoland (if Baro&GPS) or just Autoland (no GPS but Baro) or the old crap (no GPS no Baro) or RTL and old crap if only GPS
- Updated/refreshed GPS code. Added binary protocol MTK16/MTK19, improved initialization (with 10sec timeout). Replaced moving average with own Spikefilter. Own MTK binary parser.
- Improved Main Pid controller with floats and dT and PT1 Element, flies more stable, you can increase roll/pitch P now.
- ESC Calibration function "feature pass" (disable for flight "feature -pass") does a Passthrough of thr channel to all esc according to copter config (default QuadX). You can Calibrate/config all your soldered ESC at once now.
The documentation is currently only available in Kraut :) but here is the link: http://fpv-community.de/showthread.php? ... post284706
I attach the files here as well, so you don't have to sign up, if you want to take a look.
Perhaps there is some useful stuff for your upcoming releases in it.

Cheers
Kraut Rob
Attachments
Harakiri06cSOURCE.zip
(115.64 KiB) Downloaded 2487 times
Harakiri6cHEX.zip
(67.7 KiB) Downloaded 2491 times
Last edited by Crashpilot1000 on Mon Feb 04, 2013 12:23 am, edited 2 times in total.

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

AW: Baseflight aka multiwii port to stm32

Post by Lapino »

Sounds nice ;)
Did anyone test it yet?
I would if I could :(

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

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Crashpilot1000 - you mean GPS works? Shock and horror.

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

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

He says it works: http://fpv-community.de/showthread.php? ... post283741

I am currently grounded by weather and hardware (motor)..

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 »

I'm a bit confused, witch software version shall i use and what GUI

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

Re: Baseflight aka multiwii port to stm32

Post by timecop »

First post of thread.

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

Re: Baseflight aka multiwii port to stm32

Post by Gimbal »

Well i hate to brake it to you Timecop, but you're not the only one contributing to this thread.
Cp witch GUI can i use together with Harakiri6c.

have a few MTK laying around i'd like to test

KR Anders

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

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Since it looks like stuff copied from -dev multiwii, I would assume whatever -dev gui is on multiwii code page.
it takes about 15 seconds to try and find out.

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

Re: Baseflight aka multiwii port to stm32

Post by Gimbal »

for the latest MW dev (from 12?? something) Win -GUI can not be used, so ther is a few diferent GIU's, shure i can make som trail n error but why not ask ? btw have em all.

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

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

Does anybody have a working mag code for the naze? Mwii stinks alot in this area.
I will try to get eos bandi's improved mag calibration to work, but has anyone a proper mag rotation routine wich works upside down as well?

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

Re: Baseflight aka multiwii port to stm32

Post by Gimbal »

thnx CP1000 for great work, trying to keep up with small successes ;-)

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

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

@Gimbal: Thank you very much!
The Harakiri6c is just a mutant of baseflight r251, so use your normal Mwii2.1 Gui!
Flash your 3329 MTK with 3drobotics 1.9FW. I don't know if there is a similar FW for MTK3339 available, otherwise you will be stuck to shabby nmea.

Cheers
Kraut Rob

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

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

Hi Timecop!

I am currently improving the MAG based on eos bandis great work in this area. But i started from the other point: the correct tiltcompensation.
When you replace the orig mwii line in Sensors

Code: Select all

heading = _atan2f(EstG.V.X * EstM.V.Z - EstG.V.Z * EstM.V.X, EstG.V.Z * EstM.V.Y - EstG.V.Y * EstM.V.Z);

with this:

Code: Select all

        #define RADX10 M_PI/1800.0f                  // 0.001745329252f
        float rollRAD = (float)angle[ROLL] * RADX10;
        float pitchRAD = -(float)angle[PITCH] * RADX10;
        float magX = EstM.A[1];                         // Swap X/Y
        float magY = EstM.A[0];                         // Swap X/Y
        float magZ = EstM.A[2];
        float cr = cosf(rollRAD);
        float sr = sinf(rollRAD);
        float cp = cosf(pitchRAD);
        float sp = sinf(pitchRAD);
        float Xh;
        float Yh;
        Xh = magX*cp+magY*sr*sp + magZ*cr*sp;
        Yh = magY*cr-magZ*sr;   
        heading = _atan2f(-Yh,Xh);                      // magnetic heading * 10

You can fly your copter on the back without loosing the heading now :). This is only possible with your nice "proper" matrix rotation!!
The next step is the calibration, fiddeling with drv_hmc5883l and other ugly stuff.
BTW: I questioned here viewtopic.php?f=8&t=3031#p30539 but no reply:( . The link here: http://www.loveelectronics.co.uk/Tutori ... o-tutorial contains just s**t.

Cheers
Kraut
Rob

EDIT: Don't use it with orig. mwii because you will have no benefit without the proper matrix rotation routine from TC.
Last edited by Crashpilot1000 on Wed Feb 06, 2013 5:27 am, edited 3 times in total.

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

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Very nice.
Been waiting for something to come out of that mag discusion in the other thread, though formatting and indentation definitely needs to go.
Also C89 doesn't allow variable declarations in the middle of scope, I suppose you knew that though.

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

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

timecop wrote: ...Also C89 doesn't allow variable declarations in the middle of scope, I suppose you knew that though.


Thanks!!!
No, I am no programmer, so i don't know this stuff.. What should i do with the Variables? Declare them before?

Cheers
Kraut

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

Re: Baseflight aka multiwii port to stm32

Post by timecop »

I'll probably merge this into current code after making sure its all good, so you will see the proper way.
But yeah, start of scope is after opening brace ({) so variables get declared there, then used later.

EDIT: just applied it to baseflight, very nice! mag angle is perfect throughout. Will commit shortly.

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

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

Thx for injecting the code into the official branch!!
lol! I don't see the difference of variable definition :). EDIT: Ahh, i see, the Xh Yh stuff!!
BTW I got compile errors with the "#if INACCURATE" stuff when doing #define INACCURATE. Writing "#ifdef INACCURATE" instead of "#if INACCURATE" works. Perhaps it's my compiler.

Cheers
Kraut Rob

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

Re: Baseflight aka multiwii port to stm32

Post by timecop »

for #if, you need to do something like #define INACCURATE 1
#ifdef checks if something is DEFINED, #if checks literal value , so with #define INACCURATE, it would be #if ??? (nothing) bla bla #endif
and with #define iNACCURATE 1 it would be #if 1 /* code */ #endif
Yea, about vars, I forgot that the mag stuff was at start of scope - I thought the heading calculation was buried in the middle of stuff. so var/scope comment doesn't really apply.

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

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

Ahh, ok now i understand the magic of the #if /#ifdef stuff.
Currently i removed all the inaccurate stuff, because i have no use for it anymore. When checking the mag i saw that S is not exactly on the opposite of N. It's probably off by 10degrees. That is now fixed with more FP math. The Mag gets better.

Code: Select all

 #define RADX10 M_PI/1800.0f                  // if not already defined in board.h

    if (sensors(SENSOR_MAG)) {
        float rollRAD = (float)angle[ROLL] * RADX10;    // Crashpilot CORRECT MAG TILT COMPENSATION now you can fly on your back with correct heading
        float pitchRAD = -(float)angle[PITCH] * RADX10;
        float magX = EstM.A[1];                         // Swap X/Y
        float magY = EstM.A[0];                         // Swap X/Y
        float magZ = EstM.A[2];
        float cr = cosf(rollRAD);
        float sr = sinf(rollRAD);
        float cp = cosf(pitchRAD);
        float sp = sinf(pitchRAD);
        float Xh = magX * cp + magY * sr * sp + magZ * cr * sp;
        float Yh = magY * cr - magZ * sr;
        float flthead = (atan2f(-Yh,Xh) * 1800.0f / M_PI + magneticDeclination)/10;
        if (flthead > 180.0f) flthead = flthead - 360.0f;
        else if (flthead < -180.0f) flthead = flthead + 360.0f;
        heading = flthead;
    }


Cheers
Kraut Rob

whakahere
Posts: 20
Joined: Wed Jan 30, 2013 9:17 pm

Re: Baseflight aka multiwii port to stm32

Post by whakahere »

most likely a no answer but if I don't ask I don't know.

Can you update the firmware through the bluetooth module? I have sunk the board into the quad and can only reach it now through bluetooth.

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

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

@TC: Your drv_ms5611.c seems somehow faulty. It is producing slow but increasing measurements. Even a BMP in the same room doesn't do that. I am still looking to fix this. Do you have an idea?

Cheers Kraut Rob

@ whakahere: BT is just a serial cable with air in between?? Why shouldn't it work?


EDIT: I did some really hacky sh** to the mag stuff in sensors.c - to not disrupt the datastructure - and i got the mag 10-15 degree more accurate on tilting now.

whakahere
Posts: 20
Joined: Wed Jan 30, 2013 9:17 pm

Re: Baseflight aka multiwii port to stm32

Post by whakahere »

well I will give it a try .... that is if I can find out how to update firmware with a mac. It's my only machine with bluetooth build in. I have no problem talking with the cli so I can get the computer and the board communicating.

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Baseflight aka multiwii port to stm32

Post by brm »

Crashpilot1000 wrote:@TC: Your drv_ms5611.c seems somehow faulty. It is producing slow but increasing measurements. Even a BMP in the same room doesn't do that. I am still looking to fix this. Do you have an idea?


what means increasing?
2mm or 2m?

edit: i looked at it again.
behaves nice +- 5 cm.
your setup seems to be in question:
- correct voltage and stable?
- bad board?

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

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

I looked into this ms driver thing some more. It seems i produced a timing issue of some kind. Sometimes it works ok but on the next initialization it can produce +4m in 5 minutes in a closed room.... hmm. So it's a problem produced by ME, but perhaps it just reveals a weakness. Interestingly on my other naze with BMP the bmp behaves better in this regard.
The MS hardware is fine.
Cheers Kraut Rob

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Baseflight aka multiwii port to stm32

Post by brm »

ha - i just flew my imu with an ms device ... sucks.
i need to adjust the whole altitude hold - not only parts ... :-/

the test flight was with my larger quad - with low kv motors and a rel. soft frame.
the video is just bad ...

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

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

Hi!

The ms 5611 is a real bi***. It seems i have found / fixed the problem. The more or less increasing measured hight is a problem of the initialization - even with the original TC-hex files. I found that out by powering the naze and looking at the increasing hight, than without repowering, i entered the cli and exit to reset the naze, and Boom - it works correctly. I have another ms baro in my mwii (with the plastic cap) wich doesn't show this problem so it seems to be some variation between the msbaros.


Code: Select all

altered ms5611Detect:
...
    baro->get_up = ms5611_get_up;
    baro->calculate = ms5611_calculate;

    delay(50);
    for (i = 0; i < 10; i++) ms5611_reset();                     // Reset the damn thing a few times
    delay(50);
    return true;
}
...

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

Harakiri 07

Post by Crashpilot1000 »

Hi, based on Harakiri6c (viewtopic.php?f=23&t=1947&start=160#p30453) i improved the mag stuff (including calibration: http://fpv-community.de/showthread.php? ... post289267) and did slight improvements on baro (MS/BMP). Now the mag calibration runs for 60 sec, calibrate ACC before and put in the right mag declination (cli). Also swing copter on its' back and do a full yaw turn during mag calibration. You can see the full post here in "Kraut": http://fpv-community.de/showthread.php? ... post289961. I also added a 200ms delay before initial I2C initialization to give homebuild tarduino devices some time to initialize.

Have Fun!

Cheers
Kraut Rob

BTW: There is also some interesting stuff here: http://code.google.com/p/multiwii/source/detail?r=1337
Attachments
Harakiri07SOURCE.zip
(116.53 KiB) Downloaded 2443 times
Harakiri07HEX.zip
(67.87 KiB) Downloaded 2439 times

msev
Posts: 186
Joined: Thu Apr 14, 2011 11:49 am

Re: Baseflight aka multiwii port to stm32

Post by msev »

Nice work Crashpilot1000! Would you by any chance include also some kind of support for fixed wings in one of your next releases, so that fixed wing aircraft could do all the cool stuff like rth, ph, altitude hold & heading hold and of course the mandatory stab.+autolevel.

It would probably be a tough job, but I know you can handle it ;)

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

Re: Baseflight aka multiwii port to stm32

Post by fiendie »

msev wrote:Nice work Crashpilot1000! Would you by any chance include also some kind of support for fixed wings in one of your next releases, so that fixed wing aircraft could do all the cool stuff like rth, ph, altitude hold & heading hold and of course the mandatory stab.+autolevel.

It would probably be a tough job, but I know you can handle it ;)

Nobody cares about fixed wings msev.
Go over to the *Mono*Wii forum and try your luck there. ;)

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

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

@msev: Thank you very much for encouragement! Unfortunately i don't have a fixed wing and it is not my interest....
But maybe here might be the right spot for you to look:

http://code.google.com/p/nextcopterplus ... _UserGuide
http://www.rcgroups.com/forums/showthread.php?t=1729230

Cheers
Kraut Rob

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

GPS/ACC first test.....

Post by Crashpilot1000 »

Hi!
Based on the talk here viewtopic.php?f=8&t=2503, i tried something like this on the naze with the improved magnetometerstuff to get the acceleration according to the compass directions and compensate it with the laggy gps data. I took the rotation stuff from "sebbi" here: https://github.com/sebastianherp/multiw ... a_accurate and adjusted it slightly, that it actually works :). Most variables are already calculated with the accurate magnetometer stuff.
The current procedure includes several steps
1.: Get a good heading from mag, do the sin - cos - stuff
2.: Transform acc readings to "earth" frame (i.e North/west etc). Take prefiltered acc values normally used by accz althold.
3.: Sum them up with correct delta time and scaling factor to get speed cm/s (error is rapidly increasing). Cancel out acc noise before (correct value unknown set it currently to "80"). Cancel out centrifugal forces/yaw: currently not implemented
4.: Compensate the acc - summation - error with the actual speed measured by gps (cm/s) complementary filter is used to correct the sum. Filterfactor unknown (0.001 - 0.9xx). If the summation is running longer than 0,5s without gps correction - cancel out the sum (i.e set it to zero).
5.: Feed the crucial GPS routine "GPS_calc_velocity" with the fusioned data. The GPS Pid controller stuff is still called at gps updaterate (5Hz) - that could/should be decoupled in the future.

Here is the stuff:
First the variables:

Code: Select all

...
     float VelNorth = 0, VelEast = 0;      This is "global" for IMU.c and GPS.c
...
    accVelScale = 9.80665f / acc_1G / 10000.0f;
...
    velfactor = accVelScale * (float)ACCDeltaTime;  This is calculated right at acc readout to get the correct timebase
...
    cfg.gps_ins_cf           This is a new CLI Variable to set the complementary filter for the gps/acc fusion. 0 disables the acc stuff. The higher it gets, the more acc influence you will get.
...


Now the IMU stuff together with the MAG. I posted the complete "#ifdef MAG".

Code: Select all

#define RADX M_PI / 180.0f
#ifdef MAG
    if (sensors(SENSOR_MAG)) {
    float rollRAD, pitchRAD, cr, sr, cp, sp, Xh, Yh, flthead;
    float cy, sy, spcy, spsy, acc_south, acc_west;
    rollRAD = (float)angle[ROLL] * RADX10;                        // CORRECT MAG TILT COMPENSATION
        pitchRAD = -(float)angle[PITCH] * RADX10;
        cr = cosf(rollRAD);
        sr = sinf(rollRAD);
        cp = cosf(pitchRAD);
        sp = sinf(pitchRAD);
        Xh = EstM.A[1] * cp + EstM.A[0] * sr * sp + EstM.A[2] * cr * sp;
        Yh = EstM.A[0] * cr - EstM.A[2] * sr;
          flthead = (atan2f(-Yh,Xh) * 1800.0f / M_PI + magneticDeclination)/10;
        if (flthead > 180.0f) flthead = flthead - 360.0f;
        else if (flthead < -180.0f) flthead = flthead + 360.0f;
        heading = flthead;                                            // Heading in Degrees
            if (sensors(SENSOR_GPS) && cfg.gps_ins_cf !=0) {              // Do GPS INS rotate ACC X/Y to earthframe no centrifugal comp. yet
                flthead = flthead * RADX;                                 // Floatheading to RAD
               cy = cosf(flthead);
            sy = sinf(flthead);
               spcy = sp * cy;
               spsy = sp * sy;
            acc_south = (cp * cy) * accLPFVel[1] + (sr * spcy - cr * sy) * accLPFVel[0] + (sr * sy + cr * spcy) * accLPFVel[2];
            acc_west  = (cp * sy) * accLPFVel[1] + (cr * cy + sr * spsy) * accLPFVel[0] + (-sr * cy + cr * spsy) * accLPFVel[2];
            if (abs(acc_south) < 80) acc_south = 0;                   // Cancel out some acc noise maybe 80?
            if (abs(acc_west) < 80) acc_west = 0;                     // Cancel out some acc noise maybe 80?
            VelNorth  = VelNorth - acc_south * velfactor;             // Positive when moving North cm/sec
            VelEast   = VelEast - acc_west * velfactor;               // Positive when moving East cm/sec
           }
    }
#endif


Now the changed "static void GPS_calc_velocity(void)" in GPS.c

Code: Select all

static void GPS_calc_velocity(void)
{
    static int16_t speed_old[2] = { 0, 0 };
    static int32_t last[2] = { 0, 0 };
    static uint8_t init = 0;
    static uint32_t lasttime = 0;
    uint32_t temp;
    // actual_speed[GPS_Y] y_GPS_speed positve = Up (NORTH)
    // actual_speed[GPS_X] x_GPS_speed positve = Right (EAST)
    if (init){
        float tmp = 1.0f / dTnav;
        actual_speed[GPS_X] = (float) (GPS_coord[LON] - last[LON]) * GPS_scaleLonDown * tmp;
        actual_speed[GPS_Y] = (float) (GPS_coord[LAT] - last[LAT]) * tmp;
        actual_speed[GPS_X] = (actual_speed[GPS_X] + speed_old[GPS_X]) / 2;
        actual_speed[GPS_Y] = (actual_speed[GPS_Y] + speed_old[GPS_Y]) / 2;
        speed_old[GPS_X] = actual_speed[GPS_X];
        speed_old[GPS_Y] = actual_speed[GPS_Y];
           temp = micros();                                          // Crashpilot do CF with acc vel START
           if ((temp - lasttime) < 500000 && cfg.gps_ins_cf !=0) {   // Only accept summation if last correction is not older than 0,5s
               VelNorth = VelNorth * cfg.gps_ins_cf + (float)actual_speed[GPS_Y] * (1.0f - cfg.gps_ins_cf);  // CF: GPS Correction
                VelEast  = VelEast  * cfg.gps_ins_cf + (float)actual_speed[GPS_X] * (1.0f - cfg.gps_ins_cf);  // CF: GPS Correction
               actual_speed[GPS_Y] = VelNorth;
               actual_speed[GPS_X] = VelEast;
            } else {                                                  // INS Correction not possible: Timeout or turned off
                VelNorth = 0;
                 VelEast = 0;
            }
            lasttime = temp;                                          // Crashpilot do CF with acc vel END
    }
    init = 1;
    last[LON] = GPS_coord[LON];
    last[LAT] = GPS_coord[LAT];
}


These are the crucial points. I post the whole stuff here based on Harakiri07 so a "diff" is easy.

Cheers

Kraut Rob
Attachments
Harakiri7bGPSinsTestHEX.zip
(68.67 KiB) Downloaded 2408 times
Harakiri7bGPSinsTest.zip
ACC GPS Fusion is disabled. To enable it set gps_ins_cf to some value. Perhaps start with "set gps_ins_cf = 0.666" ???
(117.61 KiB) Downloaded 2458 times

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

Re: Baseflight aka multiwii port to stm32

Post by Gimbal »

tc the cam stab future in baseflight dos it have filter ability like this:
viewtopic.php?f=8&t
Last edited by Gimbal on Wed Feb 13, 2013 3:59 pm, edited 1 time in total.

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

Re: Baseflight aka multiwii port to stm32

Post by timecop »

> tc the cam stab future in baseflight dos it have filter ability like this

it supports tiltmix gimbal (me and ABL tested/debugged it few weeks ago),

if you want the filtering stuff from that thread (not sure why, may be the noise/jitter in arduino version is because thier servo outputs suck), feel free to add and test it.

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

Re: Baseflight aka multiwii port to stm32

Post by Gimbal »

i will, as soon as I'm able ;-)

kol
Posts: 5
Joined: Fri Jan 04, 2013 6:11 am

Re: Baseflight aka multiwii port to stm32

Post by kol »

CrashPilot1000, do you have a github or svn repository?

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

Re: Baseflight aka multiwii port to stm32

Post by timecop »

He doesn't believe in patches or source control.
This is kind of why its very difficult to follow any of his mods.

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 again guys,
I've now got a mag sensor board for my Free Flight board, that's running TC's Baseflight. While researching the required mag sensor orientation I note that the Naze32 boards and the images I've found of the later model Free Flight C10 board differ to each other by 90 degrees to the flight direction.
This invokes a question.
How much does the mag sensor orientation matter ?
And is TC's indicated chip orientation the easiest in relation to software settings and calibration (if it does matter) ?

Thanks,
Martin

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

Re: Baseflight aka multiwii port to stm32

Post by crazyal »

Crashpilot1000, I just had a look at your code, you have done some good work on the althold stuff :)
There is one thing I stumbled over, which looks pretty bad to me. You changed the PID controllers to float and made them time dependent. This is a good thing, but only when done the correct way. The error itself is not time dependent, only the P and I term are, so you should only correct these. See: http://www.rn-wissen.de/index.php/Regel ... ler_Regler or http://en.wikipedia.org/wiki/PID_controller#Pseudocode
I mean this:

Code: Select all

errorAngle = errorAngle*(float)cycleTime/BasePIDtime;

you should remove it and do something like that for the I-Term:

Code: Select all

ITermACC = ((float)errorAngleI[axis] * (float)cfg.I8[PIDLEVEL] * (float)cycleTime/BasePIDtime )/4096.0f;

D-term:

Code: Select all

DTerm = ((float)deltaSum * (float)dynD8[axis] * (float)BasePIDtime/cycleTime )/32.0f;

I'm 100% sure if this is the best solution, but in theory it should work.

And could you please start using git ? https://github.com/multiwii/baseflight
It makes it much easier for people like me to to see what you have changed and you'll see a version control system has many benefits ;)

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

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

@crazyal: Hi!

Thank you very much for looking into this code!
I think to really make the PID controller time independent we would have to rewrite it from scratch. But i just wanted to patch in slight time variations to improve the flightbehaviour. Multiwii flies really well so re-inventing the wheel and ignoring years of great flying did not seem reasonable to me. The changes still seem logical to me and they fly very well, please feel free to test your suggestions! Currently I improved the gps accuracy and set up a github thing here: https://github.com/Crashpilot1000/bf but i have really no idea how to use it .... have a look at the gps.c !

Cheers Kraut Rob

Post Reply