Airplane RTH BaseFlight

PatrikE · Post by **PatrikE** » Thu Apr 10, 2014 8:15 pm

Navigation code for FixedWing in Baseflihgt.

This branch have been merged to Baseflight master.
https://github.com/multiwii/baseflight

Latest Hexfile
baseflight_FW_150711.rar

Current Version Is Tested and feels equal to Arduino version.
A text file with all CLI commands i used for setup is included in the dev.
Also a Backup on my PID's.

The tests have been done with a NAZE32 Acro in the same plane as in the setup guide at.
http://fotoflygarn.blogspot.se/2014/04/ ... plane.html
http://fotoflygarn.blogspot.com/2015/01 ... dwing.html

/PatrikE

PatrikE · Post by **PatrikE** » Thu Apr 10, 2014 8:20 pm

This settings is available in CLI.
Maximum Limits for controls

Code: Select all

set gps_maxcorr = 15   // Degrees banking Allowed by GPS.
set gps_rudder = 15     // Maximum Rudder

set gps_maxclimb = 15    // Degrees climbing . Too much can stall the plane.
set gps_maxdive = 15     // Degrees Diving . Too much can overspeed the plane.

set climb_throttle = 1900    // Max allowed throttle in GPS modes.
set cruice_throttle = 1600   // Throttle to set for cruise speed.

set idle_throttle = 1300  // Lowest throttleValue during Descend
set scaler_throttle = 8    // Adjust to Match Power/Weight ratio of your model

Plüschi · Post by **Plüschi** » Thu Apr 10, 2014 10:27 pm

Good instructions on how to get that to compile are here:
https://github.com/multiwii/baseflight/ ... th-Eclipse

And in case you are stuck with the "undefined reference to `_sbrk'" error you comment out "pch = strtok(cmdline, " ");" in cliMotor() file cli.c

Edit:
As treym told me a better way is to edit the makefile and add the #lib part from here:
https://github.com/treymarc/baseflight/ ... r/Makefile
and add this file to the source directory
https://github.com/treymarc/baseflight/ ... ib_stubs.c

treym · Post by **treym** » Thu Apr 10, 2014 10:59 pm

And in case you are stuck with the "undefined reference to `_sbrk'" error you comment out "pch = strtok(cmdline, " ");" in cliMotor() file cli.c

or .. if you build with newLib :

Code: Select all

/*
 sbrk
 Increase program data space.
 Malloc and related functions depend on this
 */
caddr_t _sbrk(int incr)
{
    extern char _ebss; // Defined by the linker
    static char *heap_end;
    char *prev_heap_end;

    if (heap_end == 0) {
        heap_end = &_ebss;
    }
    prev_heap_end = heap_end;

    char * stack = (char*)__get_MSP();
    if (heap_end + incr > stack) {
        errno = ENOMEM;
        return (caddr_t)-1;
    }

    heap_end += incr;
    return (caddr_t)prev_heap_end;

}

msev · Post by **msev** » Fri Apr 11, 2014 12:19 am

PatrikE you were talking about the GUI in the other thread of yours, for baseflight there is a very nice "Baseflight Chrome Configurator" app by cTn, source for it is posted on github,...I think after the functionality is tested & hopefully merged into baseflight master branch, cTn will be glad to make selecting the various option more GUI friendly,..you/we'll just have to politely ask him.

Congrats about porting the code! This will be really nice for all fixed wing fpv-ers.

crashlander · Post by **crashlander** » Fri Apr 11, 2014 12:52 pm

Anybody successfully flashed vdjc's hex on AfroMini?
I'm using Chrome Baseflight Configurator and each time I flash that HEX I get completely unresponsive (dead) board.
To recover I have to short BootLoader pads and flash original Baseflight, from which I can again and again flash original Baseflight without BootLoader pads shorted.

Regards
Andrej

crashlander · Post by **crashlander** » Fri Apr 11, 2014 12:54 pm

