Baseflight aka multiwii port to stm32

timecop · Post by **timecop** » Fri Feb 01, 2013 5:45 am

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.

Crashpilot1000 · Post by **Crashpilot1000** » Sun Feb 03, 2013 11:38 pm

@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

Lapino · Post by **Lapino** » Sun Feb 03, 2013 11:54 pm

Sounds nice

Did anyone test it yet?
I would if I could

timecop · Post by **timecop** » Mon Feb 04, 2013 12:04 am

Crashpilot1000 - you mean GPS works? Shock and horror.

Crashpilot1000 · Post by **Crashpilot1000** » Mon Feb 04, 2013 12:12 am

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

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

Cheers
Kraut Rob

Gimbal · Post by **Gimbal** » Mon Feb 04, 2013 11:50 am

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

timecop · Post by **timecop** » Mon Feb 04, 2013 11:52 am

First post of thread.

Gimbal · Post by **Gimbal** » Mon Feb 04, 2013 1:29 pm

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 · Post by **timecop** » Mon Feb 04, 2013 1:33 pm

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 · Post by **Gimbal** » Mon Feb 04, 2013 1:46 pm

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.

Crashpilot1000 · Post by **Crashpilot1000** » Mon Feb 04, 2013 5:11 pm

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 · Post by **Gimbal** » Mon Feb 04, 2013 7:56 pm

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

Crashpilot1000 · Post by **Crashpilot1000** » Mon Feb 04, 2013 8:15 pm

@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

Crashpilot1000 · Post by **Crashpilot1000** » Wed Feb 06, 2013 4:46 am

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.

timecop · Post by **timecop** » Wed Feb 06, 2013 4:49 am

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.

Crashpilot1000 · Post by **Crashpilot1000** » Wed Feb 06, 2013 4:55 am

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 · Post by **timecop** » Wed Feb 06, 2013 4:57 am

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.

Crashpilot1000 · Post by **Crashpilot1000** » Wed Feb 06, 2013 5:46 am

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 · Post by **timecop** » Wed Feb 06, 2013 6:59 am

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.

Crashpilot1000 · Post by **Crashpilot1000** » Wed Feb 06, 2013 5:14 pm

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 · Post by **whakahere** » Fri Feb 08, 2013 11:01 pm

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.

Crashpilot1000 · Post by **Crashpilot1000** » Fri Feb 08, 2013 11:02 pm

@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 · Post by **whakahere** » Fri Feb 08, 2013 11:19 pm

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 · Post by **brm** » Sat Feb 09, 2013 11:03 am

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?

Crashpilot1000 · Post by **Crashpilot1000** » Sat Feb 09, 2013 4:05 pm

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 · Post by **brm** » Sat Feb 09, 2013 4:43 pm

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 ...

Crashpilot1000 · Post by **Crashpilot1000** » Sun Feb 10, 2013 5:19 pm

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;
}
...

Crashpilot1000 · Post by **Crashpilot1000** » Sun Feb 10, 2013 10:45 pm

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

msev · Post by **msev** » Sun Feb 10, 2013 11:10 pm

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 · Post by **fiendie** » Sun Feb 10, 2013 11:30 pm

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.

Crashpilot1000 · Post by **Crashpilot1000** » Mon Feb 11, 2013 12:41 am

@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

Crashpilot1000 · Post by **Crashpilot1000** » Tue Feb 12, 2013 12:06 am

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

Gimbal · Post by **Gimbal** » Wed Feb 13, 2013 8:18 am

tc the cam stab future in baseflight dos it have filter ability like this:
viewtopic.php?f=8&t

timecop · Post by **timecop** » Wed Feb 13, 2013 8:35 am

> 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 · Post by **Gimbal** » Wed Feb 13, 2013 8:52 am

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

kol · Post by **kol** » Wed Feb 13, 2013 9:55 am

CrashPilot1000, do you have a github or svn repository?

timecop · Post by **timecop** » Wed Feb 13, 2013 10:06 am

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

mr.sneezy · Post by **mr.sneezy** » Thu Feb 14, 2013 10:14 am

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 · Post by **crazyal** » Thu Feb 14, 2013 8:42 pm

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

Crashpilot1000 · Post by **Crashpilot1000** » Thu Feb 14, 2013 9:29 pm

@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

crazyal · Post by **crazyal** » Thu Feb 14, 2013 9:52 pm

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

Crashpilot1000 · Post by **Crashpilot1000** » Thu Feb 14, 2013 11:47 pm

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

timecop · Post by **timecop** » Fri Feb 15, 2013 2:36 am

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.

Crashpilot1000 · Post by **Crashpilot1000** » Fri Feb 15, 2013 10:22 am

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

crazyal · Post by **crazyal** » Fri Feb 15, 2013 3:39 pm

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.

fiendie · Post by **fiendie** » Fri Feb 15, 2013 4:13 pm

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

Crashpilot1000 · Post by **Crashpilot1000** » Fri Feb 15, 2013 4:27 pm

@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 · Post by **crazyal** » Fri Feb 15, 2013 6:18 pm

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)

Crashpilot1000 · Post by **Crashpilot1000** » Fri Feb 15, 2013 6:46 pm

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.

Crashpilot1000 · Post by **Crashpilot1000** » Sun Feb 17, 2013 10:29 am

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