Page 4 of 21

Re: Baseflight aka multiwii port to stm32

Posted: Wed Jan 30, 2013 9:33 am
by gena_g
Tell me please. As the firmware r260 mode triŅoptera can include Gimbal (servo_tilt).

Re: Baseflight aka multiwii port to stm32

Posted: Wed Jan 30, 2013 9:40 am
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.

Re: Baseflight aka multiwii port to stm32

Posted: Wed Jan 30, 2013 10:02 am
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

Re: Baseflight aka multiwii port to stm32

Posted: Wed Jan 30, 2013 10:12 am
by timecop
Right.
Feel free to contribute a patch that makes use of additionally available servos in that mode.
Its certainly doable.

Re: Baseflight aka multiwii port to stm32

Posted: Wed Jan 30, 2013 9:20 pm
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?

AW: Baseflight aka multiwii port to stm32

Posted: Wed Jan 30, 2013 10:13 pm
by Lapino
Looptime should be in the set accessible via cli ;)
Just have a closer look at it...

Re: Baseflight aka multiwii port to stm32

Posted: Wed Jan 30, 2013 10:27 pm
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.

Re: Baseflight aka multiwii port to stm32

Posted: Thu Jan 31, 2013 11:53 am
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

Re: Baseflight aka multiwii port to stm32

Posted: Thu Jan 31, 2013 5:29 pm
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.

Re: Baseflight aka multiwii port to stm32

Posted: Thu Jan 31, 2013 5:48 pm
by Crashpilot1000
Hahaha actually it is arducopter gps leadfilter class "failcode" LOL !
I am too stupid to do that but i will try :)

Re: Baseflight aka multiwii port to stm32

Posted: Fri Feb 01, 2013 5:45 am
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.

Re: Baseflight aka multiwii port to stm32

Posted: Sun Feb 03, 2013 11:38 pm
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

AW: Baseflight aka multiwii port to stm32

Posted: Sun Feb 03, 2013 11:54 pm
by Lapino
Sounds nice ;)
Did anyone test it yet?
I would if I could :(

Re: Baseflight aka multiwii port to stm32

Posted: Mon Feb 04, 2013 12:04 am
by timecop
Crashpilot1000 - you mean GPS works? Shock and horror.

Re: Baseflight aka multiwii port to stm32

Posted: Mon Feb 04, 2013 12:12 am
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

Re: Baseflight aka multiwii port to stm32

Posted: Mon Feb 04, 2013 11:50 am
by Gimbal
I'm a bit confused, witch software version shall i use and what GUI

Re: Baseflight aka multiwii port to stm32

Posted: Mon Feb 04, 2013 11:52 am
by timecop
First post of thread.

Re: Baseflight aka multiwii port to stm32

Posted: Mon Feb 04, 2013 1:29 pm
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

Re: Baseflight aka multiwii port to stm32

Posted: Mon Feb 04, 2013 1:33 pm
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.

Re: Baseflight aka multiwii port to stm32

Posted: Mon Feb 04, 2013 1:46 pm
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.

Re: Baseflight aka multiwii port to stm32

Posted: Mon Feb 04, 2013 5:11 pm
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?

Re: Baseflight aka multiwii port to stm32

Posted: Mon Feb 04, 2013 7:56 pm
by Gimbal
thnx CP1000 for great work, trying to keep up with small successes ;-)

Re: Baseflight aka multiwii port to stm32

Posted: Mon Feb 04, 2013 8:15 pm
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

Re: Baseflight aka multiwii port to stm32

Posted: Wed Feb 06, 2013 4:46 am
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.

Re: Baseflight aka multiwii port to stm32

Posted: Wed Feb 06, 2013 4:49 am
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.

Re: Baseflight aka multiwii port to stm32

Posted: Wed Feb 06, 2013 4:55 am
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

Re: Baseflight aka multiwii port to stm32

Posted: Wed Feb 06, 2013 4:57 am
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.

Re: Baseflight aka multiwii port to stm32

Posted: Wed Feb 06, 2013 5:46 am
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

Re: Baseflight aka multiwii port to stm32

Posted: Wed Feb 06, 2013 6:59 am
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.

Re: Baseflight aka multiwii port to stm32

Posted: Wed Feb 06, 2013 5:14 pm
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

Re: Baseflight aka multiwii port to stm32

Posted: Fri Feb 08, 2013 11:01 pm
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.

Re: Baseflight aka multiwii port to stm32

Posted: Fri Feb 08, 2013 11:02 pm
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.

Re: Baseflight aka multiwii port to stm32

Posted: Fri Feb 08, 2013 11:19 pm
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.

Re: Baseflight aka multiwii port to stm32

Posted: Sat Feb 09, 2013 11:03 am
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?

Re: Baseflight aka multiwii port to stm32

Posted: Sat Feb 09, 2013 4:05 pm
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

Re: Baseflight aka multiwii port to stm32

Posted: Sat Feb 09, 2013 4:43 pm
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 ...

Re: Baseflight aka multiwii port to stm32

Posted: Sun Feb 10, 2013 5:19 pm
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;
}
...

Harakiri 07

Posted: Sun Feb 10, 2013 10:45 pm
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

Re: Baseflight aka multiwii port to stm32

Posted: Sun Feb 10, 2013 11:10 pm
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 ;)

Re: Baseflight aka multiwii port to stm32

Posted: Sun Feb 10, 2013 11:30 pm
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. ;)

Re: Baseflight aka multiwii port to stm32

Posted: Mon Feb 11, 2013 12:41 am
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

GPS/ACC first test.....

Posted: Tue Feb 12, 2013 12:06 am
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

Re: Baseflight aka multiwii port to stm32

Posted: Wed Feb 13, 2013 8:18 am
by Gimbal
tc the cam stab future in baseflight dos it have filter ability like this:
viewtopic.php?f=8&t

Re: Baseflight aka multiwii port to stm32

Posted: Wed Feb 13, 2013 8:35 am
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.

Re: Baseflight aka multiwii port to stm32

Posted: Wed Feb 13, 2013 8:52 am
by Gimbal
i will, as soon as I'm able ;-)

Re: Baseflight aka multiwii port to stm32

Posted: Wed Feb 13, 2013 9:55 am
by kol
CrashPilot1000, do you have a github or svn repository?

Re: Baseflight aka multiwii port to stm32

Posted: Wed Feb 13, 2013 10:06 am
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.

Re: Baseflight aka multiwii port to stm32

Posted: Thu Feb 14, 2013 10:14 am
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

Re: Baseflight aka multiwii port to stm32

Posted: Thu Feb 14, 2013 8:42 pm
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 ;)

Re: Baseflight aka multiwii port to stm32

Posted: Thu Feb 14, 2013 9:29 pm
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