f3r / afrodevices Goto Github PK

Acc trim (with sticks) isn't working on r316 revision. Earlier version where 
it's broken is at least r309 (may be even on earlier release on this branch).
Easy to reproduce and check:
 - reset to defaults
 - try to fly (without weather) in gyro mode, notice any drifts (if at all)
 - turn on acc (i used horizon mode). Notice drift (if it is at all - mine drifts to left)
 - land, disarm, throttle max, roll left several times
 - fly - no difference
I tried > 40 beeps (it still beeps) - no difference at all. Even if acc is 
perfectly located and no trim needed - then probably could be reproduced by 
"trimming it out".

Tested with small and heavy (~60% to hover) copter, almost no vibrations, no 
drift in gyro mode, drift to left (port side) in acc mode. HW: NAZE32 with 
aditional acc, mag connected but not activated.

What steps will reproduce the problem?
1.Compile r382 with Sourcery Lite toolchain

What is the expected output? What do you see instead?
Exprected: Build products
Instead: Compiler errors

What version of the product are you using? On what operating system?
r382, Sourcery Lite, Eclipse, Win7

Please provide any additional information below.

see uart.patch

Here's a cleaner and hopefully easier-to-maintain Makefile for the baseflight 
bits.

"anti-wobble-on-descent" aka pt1 filter isn't working well in r266 revision. It 
was 
working very, very well in r293 revision (also check - acc trim and other stuff 
is working here as well), but in latest (r315 tested) revision it isn't smooth 
or working at all. I still get "wobbles" on descent.

I added some lines:

const clivalue_t valueTable[] = {
    { "deadband", VAR_UINT8, &cfg.deadband, 0, 32 },
    { "midrc", VAR_UINT16, &cfg.midrc, 1200, 1700 },
    { "minthrottle", VAR_UINT16, &cfg.minthrottle, 0, 2000 },
    { "maxthrottle", VAR_UINT16, &cfg.maxthrottle, 0, 2000 },
    { "mincommand", VAR_UINT16, &cfg.mincommand, 0, 2000 },
    { "mincheck", VAR_UINT16, &cfg.mincheck, 0, 2000 },
    { "maxcheck", VAR_UINT16, &cfg.maxcheck, 0, 2000 },
    { "vbatscale", VAR_UINT8, &cfg.vbatscale, 10, 200 },
    { "yaw_direction", VAR_INT8, &cfg.yaw_direction, -1, 1 },
    { "wing_left_mid", VAR_UINT16, &cfg.wing_left_mid, 0, 2000 },
    { "wing_right_mid", VAR_UINT16, &cfg.wing_right_mid, 0, 2000 },
    { "tri_yaw_middle", VAR_UINT16, &cfg.tri_yaw_middle, 0, 2000 },
    { "tri_yaw_min", VAR_UINT16, &cfg.tri_yaw_min, 0, 2000 },
    { "tri_yaw_max", VAR_UINT16, &cfg.tri_yaw_max, 0, 2000 },
    { "tilt_pitch_prop", VAR_INT8, &cfg.tilt_pitch_prop, -100, 100 },
    { "tilt_roll_prop", VAR_INT8, &cfg.tilt_roll_prop, -100, 100 },
    { "p_pitch", VAR_UINT8, &cfg.P8[PITCH], 0, 200},
    { "i_pitch", VAR_UINT8, &cfg.I8[PITCH], 0, 200},
    { "d_pitch", VAR_UINT8, &cfg.D8[PITCH], 0, 200},
    { "p_roll", VAR_UINT8, &cfg.P8[ROLL], 0, 200},
    { "i_roll", VAR_UINT8, &cfg.I8[ROLL], 0, 200},
    { "d_roll", VAR_UINT8, &cfg.D8[ROLL], 0, 200},
    { "p_yaw", VAR_UINT8, &cfg.P8[YAW], 0, 200},
    { "i_yaw", VAR_UINT8, &cfg.I8[YAW], 0, 200},
    { "d_yaw", VAR_UINT8, &cfg.D8[YAW], 0, 200},
    { "p_level", VAR_UINT8, &cfg.P8[PIDLEVEL], 0, 200},
    { "i_level", VAR_UINT8, &cfg.I8[PIDLEVEL], 0, 200},
    { "d_level", VAR_UINT8, &cfg.D8[PIDLEVEL], 0, 200},

At least in r315 revision alt hold isn't working correctly.
Earlier version, where alt hold was working OK - r261, probably some versions 
after that or even latest release from TC branch.

I tested with low alt PID's (something like 14, 10, 20), with very high (70, 
30, 40), it's not working in any case...

