lkaino / Triflight

Triflight flight controller firmware for tricopters
http://rcexplorer.se
GNU General Public License v3.0
50 stars 19 forks source link

A simpler calculation of tri_tail_motor_thrustfactor #28

Closed Bengt-M closed 8 years ago

Bengt-M commented 8 years ago

I have mentioned this possibility before. Here it is. For me it passes the same unit test.

Bengt-M commented 8 years ago

I'm still not used to how things I do on my laptop propagates to the PR at GitHub/Triflight. After the last merge I did one rebase too much and all comments disappeared. Anyway, here is a small analysis regarding the limits:

A prop with a higher factor must have less drag and must produce more thrust per watt. That is not easy to do. The prop selected by David W is pretty good. Let's say we can find another one which is double good (but then I think David would have chosen that one already). If our prop have a factor of 14, I'd say its unlikely we find another one with a factor >30, because I think that would mean that the drag is half. That corresponds to an angle = 91.9 deg. Remove the misalignment from bad bench tuning. 1 deg is cleary visible. Gives us 90.9. So 90.5 (factor=114) should be on the safe side. Your current function stops at 90.15 deg but I don't see how that can happen. I don't think a prop can be that good. (if so, where can I buy it?) At even lower angles the factor grows very rapidly into indefinit at 90 (divide by 0).

In the other direction; how bad prop can we have? Four times worse? (Who would buy it?) A factor at 14/4 corresponds to 106 deg. Add one for misalignment gives 107 deg. Say 120 to be safe.

So 90.5 .. 120 deg is a reasonable and not unrealistic range, given that the bench tuning is good. If we put 90.01 .. 180 there would never be a failed tuning and we can remove the check completely.

Does this make sense or did I miss something here?

Bengt-M commented 8 years ago

We have a problem. After the latest changes lkaino/Triflight:master still builds fine. But with this PR it won't. It worked before the recent changes and for me its strange. The PR should make it smaller, not bigger. Look here:

arm-none-eabi-gcc -o obj/main/triflight_NAZE.elf obj/main/NAZE/startup_stm32f10x_md_gcc.o obj/main/NAZE/drivers/accgyro_adxl345.o obj/main/NAZE/drivers/accgyro_bma280.o obj/main/NAZE/drivers/accgyro_l3g4200d.o obj/main/NAZE/drivers/accgyro_mma845x.o obj/main/NAZE/drivers/accgyro_mpu.o obj/main/NAZE/drivers/accgyro_mpu3050.o obj/main/NAZE/drivers/accgyro_mpu6050.o obj/main/NAZE/drivers/accgyro_mpu6500.o obj/main/NAZE/drivers/accgyro_spi_mpu6500.o obj/main/NAZE/drivers/adc.o obj/main/NAZE/drivers/adc_stm32f10x.o obj/main/NAZE/drivers/barometer_bmp085.o obj/main/NAZE/drivers/barometer_ms5611.o obj/main/NAZE/drivers/barometer_bmp280.o obj/main/NAZE/drivers/bus_spi.o obj/main/NAZE/drivers/bus_i2c_stm32f10x.o obj/main/NAZE/drivers/compass_hmc5883l.o obj/main/NAZE/drivers/display_ug2864hsweg01.o obj/main/NAZE/drivers/flash_m25p16.o obj/main/NAZE/drivers/gpio_stm32f10x.o obj/main/NAZE/drivers/inverter.o obj/main/NAZE/drivers/light_led_stm32f10x.o obj/main/NAZE/drivers/light_ws2811strip.o obj/main/NAZE/drivers/light_ws2811strip_stm32f10x.o obj/main/NAZE/drivers/sonar_hcsr04.o obj/main/NAZE/drivers/pwm_mapping.o obj/main/NAZE/drivers/pwm_output.o obj/main/NAZE/drivers/pwm_rx.o obj/main/NAZE/drivers/serial_softserial.o obj/main/NAZE/drivers/serial_uart.o obj/main/NAZE/drivers/serial_uart_stm32f10x.o obj/main/NAZE/drivers/sound_beeper_stm32f10x.o obj/main/NAZE/drivers/system_stm32f10x.o obj/main/NAZE/drivers/timer.o obj/main/NAZE/drivers/timer_stm32f10x.o obj/main/NAZE/io/flashfs.o obj/main/NAZE/hardware_revision.o obj/main/NAZE/flight/gtune.o obj/main/NAZE/flight/navigation.o obj/main/NAZE/flight/gps_conversion.o obj/main/NAZE/common/colorconversion.o obj/main/NAZE/io/gps.o obj/main/NAZE/io/ledstrip.o obj/main/NAZE/io/display.o obj/main/NAZE/telemetry/telemetry.o obj/main/NAZE/telemetry/frsky.o obj/main/NAZE/telemetry/hott.o obj/main/NAZE/telemetry/smartport.o obj/main/NAZE/telemetry/ltm.o obj/main/NAZE/sensors/sonar.o obj/main/NAZE/sensors/barometer.o obj/main/NAZE/blackbox/blackbox.o obj/main/NAZE/blackbox/blackbox_io.o obj/main/NAZE/build_config.o obj/main/NAZE/debug.o obj/main/NAZE/version.o obj/main/NAZE/config/config.o obj/main/NAZE/config/runtime_config.o obj/main/NAZE/common/maths.o obj/main/NAZE/common/printf.o obj/main/NAZE/common/typeconversion.o obj/main/NAZE/common/encoding.o obj/main/NAZE/common/filter.o obj/main/NAZE/scheduler.o obj/main/NAZE/scheduler_tasks.o obj/main/NAZE/main.o obj/main/NAZE/mw.o obj/main/NAZE/flight/altitudehold.o obj/main/NAZE/flight/failsafe.o obj/main/NAZE/flight/pid.o obj/main/NAZE/flight/imu.o obj/main/NAZE/flight/mixer.o obj/main/NAZE/flight/mixer_tricopter.o obj/main/NAZE/drivers/bus_i2c_soft.o obj/main/NAZE/drivers/serial.o obj/main/NAZE/drivers/sound_beeper.o obj/main/NAZE/drivers/system.o obj/main/NAZE/drivers/dma.o obj/main/NAZE/drivers/buf_writer.o obj/main/NAZE/drivers/gyro_sync.o obj/main/NAZE/io/beeper.o obj/main/NAZE/io/rc_controls.o obj/main/NAZE/io/rc_curves.o obj/main/NAZE/io/serial.o obj/main/NAZE/io/serial_1wire.o obj/main/NAZE/io/serial_cli.o obj/main/NAZE/io/serial_msp.o obj/main/NAZE/io/statusindicator.o obj/main/NAZE/rx/rx.o obj/main/NAZE/rx/pwm.o obj/main/NAZE/rx/msp.o obj/main/NAZE/rx/sbus.o obj/main/NAZE/rx/sumd.o obj/main/NAZE/rx/sumh.o obj/main/NAZE/rx/spektrum.o obj/main/NAZE/rx/xbus.o obj/main/NAZE/rx/ibus.o obj/main/NAZE/sensors/acceleration.o obj/main/NAZE/sensors/battery.o obj/main/NAZE/sensors/boardalignment.o obj/main/NAZE/sensors/compass.o obj/main/NAZE/sensors/gyro.o obj/main/NAZE/sensors/initialisation.o obj/main/NAZE/core_cm3.o obj/main/NAZE/system_stm32f10x.o obj/main/NAZE/stm32f10x_gpio.o obj/main/NAZE/stm32f10x_fsmc.o obj/main/NAZE/stm32f10x_exti.o obj/main/NAZE/stm32f10x_bkp.o obj/main/NAZE/stm32f10x_spi.o obj/main/NAZE/stm32f10x_adc.o obj/main/NAZE/stm32f10x_iwdg.o obj/main/NAZE/misc.o obj/main/NAZE/stm32f10x_wwdg.o obj/main/NAZE/stm32f10x_tim.o obj/main/NAZE/stm32f10x_usart.o obj/main/NAZE/stm32f10x_flash.o obj/main/NAZE/stm32f10x_rcc.o obj/main/NAZE/stm32f10x_sdio.o obj/main/NAZE/stm32f10x_i2c.o obj/main/NAZE/stm32f10x_pwr.o obj/main/NAZE/stm32f10x_rtc.o obj/main/NAZE/stm32f10x_dac.o obj/main/NAZE/stm32f10x_dbgmcu.o obj/main/NAZE/stm32f10x_dma.o -lm -nostartfiles --specs=nano.specs -lc -lnosys -mthumb -mcpu=cortex-m3 -flto -fuse-linker-plugin -Os -ggdb3 -DDEBUG -static -Wl,-gc-sections,-Map,./obj/main/triflight_NAZE.map -Wl,-L./src/main/target -Wl,--cref -T./src/main/target/stm32_flash_f103_128k.ld c:/program files (x86)/gnu tools arm embedded/4.9 2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe: obj/main/triflight_NAZE.elf section .text' will not fit in regionFLASH' c:/program files (x86)/gnu tools arm embedded/4.9 2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe: region `FLASH' overflowed by 3620 bytes collect2.exe: error: ld returned 1 exit status Makefile:845: recipe for target 'obj/main/triflight_NAZE.elf' failed make: *\ [obj/main/triflight_NAZE.elf] Error 1

lkaino commented 8 years ago

Your reasoning of the limits is valid, let's make it 90.5 .. 120.

The problem with size is most likely related to the fact that the double version of tan() is not used anywhere in the code, thus it has been cleaned by garbage collection. Might be that the tan() is dependent on other double precision functions that need to be included as well. It seems that the float version is not used either, but you could try using tan_approx() and see what happens.

Bengt-M commented 8 years ago

New update committed. You where right abut the tan size. 1/tan_approx didn't help at first so I changed to cos_approx/sin_approx Now it builds.

lkaino commented 8 years ago

Thanks, I'll go test it.

Bengt-M commented 8 years ago

I hope it went well. Please tell.

Thinking about if there is any other function I should dive into. The easy ones are OK and the difficult ones are, well, difficult.

I see you are not taking some real world effects into account. Like the disymetry of lift, and gyroscopic precession. These are important for full scale helis but here I'm not sure.

I'm not a good enough pilot and I haven't got my blackbox working but I'm sure the best way to find model errors is to watch the I term in the PID. If the model is perfect the I would only deal with external slow errors like wind.

That would be interesting to know because it would surely mean that the effects as above have some significance.

lkaino commented 8 years ago

The test went well, works as before. I added some more filtering to the input samples to get the results more consistent. Worked to some extent.

Noy everything is modeled here, I have been staring at blackbox logs trying to figure out the most essential ones abd started modeling those. If you have time, please go ahead and try them. I would like to play around more with this but I have more profitable projects that need my effort as well :).

Please try stuff, it's hard to know what is worth modeling and what is waste of computation time. There's one really interesting issue I'm having now when the copter has more yaw authority at low throttle. I will write about it in the forums when I get time. You could try to think some solution for that :).

Bengt-M commented 8 years ago

Please commit and push the src, even if it's not release yet (no need to commit the hex).

Extra pre-filtering doesn't sound as the right way. You probably get some improvement because you extend the averaging time, but you will also include errors that are remaining in that LPF but not caught by the sampling criteria. An average over longer time is a more direct way and then every sample will have passed the criteria.

Currently the code tries to sample every 10 ms and do 300 samples. That should finish in 3 s, but it never does. Or maybe it does but we have to wait for the beeper queue to finish. Every beep need 220 ms so maybe we should try to beep only every 10-20 sample or so, as discussed before.

Suggest changing 10 to 30 is a simple test that would have more effect than pre-filtering.

lkaino commented 8 years ago

I'll commit it soon. Currently it consists of 20+ commits, need to squash them. Don't know how to create a merge commit to my own fork.

Bengt-M commented 8 years ago

Well you don't do it on GitHub. You do it locally and then push.But first fetch and rebase on the new master so you don't loose my PR's. If you use Eclipse I've found the way to squash is in the (Git) History view. I can select a series of commits and with rightclick do Modify::Squash. But if I was to do a complex merge I would commit and push (and then fetch again) as is first of all anyway. Then I would be able to delete the project locally and import it again if I messed up completely. It has happened. Provided I had been working on a separate branch; One time I was working on the master (not good) and it was more tricky to reset it as I wanted it.

2016-05-07 17:26 GMT+02:00 lkaino notifications@github.com:

I'll commit it soon. Currently it consists of 20+ commits, need to squash them. Don't know how to create a merge commit to my own fork.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/lkaino/Triflight/pull/28#issuecomment-217644111

lkaino commented 8 years ago

I was just wondering how can I merge bunch of commits like PRs are merged, so that the merge commit would contain link to the individual commits. Maybe they can be merged from a separate branch, but I'll rather squash them and push to master as one commit.

I use git daily but my experience with github is quite limited.

Bengt-M commented 8 years ago

With my limited experience I am fairly sure anyway. You can't do this on GitHub. You have to do it locally and then push to GitHub. If you want to keep the individual commits then you must not squash them.

Before you merge you must have the branches in order. You merge branches not commits.

If you are where I think you are, I think you should:

Then you should be able to merge branch improvements into master. Maybe you should rebase first, I'm not sure. Probably. Then push.

If you don't like the advice to push as is first you should anyway make a backup copy first. Copy the whole Triflight folder with git database, project and all. So you can start again if something goes wrong.

2016-05-07 20:58 GMT+02:00 lkaino notifications@github.com:

I was just wondering how can I merge bunch of commits like PRs are merged, so that the merge commit would contain link to the individual commits. Maybe they can be merged from a separate branch, but I'll rather squash them and push to master as one commit.

I use git daily but my experience with github is quite limited.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/lkaino/Triflight/pull/28#issuecomment-217661863