Another observation: vdjc's HEX (file size) is half the size of TC's?!

crashlander · Post by **crashlander** » Fri Apr 11, 2014 1:09 pm

I ve just recompiled it myself and it works...
..it works in GUI and I can set new parameters.
So it seems that HEX in GIT is somehow corrupt!

Regards
Andrej

PatrikE · Post by **PatrikE** » Fri Apr 11, 2014 2:02 pm

crashlander wrote:Anybody successfully flashed vdjc's hex on AfroMini?
I'm using Chrome Baseflight Configurator and each time I flash that HEX I get completely unresponsive (dead) board.
To recover I have to short BootLoader pads and flash original Baseflight, from which I can again and again flash original Baseflight without BootLoader pads shorted.

Regards
Andrej

I get the same now.

vdjc moved settings to CLI.
After that Cli dont work.

The Hex before that worked.

crashlander · Post by **crashlander** » Fri Apr 11, 2014 2:20 pm

Mine working attached:

baseflight_NAZE.hex.zip: HEX; (84.9 KiB) Downloaded 1038 times

PatrikE · Post by **PatrikE** » Fri Apr 11, 2014 3:15 pm

Thanks Andrej.
This Hex works.

I see this.

gps_maxcorr = 15 -180 180
gps_rudder = 15 -180 180
gps_maxclimb = 15 -180 180
gps_maxdive = 15 -180 180

18 degrees limiting Max/Min is ok for testing.
I have flown mine with 25 degrees Maxcorr.
But 45 would be better if you want more precise/distinct navigation.

But This can be on the todo list to change.

Patrik

vdjc · Post by **vdjc** » Fri Apr 11, 2014 3:46 pm

PatrikE wrote:vdjc moved settings to CLI.
After that Cli dont work.
The Hex before that worked.

I've did a full rebuild and re-uploaded the hex. Seems to work now.

PatrikE wrote:18 degrees limiting Max/Min is ok for testing.
I have flown mine with 25 degrees Maxcorr.
But 45 would be better if you want more precise/distinct navigation.

I've tried to guess limit values, but without really understanding what they're doing.
I can modify this, or let you or someone else change them by giving access to the repo on github.

bhines · Post by **bhines** » Fri Apr 11, 2014 11:41 pm

Does RTH need magnetometer to function properly? gonna try it with a mininaze32

crashlander · Post by **crashlander** » Sat Apr 12, 2014 5:46 am

It does not need compass.

Rgards
Andrej

scrat · Post by **scrat** » Mon Apr 14, 2014 7:43 am

As far as I know, RTH needs magnetometer to function properly.

crashlander · Post by **crashlander** » Mon Apr 14, 2014 8:06 am

scrat wrote:As far as I know, RTH needs magnetometer to function properly.

RTH and PH on multi copters need compas/magnetometer to operate (since copters are/can be stationary)!
For fixed wing (that can not fly without horizontal speed/vector) heading can be/is obtained from there!

Regards
Andrej

PatrikE · Post by **PatrikE** » Mon Apr 14, 2014 1:05 pm

The code works perfect without magnetometer.
Ground course from Gps is predictable as long as you stay in motion.
And most planes don't hover normally.
Yes It can soar like a kite in headwind.
But theres a function to detect it and increase throttle to maintain forward speed.

msev · Post by **msev** » Tue Apr 15, 2014 1:50 pm

Has anyone flight-tested this already? :-)

... Are there any pointers/is there a way on how to ground-test the functionality before actual tests in the air?

PatrikE · Post by **PatrikE** » Tue Apr 15, 2014 2:05 pm

I haven't heard of any test yet.
If you use EOS gps simulator you should be able to benchtest.

I hope to be able to do some flighttest during the week.
Hopefully the wind will calm down a bit!
5 - 10m/s is not perfect for initial testing!