Expecting: stable hover (was working in earlier TC releases with P=17, I=12, 
D=30) within 1m height (if wind won't disturb). Yes, baro (and acc) is covered 
with soft foam and it was working good before.
Actual result - hover with throttle and acc (horizon) mode on, turn on baro. 
Copter will tilt to it's back (not a lot, but noticeable) and will slowly 
oscillate in ~5 meter altitude (on very high P value only, on small it's not 
noticeable). Affected by throttle a lot - won't hold altitude at all if 
throttle isn't inside hover range.
So, based on those observations - i would say alt hold does not work at all 
(but activation does something - at least copter tilts a bit to back when 
activating).

What steps will reproduce the problem?
1.Reset to defaults
2.set mixer TRI or feature GYRO_SMOOTHING
3.Gyro input is always at 0, even if shaking the tricopter.

What is the expected output? What do you see instead?

Expected it to respond to shaking, but it doesn't.

What version of the product are you using? On what operating system?

Latest as of writing this

Please provide any additional information below.

Patch included to fix things :)

Hello:
     Stm32f103ve MPU6050 ACC GRYO open DMP function after no data output. Shut down DMP all function is normal. May I ask how is it?

What steps will reproduce the problem?

1. in CLI, "feature PPM" and "map TAER1234"
2. go to RC Control Setting tab, tick on Beeper in the Aux1 H box
3. click Write Setting

What is the expected output? What do you see instead?
expected outcome is mapped controls using PPM with beeper that turns on with 
aux1 engaged.  Instead, many settings get set to something other than default 
(i.e., minthrottle goes to 0 instead of 1150.)  But beeper works.

What version of the product are you using? On what operating system?
Baseflight r461, Cartsen's Baseflight GUI 2.3.5.0

Please provide any additional information below.
same thing happens when using MiltiWiiConf, but NOT when using the Google 
Chrome extension bt cTn.  So I'm not sure if this is a bug in the board 
firmware, or the GUI's.

To correct function "parseRcChannels".

to correct the rcMap.
example : TREA1234 should be [3 0 1 2 4 5 6 7] but the optput is  [1 2 3 0 4 5 
6 7] 

I was trying arround to get Tricopter and Gimbal work at the same time without 
luck, after looking in the mixer.c i found that:

void writeServos(void)
{
    if (!useServo)
        return;

    switch (mcfg.mixerConfiguration) {
        case MULTITYPE_BI:
            pwmWriteServo(0, servo[4]);
            pwmWriteServo(1, servo[5]);
            break;

        case MULTITYPE_TRI:
            pwmWriteServo(0, servo[5]);
            break;

        case MULTITYPE_AIRPLANE:

            break;

        case MULTITYPE_FLYING_WING:
        case MULTITYPE_GIMBAL:
            pwmWriteServo(0, servo[0]);
            pwmWriteServo(1, servo[1]);
            break;

        default:
            // Two servos for SERVO_TILT, if enabled
            if (feature(FEATURE_SERVO_TILT)) {
                pwmWriteServo(0, servo[0]);
                pwmWriteServo(1, servo[1]);
            }
            break;
    }
}

If i see that right Tricopter with Gimbal is not possible at the moment right?
In general that would be possible, as there are enought output pins right?

Code additions allow separate adjustment of a deadband in the yaw channel only.
Previously existing variable 'deadband' is now used only for roll/pitch 
channel. New variable 'yawdeadband' is used for the yaw channel.
Attached patch changes deadband algorithm and also makes yawdeadband editable 
in CLI.
Code has been tested, but please doublecheck!

a

[deleted issue]

[deleted issue]

I tried to verify that the baseflight firmware does not have any obvious bugs 
like division by zero, array access out of bound, ...

To do this I used CBMC to verify the loop function in mw.c. Until now CBMC 
found two possible bugs. I'm not sure if this are real bugs as the tool works 
with non-deterministic assumptions and cannot check if the values that trigger 
the bug are present during normal operation.

In the function annexCode line 125: array out of bound when tmp=500 in statement

rcCommand[axis] = lookupPitchRollRC[tmp2] + (tmp - tmp2 * 100) * 
(lookupPitchRollRC[tmp2 + 1] - lookupPitchRollRC[tmp2]) / 100;

Line 803: possible integer overflow in statement

cycleTime = (int32_t)(currentTime - previousTime);


The verification is not finished yet and more bugs may be found. I will report 
back any further results.

Regards,
Johannes

[deleted issue]

This patch allows automatic start of firmware after (re)loading via stm32loader 
(maybe other tools too).

[deleted issue]