The actual code is basically same as in Arduino.
Some things is not correct but it shouldn't affect rth.
Home Pos is reset at ARM that's to be changed.
Not good if you accidentally Disarm/Arm in air!

Otherwise i've mentioned the most in the first posts.

PatrikE · Post by **PatrikE** » Sat Apr 19, 2014 12:23 pm

A new Hex file is available in the first pos.
viewtopic.php?f=23&t=4934

FlightTested and ready for further testers.

Happy easter..

PatrikE

msev · Post by **msev** » Sat Apr 19, 2014 12:49 pm

Great news that you flight-tested it and it works as expected!

vdjc · Post by **vdjc** » Sun Apr 20, 2014 5:26 pm

The code on github has just been updated with the latest sources from Patrick:
https://github.com/sbaron/baseflight/tree/rth_dev

crashlander · Post by **crashlander** » Sun Apr 20, 2014 5:48 pm

<EDIT>
I just saw that line in mw.c

Code: Select all

if ((failsafeCnt > 5 * (cfg.failsafe_delay + cfg.failsafe_off_delay)) && !f.FAILSAFE_RTH_ENABLE)

that disables that delay...
</EDIT>

I'm missing arduino alternative of

Code: Select all

#define FAILSAFE_OFF_DELAY

In MWII I increase this value to 6000+ (I do not want my plane to shutdown after 30s of FS RTH flight).

Regards
Andrej

PatrikE · Post by **PatrikE** » Sun Apr 20, 2014 8:42 pm

No need to increase failsafe_off_delay.
It is only active if f.FAILSAFE_RTH_ENABLE is false...

Code: Select all

if ((failsafeCnt > 5 * (cfg.failsafe_delay + cfg.failsafe_off_delay)) && !f.FAILSAFE_RTH_ENABLE)

f.FAILSAFE_RTH_ENABLE is only true for FixedWing in falisafe and with GPSFix.!

If there's no Gps fix it will go in normal falsafe and Disarm
A 5 degree bank is added and the plane will be disarmed after failsafe_off_delay.
And you don't want the plane to continue flying in falsafe for ever.

Plüschi · Post by **Plüschi** » Mon Apr 21, 2014 8:08 pm

For the first test i need some more info:

- was the version tested with NMEA or UBX-binary GPS ?

- I dont want climbout. How do i disable ?

- I dont want altitude control. Plane will be 100% visual, i to want build up confidence in RTH. How do i disable altitude control ?

- I dont want any fancy failsave features. How do i disable ?

Plane is Easystar2, Afromini controller.

PatrikE · Post by **PatrikE** » Mon Apr 21, 2014 9:58 pm

Being cautious is never wrong.
Easystar is same type of plane as i tested the code on.

- was the version tested with NMEA or UBX-binary GPS ?

I have only tested NMEA.
But on Arduino I know I2C works equal.
If Ublox works on copters it should work for planes to.

With CLI Tweaking, This should disable Altitude and throttle code as much as possible.

Code: Select all

set climb_throttle = xxxx // Set to same as cruicethrottle value...
set gps_maxdive = 0
set gps_maxclimb = 0
set scaler_throttle = 1

Throttle will still vary a little depending on AltError.
The climbout flag will still be set below RTH Altitude.

- I dont want any fancy failsave features. How do i disable ?

Don't enable...

Code: Select all

feature FAILSAFE
feature FAILSAFE_RTH

Will give you Switch selected RTH Only.
But i recommend feature FAILSAFE as it will Cut throttle and circle down the plane.

I'm not sure how the plane will react on this Hacks.
I think it's safer to just disable Failsafe RTH.

Good luck Testing...
Patrik

crashlander · Post by **crashlander** » Mon Apr 28, 2014 5:30 pm

Just back from the field and BaseFlight RTH is tested and WORKING!
Equipment used:
Assassin wing (from Crash Test Hobby)
AfroMini 32 (thanks TC for wonderful mini FC and BaseFlight)
Ublox NEO-5
Orange OpenLRS (OpenLRSng)

Thank you Patrik!

Regards
Andrej

crashlander · Post by **crashlander** » Wed Apr 30, 2014 8:13 pm

In BaseFlight I'm missing MWII' s alternative of

Code: Select all

#define GYRO_SMOOTHING

Since I can not remove fast dive elevon oscillation (on pitch) even when I set

Code: Select all

set gyro_lpf = 10

in CLI.
Second observation is that my wing always "rocket" (with high pitch angle) into climb when it is lower than set height and RTH is enabled even if I set

Code: Select all

set gps_maxclimb = 10

I'm flying in HORIZON mode and that one is also enabled with RTH functions.

Regards
Andrej

PatrikE · Post by **PatrikE** » Wed Apr 30, 2014 9:43 pm

With some sarcastic comment GYRO_SMOOTHING was removed from Baseflight source just before i checked it out for merging.
Because No one was using it.
MPU6050 is more sensitive than ITG gyros.

RTH is actually intended for Failsafe and not a normal flightmode.
The "Rocket Launch" is to ensure it will reach altitude as fast as possible.

Some sort of GYRO_SMOOTHING is probably needed for FlyingWings.
LPF is not enough.

timecop · Post by **timecop** » Thu May 01, 2014 1:19 am

Yeah. It was removed because its implementation was kinda poop, as well as setting it (was a 32bit int that people would had to calculate with a binary calculator or something, who'd do that in 2014?).

If there's a clean patch to make this work again, I'll be glad to re-include it. And I don't mean just re-introducing old code

Speaking of patches, if anyone feels like cleaning up and submitting this into baseflight, assuming it follows https://github.com/multiwii/baseflight/wiki/CodingStyle and doesn't break anything else, it will be accepted

Plüschi · Post by **Plüschi** » Thu May 01, 2014 2:15 am

PatrikE wrote:Some sort of GYRO_SMOOTHING is probably needed for FlyingWings.

Would a lower P or/and I value not be better at solving oscillation?
We should not compensate wrong PID values by shooting the sensor in the knee.

crashlander · Post by **crashlander** » Thu May 01, 2014 5:35 am

PatrikE wrote:RTH is actually intended for Failsafe and not a normal flightmode.
The "Rocket Launch" is to ensure it will reach altitude as fast as possible.

It seems that current (Baseflight) code does not use safe max climb parameter (set gps_maxclimb) as set in CLI and would probably stall underpowered planes.

Regards
Andrej

crashlander · Post by **crashlander** » Thu May 01, 2014 5:40 am

Plüschi wrote:
PatrikE wrote:Some sort of GYRO_SMOOTHING is probably needed for FlyingWings.

Would a lower P or/and I value not be better at solving oscillation?
We should not compensate wrong PID values by shooting the sensor in the knee.

In that case only use of airspeed sensor and some kind of "TPA" (APA) based on that would be nice.

Regards
Andrej

PatrikE · Post by **PatrikE** » Thu May 01, 2014 10:35 am

crashlander wrote:It seems that current (Baseflight) code does not use safe max climb parameter (set gps_maxclimb) as set in CLI and would probably stall underpowered planes.

Regards
Andrej

The limits is applied same way as for Ardu version.
Elevator compensation is added after limiting is done.
It can be why it seems to not work.

Below 20 meters the wings should be level and no elevator compensation added.
After 20m it's allowed to start navigate and elevator is added equal to Roll angle.
If the plane banks ~45 it will add 450µs to elevator.( Almost Full up )

I have seen it on my HK RadJet too.(Arduino board)
First a nice accent to 20m and shoots skywards when it starts navigate.
On the Bixler type it's not so visual.

Climbout flag forces max climb, Elevator Compensation on that Can be BAD.
Maybe check the Climbout flag before allowing compensation would be a solution.
Or cancel climbout after 20m and use alterror + compensation
Today It keeps Full climb + compensation until altitude is reached.

I use Angle mode in GPS modes.
Passthru, Acro or Horizon for flying.

Patrik

PatrikE · Post by **PatrikE** » Thu May 01, 2014 10:43 am

A airspeed sensor would be optimal and "TPA" (APA) based on that would be nice.
But we can use the fact that we know the angle of attack and throttle and feed "APA" with it.

crashlander · Post by **crashlander** » Thu May 01, 2014 1:45 pm

PatrikE wrote:A airspeed sensor would be optimal and "TPA" (APA) based on that would be nice.
But we can use the fact that we know the angle of attack and throttle and feed "APA" with it.

That would produce bad oscilations after fast dive, during recovery...

crazyal · Post by **crazyal** » Thu May 01, 2014 2:09 pm

I took vdjcs baseflight commit and cleaned it up a bit. The formatting should be allright now, but the global vars shared between gps.c and fw_nav.c are still unclean and should be changed into a clean struct according to timecop.
If anyone wants to proceed with it, here is my change: https://github.com/luggi/baseflight/com ... 8a34e52455

crashlander · Post by **crashlander** » Fri May 02, 2014 5:42 pm

I have seen it on my HK RadJet too.(Arduino board)
First a nice accent to 20m and shoots skywards when it starts navigate.
On the Bixler type it's not so visual.

O.K. I understand it is true that my BaseFlight wing is very different from my Ardu one (faster and more agile/overpowered).
I have lowered gps_maxclimb to 8 and now it look's nicer.

Probably any solution that would not add climbout and elevator compensation together would be O.K. (maybe zeroing compensation while climbout is active?).

Regards
Andrej

PatrikE · Post by **PatrikE** » Fri May 02, 2014 10:11 pm

I have tested to cancel ElevComp But then the climbout feels lame.
gps_maxclimb = 15 degrees.
I guess without compensation gps_maxclimb could be set higher.
And maybe just limit compensation during Climbout.(Next test...)

Patrik

PatrikE · Post by **PatrikE** » Fri May 02, 2014 10:21 pm

Oscillations Is not related to RTH But planes in general.

MPU feels more sensitive on Baseflight or something.
I get oscillations on my test plane with lpf 42 hz.
With the Arduino i run with 256 hz on the ITG3200.

Or should MPU6050 be that much more sensitive?

Since Gyro smoothing worked but was shooting it in the knee.
I'm thinking Why not shoot it in both knees to perform better on planes!
Copters react fast on Gyro but planes is slow in reaction.
Fast compensations is also harmful for the servos.

And since LPF_10_HZ Is still not good as crashlander says.
What can we do then?
True airspeed would mean a more complex setup.( Mpu + Gps should be enough )
Radical PID tuning?
Increase Cykletime?
Scale down Gyrovalues?

Averaging Gyro works fine on planes to smoothen the outputs.
Maybe averaging outputs instead?

Any Idéas?

Patrik

Plüschi · Post by **Plüschi** » Sat May 03, 2014 1:27 am

Me no expert but lets brainstorm:

Thy gyro LPF is here to flatten out vibrations. What it does is to slow down the control loop and introduce a delay. A 10HZ LPF will average measurements over 100ms and introduce 50ms delay (about). The SAME effect can be had by drastically lowering the PID P term. PID I and D terms are a function of the P term and need to be adjusted as well.

Another point is the Level PID values for roll and pitch may be very different on a plane.

I did have a notoriously shaky brushed-geared micro-quad where PID was very hard to adjust. Then i read about using ziegler-nichols to calculate PID factors, and i did use that with an AUX channel as input to ziegler-nichols for testing. This was a 328 tarduino and did fly as smooth as silk ever after.

Note FREQ_TU_PR is oscillation frequency of micro quad, might be much lower (and different roll / pich) on plane:

Code: Select all


#define FREQ_TU_PR 3 

    #if defined(DIAL_TUNING)
      int ku;
      int kp;
      #if defined(POT_PR)  // aux channel for gyro PID
        ku = ((constrain(rcData[POT_PR],1000,2000) -1000) << 1) >> 6 ; // * 20/640;
        kp = ku * 3 ;
        conf.pid[PIDROLL].P8 = kp;
        conf.pid[PIDROLL].I8 = (kp << 1)/FREQ_TU_PR;
        conf.pid[PIDROLL].D8 = (kp * FREQ_TU_PR) >> 3;
        conf.pid[PIDPITCH].P8 = kp;
        conf.pid[PIDPITCH].I8 = (kp << 1)/FREQ_TU_PR;
        conf.pid[PIDPITCH].D8 = (kp * FREQ_TU_PR) >> 3;
      #endif
      #if defined(POT_L)  // aux channel for level PID
        ku = ((constrain(rcData[POT_L],1000,2000) -1000) << 1) >> 6 ; // * 20/640;
        kp = ku * 4 ;
        conf.pid[PIDLEVEL].P8 = kp;
        conf.pid[PIDLEVEL].I8 = (kp << 1)/FREQ_TU_PR;
      #endif
    #endif

Unluckily im not able to walk and to test fly this myself atm.

treym · Post by **treym** » Sun May 04, 2014 11:05 pm

POS.HOLD will maintain (as best as possible) plane's 3D position by doing figure 8 or circles using cruise throtle.

looks like it work

Truglodite · Post by **Truglodite** » Mon May 12, 2014 8:33 am

I'm feeling a bit humbled trying to get this working on my wing (no tail). Looks like flying wing is no longer included as a CLI option (correct?), and I get errors compiling rth_dev. I'm not familiar enough with the environment to decipher what's going wrong with this error, but I have no problems compiling normal baseflight and harakiri for my copters using the same procedure. I was going to look in to editing the mixers for my purposes, but I don't want to start if I can't finish. I copied the error output below.

Code: Select all

Finished building: ../lib/CMSIS/CM3/CoreSupport/core_cm3.c
 
Building target: Baseflight_rth_dev.elf
Invoking: ARM Sourcery Windows GCC C Linker
arm-none-eabi-gcc -T"C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\workspace\Baseflight_rth_dev\stm32_flash.ld" -Xlinker --gc-sections -Wl,-Map,Baseflight_rth_dev.map -mcpu=cortex-m3 -mthumb -o "Baseflight_rth_dev.elf"  ./src/baseflight_startups/startup_stm32f10x_md_gcc.o  ./src/buzzer.o ./src/cli.o ./src/config.o ./src/drv_adc.o ./src/drv_adc_fy90q.o ./src/drv_adxl345.o ./src/drv_bma280.o ./src/drv_bmp085.o ./src/drv_gpio.o ./src/drv_hcsr04.o ./src/drv_hmc5883l.o ./src/drv_i2c.o ./src/drv_i2c_soft.o ./src/drv_l3g4200d.o ./src/drv_ledring.o ./src/drv_mma845x.o ./src/drv_mpu3050.o ./src/drv_mpu6050.o ./src/drv_ms5611.o ./src/drv_pwm.o ./src/drv_pwm_fy90q.o ./src/drv_serial.o ./src/drv_softserial.o ./src/drv_spi.o ./src/drv_system.o ./src/drv_timer.o ./src/drv_uart.o ./src/fw_nav.o ./src/gps.o ./src/imu.o ./src/main.o ./src/mixer.o ./src/mw.o ./src/printf.o ./src/sbus.o ./src/sensors.o ./src/serial.o ./src/spektrum.o ./src/sumd.o ./src/telemetry_common.o ./src/telemetry_frsky.o ./src/telemetry_hott.o ./src/utils.o  ./lib/STM32F10x_StdPeriph_Driver/src/misc.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_adc.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_bkp.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_can.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_cec.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_crc.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_dac.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_dbgmcu.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_dma.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_exti.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_flash.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_fsmc.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_gpio.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_i2c.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_iwdg.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_pwr.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_rcc.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_rtc.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_sdio.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_spi.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_tim.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_usart.o ./lib/STM32F10x_StdPeriph_Driver/src/stm32f10x_wwdg.o  ./lib/CMSIS/CM3/DeviceSupport/ST/STM32F10x/system_stm32f10x.o  ./lib/CMSIS/CM3/CoreSupport/core_cm3.o   -lm
c:/program files (x86)/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/thumb2\libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text+0x12): undefined reference to `_sbrk'
collect2.exe: error: ld returned 1 exit status
cs-make: *** [Baseflight_rth_dev.elf] Error 1

Can anyone help point me in the right direction to get my AfroMini working on my wing?

Kev

timecop · Post by **timecop** » Mon May 12, 2014 8:43 am

mixer flying_wing works, no?
you shouldn't have to edit anything.
sbrk shit is some gnu garbage, stop using codesourcery and ONLY use gcc-arm-embedded and don't generate makefiles in eclipse, only use provided Makefile

Truglodite · Post by **Truglodite** » Mon May 12, 2014 8:56 am

Showing my newbness here... got it figured out and found the mixer. Thanks again timecop.

Kev

subaru4wd · Post by **subaru4wd** » Fri May 16, 2014 7:03 am

Im setting up an AfroMini for my FPV Plane. Im not sure exactly what servo's go where? It is a 3 channel plane, and I assume the motor ESC goes on THR, but i have two servo's for the Ailerons and one for Elevator and i am not sure which S pins to use for which.

PatrikE · Post by **PatrikE** » Fri May 16, 2014 8:34 am

Im not 100% sure but I think i connected like this.

Code: Select all

6 => Elevator
5 => Rudder
4 => Wing 2
3 => Wing 1
2 => -
1 => ESC

Truglodite · Post by **Truglodite** » Fri Jun 06, 2014 11:37 pm

I have flown my flyingwing to some degree of success with Plane RTH firmware (rate, stab, passthrough fly well). It just needs some more up elevator travel to slow for landing. I started to play in the servo tab and ran in to troubles. I read this post by crashlander about servo setup, but it doesn't elaborate on how to deal with elevon mixing:

http://fpvlab.com/forums/showthread.php ... post493533

I played with the checkboxes and values; they had effects but I couldn't brew up what I need. This plane needs full mechanical up travel, without servos stalling from roll stick or roll gyro input (bigger digital servos too... stall is very bad). Baseflight must have a global servo travel setting, but I don't know where to find it. An example of what I mean by global travel... in OpenAero2 (for KK2), you have one page where you can set travels for each servo so they don't bind no matter what you do with the tuning and rates. Then there's another page on OA2 where the user can adjust pitch/roll rates independently, and of course there are gyro PIDs.

I can find the pitch and roll rates, and of course the PIDs in the GUI, but not the definitive "left wing servo limits" and "right wing servo limits" I was hoping to find. Can baseflight do this? If so, can someone point me to the right settings?

Thanks,
Kev

PatrikE · Post by **PatrikE** » Sat Jun 07, 2014 1:48 pm

In baseflight you can adjust Rates per axis from CLI Tab.
set fixedwing_rollrate = 0.500
set fixedwing_pitchrate = 0.500
Range 0 - 1.0

And Setting Min & Max in servoTab should set absolute endpoints for each servo.

Truglodite · Post by **Truglodite** » Sat Jun 07, 2014 7:52 pm

Thanks PatrickE... to be complete regarding the servoTab Min/Max... I should apply full elevator and aileron on my TX when setting the servo enpoints, correct? Ie... up/right makes R servo go max up, set R servo up... down/left makes R servo go max down, set R servo down... etc repeat using up/left and down/right to set L servo limits... correct? I was kind of hoping my TX wouldn't be required, but I guess if this works then it's good enough.

Kev