Cleanflight aka Multiwii port to STM32 F10x and F30x

dieterg · Post by **dieterg** » Tue Aug 26, 2014 2:50 pm

dominicclifton wrote:
dieterg wrote:Safety issue !!!!
I'm not a great writer so here the video, Cleanflight should not arm this way
https://www.youtube.com/watch?v=JTW5Bu4uLCI

Fixed last night, please re-test with latest binary.

Please can people always report bugs via the github issue tracker - of course, feel free to reference the bugs here and on IRC after submitting them

https://github.com/hydra/cleanflight/issues

this is working on my setup, thank you

dominicclifton · Post by **dominicclifton** » Tue Aug 26, 2014 10:16 pm

there have been a couple of minor bugs fixed today.

* mis-reporting of horizon mode to gui when arming (due to the recent flags cleanup).
* the other is a bug which could occur in rare edge cases and only if you configured aux channels for which weren't applicable if you then changed the rx mode to one with less aux channel.
* when angle and horizon mode were enabled at the same the error angle would be continuously reset resulting in unintended flight behavior.

the latter two are still a bugs in baseflight, maybe someone will back-port them - see https://github.com/hydra/cleanflight/co ... e692472ecc

latest cleanflight binary contains the fixes - please update!

stronnag · Post by **stronnag** » Wed Aug 27, 2014 7:19 pm

Has anyone tried cleanflight with GPS Hold and GPS Home?

Here's my experience. Until today, GPS Hold did not work. The machine would alway drift away (I believe the compass is well calibrated and not subject to interference). Today, with the latest firmware, it appeared to work. Emboldened, I flew away and engaged GPS Home. The machine returned to the home position, hovered at home for a few seconds, then violently flipped into the ground from about 10m up. Two bent motor mounts, one broken carbon prop, one severely bent tricopter tail boom. Ouch.Big rebuild.

dominicclifton · Post by **dominicclifton** » Thu Aug 28, 2014 12:19 am

I guess not recently stronnag! That sucks.

GPS navigation in baseflight (and thus cleanflight) is somewhat experimental. The code doesn't do very much sanitation of gps input and in the past i have noticed erroneous longitude/latitude values on my FrSky/OpenTX telemetry read-out. It wouldn't suprise me if bad gps data was the cause based on that experience.

Cleanflight has not changed the implementation of gps navigation, i have been waiting for patrikE's work to be completed before embarking on that. Only the gps initialisation code with regard to serial ports and SBAS mode is different in cleanflight vs baseflight.

Can you share with us your cleanflight config dump, details of the gps receiver you're using and anything else you can think of that might be useful. How far away were you when you enabled RTH, what other modes were active?

Please file an issue on the github issue page with the above requested info: https://github.com/hydra/cleanflight/issues

strepto · Post by **strepto** » Thu Aug 28, 2014 1:20 am

Ouch! Nasty.

Yes... I wouldn't trust the baseflight GPS code any further than I could throw my quad...

https://www.youtube.com/watch?v=waklINsuPOg

I would love to see improvement. IMO it's one of the things that is holding back this board in a big way. I know TC doesn't care about it, but the reality is, some people want the safety net for when they're flying a long way away and have radio problems. It's not just for DJI hoverers.

dominicclifton · Post by **dominicclifton** » Thu Aug 28, 2014 1:37 am

i totally agree strepto, making our aircraft safer is a good thing.

dopplerguru · Post by **dopplerguru** » Thu Aug 28, 2014 4:02 am

Have used GPS in baseflight and cleanflight on naze32 and they are both worse than useless. Cause random very fast loss of control - almost guaranteed to crash. After a few such crashes, I tried harakiri newest version, and it works excellent with GPS hold and rth. With newest harakiri firmware I have now flown over a thirty flights in GPS mode with no issues - even doing GPS hold and rth in 20+ knot winds. You should look at harakiri as a starting point to fix cleanflight GPS - don't reinvent the wheel.

brm · Post by **brm** » Thu Aug 28, 2014 6:54 am

dopplerguru wrote:Have used GPS in baseflight and cleanflight on naze32 and they are both worse than useless. Cause random very fast loss of control - almost guaranteed to crash. After a few such crashes, I tried harakiri newest version, and it works excellent with GPS hold and rth. With newest harakiri firmware I have now flown over a thirty flights in GPS mode with no issues - even doing GPS hold and rth in 20+ knot winds. You should look at harakiri as a starting point to fix cleanflight GPS - don't reinvent the wheel.

why not sticking with harakiri?
the bugs from the video above are quite clear.
never seen it so clear.
but it will take time to fix this.

brm · Post by **brm** » Thu Aug 28, 2014 6:56 am

strepto wrote:Ouch! Nasty.

Yes... I wouldn't trust the baseflight GPS code any further than I could throw my quad...

https://www.youtube.com/watch?v=waklINsuPOg

I would love to see improvement. IMO it's one of the things that is holding back this board in a big way. I know TC doesn't care about it, but the reality is, some people want the safety net for when they're flying a long way away and have radio problems. It's not just for DJI hoverers.

very good video.
makes clear where the missing pieces are.
the code, as far i remember this, does not handle altitude issues with RTH.
have a gps glitch filter in the back ... will need to test this soon.

strepto · Post by **strepto** » Thu Aug 28, 2014 11:25 am

dopplerguru wrote:Have used GPS in baseflight and cleanflight on naze32 and they are both worse than useless. Cause random very fast loss of control - almost guaranteed to crash. After a few such crashes, I tried harakiri newest version, and it works excellent with GPS hold and rth. With newest harakiri firmware I have now flown over a thirty flights in GPS mode with no issues - even doing GPS hold and rth in 20+ knot winds. You should look at harakiri as a starting point to fix cleanflight GPS - don't reinvent the wheel.

I've not looked hard at Harakiri, but does it fly as well as baseflight?

As for code, the APM code works really well too. Their altitude hold is also vastly superior to the yo-yo implementation in baseflight (although that can probably be tuned out with work). Only problem with it is that it flies awfully in acro, and it's a bit ick to configure (6 flight modes on one channel is kinda nice though once you get it working).

If someone wants to do something original, another nifty mode from openpilot is axis lock. It's like rate mode but actively holds the current angle, so wind/weight distribution don't make the quad level out.

Anyway, I realise it's a lot of work to get any of this stuff done. My hat's off to everyone who's worked on code for free. Without open source efforts this hobby would be a lot less interesting.

dominicclifton · Post by **dominicclifton** » Thu Aug 28, 2014 1:29 pm

dopplerguru wrote:Have used GPS in baseflight and cleanflight on naze32 and they are both worse than useless. Cause random very fast loss of control - almost guaranteed to crash. After a few such crashes, I tried harakiri newest version, and it works excellent with GPS hold and rth. With newest harakiri firmware I have now flown over a thirty flights in GPS mode with no issues - even doing GPS hold and rth in 20+ knot winds. You should look at harakiri as a starting point to fix cleanflight GPS - don't reinvent the wheel.

yes, i plan on having a look into the harakiri code. Can you confirm which version of harakiri you were using and where the source code for that version is?

scrat · Post by **scrat** » Thu Aug 28, 2014 2:08 pm

strepto wrote:Ouch! Nasty.

Yes... I wouldn't trust the baseflight GPS code any further than I could throw my quad...

https://www.youtube.com/watch?v=waklINsuPOg

I would love to see improvement. IMO it's one of the things that is holding back this board in a big way. I know TC doesn't care about it, but the reality is, some people want the safety net for when they're flying a long way away and have radio problems. It's not just for DJI hoverers.

For me...GPS PH and GPS RTH works. GPS RTH works better then GPS PH with original baseflight. But I would like to see if someone implements FAILSAFE RTH in baseflight.

Thanks.

stronnag · Post by **stronnag** » Thu Aug 28, 2014 5:46 pm

dominicclifton wrote:I guess not recently stronnag! That sucks.

GPS navigation in baseflight (and thus cleanflight) is somewhat experimental. The code doesn't do very much sanitation of gps input and in the past i have noticed erroneous longitude/latitude values on my FrSky/OpenTX telemetry read-out. It wouldn't suprise me if bad gps data was the cause based on that experience.

Cleanflight has not changed the implementation of gps navigation, i have been waiting for patrikE's work to be completed before embarking on that. Only the gps initialisation code with regard to serial ports and SBAS mode is different in cleanflight vs baseflight.

Can you share with us your cleanflight config dump, details of the gps receiver you're using and anything else you can think of that might be useful. How far away were you when you enabled RTH, what other modes were active?

Please file an issue on the github issue page with the above requested info: https://github.com/hydra/cleanflight/issues

Hi Dominic,

I appreciate the current gps code / test status and was well aware of the risks; next time it will be with a more expendable platform! The GPS is Ublox 6M. The mode would have been angle or horizon. Distance was c. 42m (from the telemetry log, and the home point remained constant through the flight).

The above, plus the FC config posted into Issue #61 https://github.com/hydra/cleanflight/issues/61

dopplerguru · Post by **dopplerguru** » Fri Aug 29, 2014 2:38 am

Have been using version 79 of harakiri , source is here https://github.com/Crashpilot1000/TestCode3 . GPS Hold and RTH work as good as, or better than APM. Although with both if you are using GPS you should use the best GPS and largest patch antenna that you can get (ublox neo-m8n and 35mm x 35 mm patch antenna works very good). Am currently using harakiri, tried cleanflight and baseflight but I really wanted a failsafe RTH as I use openlrs and fly fpv over 2 km from base so really need reliable RTH to prevent having to track down lost copters. Harakari has accomplished reliable failsafe RTH and is now more reliable for me than apm, but not yet 100% perfect and does not currently have gps auto, Am hoping that cleanflight will eventually become extremely reliable with full gps including gps auto.

dominicclifton · Post by **dominicclifton** » Fri Aug 29, 2014 3:44 am

thanks guys, i'll update #61 with the details.

PatrikE · Post by **PatrikE** » Fri Aug 29, 2014 10:57 am

@dominicclifton
I have not done any changes in the rth code since June 21.
Latest code is in
https://github.com/sbaron/baseflight/tree/rth_dev
Changed since is only lowering some max limits in CLI to 45.

Code: Select all

    { "gps_maxcorr", VAR_INT16, &cfg.gps_maxcorr, -450, 450 },
    { "gps_rudder", VAR_INT16, &cfg.gps_rudder,  -450, 450 },
    { "gps_maxclimb", VAR_INT16, &cfg.gps_maxclimb,  -450, 450 },
    { "gps_maxdive", VAR_INT16, &cfg.gps_maxdive,  -450, 450 },

There's also another newer merge where it have been changed.
https://github.com/schugabe/baseflight/tree/plane-rth
I have not tested that one myself though.

But it's sbaron git all tests have been made on.
I'm no C programmer and it's as clean i can make it.
Feel free to cleanup my messy code and merge.

The RTH function works really good judging from reports.

Patrik

tungsten2k · Post by **tungsten2k** » Fri Aug 29, 2014 11:33 pm

I'm getting ready to load and test the latest code to verify that the OSDSW config switch is fixed, but I got sidetracked going through the accelerometer drivers, and couldn't really figure out if CF makes use of multiple accerometers or not ?

I've got two Flip32+ units here, one of which I'll be puting into the quad and it seems the latest Flip32+ board I received from Paul doesn't include the second accelermeter (Freescale MMA8452). It includes just the single Invensense MPU6050 like the Naze32 includes.

I was curious, if choosing which FC to use for my primary FPV acro quad, does CF sample the results of both accerometers on the Flip32 and use them ? I guess the next question is, if so, how does it use them ? Does it average the results from both, or does it do some kind of sanity checking between the two in order to throw away extraneous samples if one of them malfunctions or sends a stray bit ?

-=dave

tungsten2k · Post by **tungsten2k** » Sat Aug 30, 2014 3:45 pm

OSDSW in latest hex indeed is fixed: tested working with MWOSD1.2pre1

Thanks Dominic for sorting this out !

-=dave

Crashpilot1000 · Post by **Crashpilot1000** » Sat Aug 30, 2014 5:57 pm

tungsten2k wrote:...
I've got two Flip32+ units here, one of which I'll be puting into the quad and it seems the latest Flip32+ board I received from Paul doesn't include the second accelermeter (Freescale MMA8452). It includes just the single Invensense MPU6050 like the Naze32 includes.

I was curious, if choosing which FC to use for my primary FPV acro quad, does CF sample the results of both accerometers on the Flip32 and use them ? I guess the next question is, if so, how does it use them ? Does it average the results from both, or does it do some kind of sanity checking between the two in order to throw away extraneous samples if one of them malfunctions or sends a stray bit ?
...
-=dave

Sorry for writing in this thread but that dual acc stuff kept me busy for some time.
Having 2 ACC and only using one bothered me as well so I spent a week (in the evenings..) to get both working together.
I did a dual ACC calibration for MPU6050 and ADXL345 / MMA8452 and rescaled them to the proper g scaling, even tried different g scales and sample times.
From my findings MPU6050 and ADXL345 make a very nice couple they complemented well and improved the result and sturdiness without much hassle. However I was not able to get MMA and MPU working together in a beneficial way. Perhaps MMA and MPU can be made a better working couple but I wasn't able to do that. Maybe my inability or whatever blocked me but I hate MMA now... I had the code on display in my github but removed it because practically useless. If you want to kick off the ball from what I already did I can provide you with the source - must be somewhere on the hddsk. Those sanity checking stuff is just 3DR sales talk IMHO that came up when they released PX4 with MPU and STM acc. By that time they had no idea how to combine acc data or how to make the stm part replace the mpu. Meanwhile Paul Riseborough brought some brains to the 3DR overhyped and major fail sales party.
Generally I think combining ACC values to avoid resonance etc is a good thing but I bit my teeth on mma.
Cheer Rob

brm · Post by **brm** » Sat Aug 30, 2014 8:04 pm

Crashpilot1000 wrote:
tungsten2k wrote:...
I've got two Flip32+ units here, one of which I'll be puting into the quad and it seems the latest Flip32+ board I received from Paul doesn't include the second accelermeter (Freescale MMA8452). It includes just the single Invensense MPU6050 like the Naze32 includes.

I was curious, if choosing which FC to use for my primary FPV acro quad, does CF sample the results of both accerometers on the Flip32 and use them ? I guess the next question is, if so, how does it use them ? Does it average the results from both, or does it do some kind of sanity checking between the two in order to throw away extraneous samples if one of them malfunctions or sends a stray bit ?
...
-=dave

Sorry for writing in this thread but that dual acc stuff kept me busy for some time.
Having 2 ACC and only using one bothered me as well so I spent a week (in the evenings..) to get both working together.
I did a dual ACC calibration for MPU6050 and ADXL345 / MMA8452 and rescaled them to the proper g scaling, even tried different g scales and sample times.
From my findings MPU6050 and ADXL345 make a very nice couple they complemented well and improved the result and sturdiness without much hassle. However I was not able to get MMA and MPU working together in a beneficial way. Perhaps MMA and MPU can be made a better working couple but I wasn't able to do that. Maybe my inability or whatever blocked me but I hate MMA now... I had the code on display in my github but removed it because practically useless. If you want to kick off the ball from what I already did I can provide you with the source - must be somewhere on the hddsk. Those sanity checking stuff is just 3DR sales talk IMHO that came up when they released PX4 with MPU and STM acc. By that time they had no idea how to combine acc data or how to make the stm part replace the mpu. Meanwhile Paul Riseborough brought some brains to the 3DR overhyped and major fail sales party.
Generally I think combining ACC values to avoid resonance etc is a good thing but I bit my teeth on mma.
Cheer Rob

i just checked the variance of the mma device. looks much better as the i2c variant of the mpu-6050.
to me i would feed the mma data into the inertial navigation and def. not the mpu-6050 data.

i see no problem to average the acc data ;-)

have sold all my rev4 board - one bad board is still on my desk.
need to write a small test ...

still in love using the mpu-3050 and the adxl device.

alastairseggie · Post by **alastairseggie** » Sun Aug 31, 2014 9:27 pm

To all that are Contributing to CF, I just wanted to say a big thank you.

I know there are large egos attached to which flavour of Firmware you use. I am just a user of the code and not a coder and after spending 2 fruitless days trying to get my minim OSD to play nice with BF, I took the plunge and loaded CF, after a few CLI changes, which took less than 60 sec I can report everything behaved as expected with both KV and MW OSD's. I just wish I had made the move sooner :roll:

Alastair

stronnag · Post by **stronnag** » Sun Aug 31, 2014 9:45 pm

I've been using the new MSP telemetry with softserial and a 433 Mhz 3DR radio. Recently I thought that "set emf_avoidance = 1" might be a good idea to avoid any CPU 6th order 72Mhz harmonics on the 3DR; it is not, as softserial eventually dies at 80Mhz and requires a reboot to start again. I guess there is a hard timing dependency on 72Mhz for softserial?

With "set emf_avoidance = 0" there are a few MSP checksum errors, but this is far preferable to the telemetry dying with warning.

dominicclifton · Post by **dominicclifton** » Mon Sep 01, 2014 7:53 pm

PatrikE wrote:@dominicclifton

I have not done any changes in the rth code since June 21.
Latest code is in https://github.com/sbaron/baseflight/tree/rth_dev
But it's sbaron git all tests have been made on.

I'm no C programmer and it's as clean i can make it.
Feel free to cleanup my messy code and merge.

The RTH function works really good judging from reports.

Hi PatrikE - thanks for the details, I'll add this to the github issue tracker. Keep up the good work!

dominicclifton · Post by **dominicclifton** » Mon Sep 01, 2014 7:55 pm

alastairseggie wrote:To all that are Contributing to CF, I just wanted to say a big thank you.

I know there are large egos attached to which flavour of Firmware you use. I am just a user of the code and not a coder and after spending 2 fruitless days trying to get my minim OSD to play nice with BF, I took the plunge and loaded CF, after a few CLI changes, which took less than 60 sec I can report everything behaved as expected with both KV and MW OSD's. I just wish I had made the move sooner

Alastair

Hi Alastair! Thanks for the thanks, it's really appreciated and always nice to hear from happy users

Glad everything is working for you. If you have any ideas please don't hesitate to share them with us, always looking to make things better.

dominicclifton · Post by **dominicclifton** » Mon Sep 01, 2014 7:56 pm

stronnag wrote:I've been using the new MSP telemetry with softserial and a 433 Mhz 3DR radio. Recently I thought that "set emf_avoidance = 1" might be a good idea to avoid any CPU 6th order 72Mhz harmonics on the 3DR; it is not, as softserial eventually dies at 80Mhz and requires a reboot to start again. I guess there is a hard timing dependency on 72Mhz for softserial?

With "set emf_avoidance = 0" there are a few MSP checksum errors, but this is far preferable to the telemetry dying with warning.

No it's not hardcoded, it uses the system base clock, you can see the code here:
https://github.com/hydra/cleanflight/bl ... rial.c#L92

stronnag · Post by **stronnag** » Mon Sep 01, 2014 7:59 pm

Thanks. It seems much more reliable at 72Mhz for whatever reason.

markus1234 · Post by **markus1234** » Tue Sep 02, 2014 2:47 pm

Hi, I plan to use cleanflight with a cc3d board.
The configurator has to connected to com1. This com is blocked and the usb port is not used?
Are there plans to split com ports ( eg. rx to receiver and tx to osd, the baudrate has to be the same) or is this already possible?

nebbian · Post by **nebbian** » Wed Sep 03, 2014 2:12 am

Not sure if you saw this on github yet Dominic, but I've redone the sonar flight mode to allow it to work even when BARO is not defined in the target (as requested).

I can now understand the frustration that timecop expressed with regard to the boxnames and the multiwii gui!

On another note, has anyone else seen some real flakiness in the cleanflight configurator chrome app lately? I used to be able to just disconnect the USB cord and it would notice that it was disconnected, and figure itself out. Now it just hangs and crashes hard.

alastairseggie · Post by **alastairseggie** » Thu Sep 04, 2014 10:00 am

nebbian wrote:On another note, has anyone else seen some real flakiness in the cleanflight configurator chrome app lately? I used to be able to just disconnect the USB cord and it would notice that it was disconnected, and figure itself out. Now it just hangs and crashes hard.

No not seen this, it works fine for me no crashes or hanging....seems odd.

Alastair

tungsten2k · Post by **tungsten2k** » Thu Sep 04, 2014 4:24 pm

alastairseggie wrote:
nebbian wrote:On another note, has anyone else seen some real flakiness in the cleanflight configurator chrome app lately? I used to be able to just disconnect the USB cord and it would notice that it was disconnected, and figure itself out. Now it just hangs and crashes hard.

No not seen this, it works fine for me no crashes or hanging....seems odd.

Alastair

Same here; works as expected.

-=dave

tungsten2k · Post by **tungsten2k** » Thu Sep 04, 2014 4:35 pm

brm wrote:
Crashpilot1000 wrote:
tungsten2k wrote:...
I've got two Flip32+ units here, one of which I'll be puting into the quad and it seems the latest Flip32+ board I received from Paul doesn't include the second accelermeter (Freescale MMA8452). It includes just the single Invensense MPU6050 like the Naze32 includes.

Sorry for writing in this thread but that dual acc stuff kept me busy for some time.
Having 2 ACC and only using one bothered me as well so I spent a week (in the evenings..) to get both working together.
[...]
Generally I think combining ACC values to avoid resonance etc is a good thing but I bit my teeth on mma.
Cheer Rob

i just checked the variance of the mma device. looks much better as the i2c variant of the mpu-6050.
to me i would feed the mma data into the inertial navigation and def. not the mpu-6050 data.

i see no problem to average the acc data
have sold all my rev4 board - one bad board is still on my desk.
need to write a small test ...

Interesting history. Thanks for the insight.

Just to let everyone know, the Flip32 latest rev 6 apparently has the Spektrum satellite port wiring changed. Unfortunately it isn't "fixed" from the rev 5, but is in fact worse. Rev 5 had the sat port connected to the primary UART line, so you could never use it without recompiling code to move the MSP/commandline usage to the other UART; it essentially was a big mess, and far easier to mod the port by cutting the trace that connected it to UART1 and put a surface trace to connect it to UART2 (the "Ch4" data line).

Well, Flip32 rev 6 apparently has the SAT port data line connect to the MPU_INT on the 6050 (WHT ?)

I loaded Cleanflight and it didn't work out of the box (no surprise) but my gut is that it will never work ? Is there any way that the MPU_INT (interrupt line for the Invernsense) can serve double-duty to manage the spektrum SAT too ? It just doens't seem possible, no matter what code magic you might want to throw at it

I'll keep plugging at it…

-=dave

linuxslate · Post by **linuxslate** » Thu Sep 04, 2014 7:57 pm

Hello, Dominic et. al.

I am doing a user manual for CleanFlight on the Massive32 and MassiveAcro boards:
http://www.massiverc.com/PrestaShop/22- ... rol-boards

I am experienced with the 8 bit MW stuff, including messing with the code (although I now run a stock 2.3).
After a quick look at the various 32bit MW forks, it was me that convinced MassiveRC (MO) to go with CleanFlight.

I have to confess to having never flown a 32 bit system. Parts are on order for a new build that will be 32 bit (I also design / build my own frames). I have a Massive32 board that MO gave me, and it is on the bench with a LemonRX PPM Receiver.

I have lots of other stuff to try so that I can document that, too: MinimOSD (I have my own version of KVTeamOSD, that I call PRO_HUD_OSD), GPS, etc.

It is my intention to make CleanFlight the best documented 32 bit MW fork.

My documentation will also be free of other peoples intellectual property, as I am aware of, and sensitive to... Well... "The Situation".

I will be asking a few questions here, and I know that the answer to my questions may be "go look at the code"; however, If some of you that have already worked with this can answer, it will allow me more time to make pretty documentation.

The same goes for questions that may be hardware related. My documentation is specifically CleanFight; Yes, I do read the "other" documentation, and 32bit HW threads, but I may still ask here to get my documentation right.

Also, any other comments that would help or correct my documentation is requested. If Dominic thinks I should make a separate CleanFlight Documenation thread, I will.

I cannot provie a link to the documentation at the moment, because we are still deciding where it should live.

strips · Post by **strips** » Fri Sep 05, 2014 10:55 am

I just flashed Cleanflight for the first time to test channels 9-12 on PPM.

I'm unable to arm using channel 9 and greater. Created a issue in github: https://github.com/hydra/cleanflight/issues/64

dominicclifton · Post by **dominicclifton** » Fri Sep 05, 2014 2:10 pm

strips wrote:I just flashed Cleanflight for the first time to test channels 9-12 on PPM.

I'm unable to arm using channel 9 and greater. Created a issue in github: https://github.com/hydra/cleanflight/issues/64

Interesting, I did a couple of changes to the configurator and cleanfligth recently with regard to aux channel configuration. Can you make sure you're running the very latest firmware - compile it yourself, i'll probably publish a binary in the next day or so after i've flown it myself. Also make sure you're using the latest configurator, 0.50.1 or higher.

Please update the issue after confirming version and/or re-testing with latest code.

dominicclifton · Post by **dominicclifton** » Fri Sep 05, 2014 2:23 pm

linuxslate wrote:It is my intention to make CleanFlight the best documented 32 bit MW fork.

Awesome! Creating good documentation is hard and I thank you for wanting to help with this!

linuxslate wrote:I cannot provide a link to the documentation at the moment, because we are still deciding where it should live.

Here's a few thoughts on this subject, of the top of my head - in no specific order.

1) We don't ever want the documentation to get out of sync with the code. If it lives with the code it's easier to update it at the same time.
2) We don't want duplicate or conflicting documentation.
3) Keeping the documentation with the code makes it easy for others to access and change, not as easy as a wiki but wiki's go out of date very quickly.
4) I've been using markdown format, since markdown is displayed on the github pages.
5) I'm not averse to having a publishing step or a command to build the documentation from a set of source files, if required.
6) Publishing to PDF or Static HTML (single or multi page) would be nice - e.g. to be available as downloads.
7) Screenshots go out of date and are time consuming to re-create, use sparingly.
8) Connection photos don't go out of date as quickly, are very useful but are also time consuming to create.
9) Documentation should be purely factual, contain no opinions and be backed by references and links where possible (like wikipedia).

dominicclifton · Post by **dominicclifton** » Sat Sep 06, 2014 12:54 am

strips wrote:I just flashed Cleanflight for the first time to test channels 9-12 on PPM.

I'm unable to arm using channel 9 and greater. Created a issue in github: https://github.com/hydra/cleanflight/issues/64

this is now fixed, a unit test was created to show the problem and a solution was then created so the problem can't re-appear without the test breaking.

https://github.com/hydra/cleanflight/bl ... c#L69-L129

That's actually quite a useful test since MultiWii has support for 6 positions per aux channel and so it will help when adding support for that.

linuxslate · Post by **linuxslate** » Sat Sep 06, 2014 2:43 am

dominicclifton wrote:
Awesome! Creating good documentation is hard and I thank you for wanting to help with this!

Here's a few thoughts on this subject, of the top of my head - in no specific order.

1) We don't ever want the documentation to get out of sync with the code. If it lives with the code it's easier to update it at the same time.

Agreed, but somewhat idealistic. I do not know of any project for which there is not stale or outdated information on the 'web, and I do not think CF is going to be the first.

We are still talking about where it will live. Allowing others to keep it up to date is definately a concideration.

2) We don't want duplicate or conflicting documentation.

Uhhhh... Duplicate or conflicting information on the internet?! Nahhh, That'll never happen!
I can control what is in my single document, and I certainly accept redlines to remove/correct duplicate or conflicting information, but that is all.

3) Keeping the documentation with the code makes it easy for others to access and change, not as easy as a wiki but wiki's go out of date very quickly.

See above.

4) I've been using markdown format, since markdown is displayed on the github pages.

5) I'm not averse to having a publishing step or a command to build the documentation from a set of source files, if required.

Both good ideas, but a static PDF, (and thus "out of sync" soon after it is published) is probably what we will have at least for the short term.

6) Publishing to PDF or Static HTML (single or multi page) would be nice - e.g. to be available as downloads.

Yeah, again trade off between something we can publish as a nice downloadable document, and the ease of keeping it up to date with the code.

7) Screenshots go out of date and are time consuming to re-create, use sparingly.

Agreed, but customers (esp Noobs) like screenshots. Right now I have a few.

8) Connection photos don't go out of date as quickly, are very useful but are also time consuming to create.

Already done, but subject to change.

9) Documentation should be purely factual, contain no opinions and be backed by references and links where possible (like wikipedia).

Errrmmm.. Well I do put humor and personal expirience in the documentation I write. Look in the book store. Dry text is just not what people want to read.
"...for Dummies" and other books with humor and cutsie graphics is what people will read.

Developers can look at the code. Readable documentation opens the user base to more people.

I think we may need 2 sets of documentation -- a Wiki or markdown, and a "pretty" PDF.

I am willing to do a 2nd version in markdown, with just the basic formating, and no "editorial".

Of course I can't promise to maintain it "in perpetuity" (I drink too much Pepsi to be around when perpetuity gets here.)

tungsten2k · Post by **tungsten2k** » Sat Sep 06, 2014 3:36 am

linuxslate wrote:Agreed, but somewhat idealistic.

And we like it that way

But seriously. I've already witnessed two instances where outdated documentation caused grief for configuring CF (I was one of them). Dominic chose (I think wisely) to ditch the wiki-format documentation entirely, rather than have to keep two sources in sync. Single-source prevents any problem there. My first job at WindRiver back in 1990 had this as their requirement, where documentation was literally kept inline with source with their own markup. Idealistic goals and a better execution to uphold those (somewhat lofty) ideals more closely than competition determines success.

oops. sorry for waxing philosophically...

-=dave

tungsten2k · Post by **tungsten2k** » Sat Sep 06, 2014 5:54 pm

Looks like the latest verison of Configurator has the Profile pop-up menu removed. However, the stick-movement Profile switching still works; you just need to refresh Configurator and the "Profile" field will update to show you the correct Profile the controller is set to.

I'm not sure if this is a bug or a new "feature"

-=dave

strips · Post by **strips** » Sat Sep 06, 2014 6:21 pm

dominicclifton wrote:
strips wrote:I just flashed Cleanflight for the first time to test channels 9-12 on PPM.

I'm unable to arm using channel 9 and greater. Created a issue in github: https://github.com/hydra/cleanflight/issues/64

this is now fixed, a unit test was created to show the problem and a solution was then created so the problem can't re-appear without the test breaking.

https://github.com/hydra/cleanflight/bl ... c#L69-L129

That's actually quite a useful test since MultiWii has support for 6 positions per aux channel and so it will help when adding support for that.

Sweet I will test it as soon as my wife allows me a bit of spare time

dominicclifton · Post by **dominicclifton** » Sun Sep 07, 2014 11:38 pm

tungsten2k wrote:
linuxslate wrote:Agreed, but somewhat idealistic.

And we like it that way

But seriously. I've already witnessed two instances where outdated documentation caused grief for configuring CF (I was one of them). Dominic chose (I think wisely) to ditch the wiki-format documentation entirely, rather than have to keep two sources in sync. Single-source prevents any problem there.

Totally! It's really easy for any developers to update the documentation when they submit changes or new features along with their pull requests.

There are various formats for creating documentation which can be used to generate pdfs or html documentation pages and i'm fine with those as long as the format is simple and doesn't get in the way of the process of creating documenation. I keep the documentation in markdown format for two reasons: 1) github renders it correctly and when you edit the file on the github website itself allows you to preview changes you make. 2) it's simple, widley used and isn't a large barrier for people to overcome which more complicated formats sometimes are. The less barriers there more likely the documentation actually gets updated.

granted there is a higher barrier in editing files in markdown format vs editable wiki pages but the benefits of keeping it in sync outweighed it for me when I made the choice between the two.

I propose that, for now, so we get somewhere with this, that we update and extend the current documentation with the things that are missing or not as good as they could be, and then think about introducing different output formats for it? markdown format lends itself well to automatic html generation, html generation lends itself well to automatic pdf generation.

dominicclifton · Post by **dominicclifton** » Mon Sep 08, 2014 3:08 pm

pulsar on irc pointed out this tool which can be used to automate the process from markdown to pdf.

https://github.com/walle/gimli

linuxslate · Post by **linuxslate** » Mon Sep 08, 2014 10:23 pm

I actualy need the opposite, since the PDF is already largely done. (OK, a start is somewhat done.)

It's being done in LibreOffice, and there are ways to go LibreOffice ---> Export HTML ---> HTML to Markdown.

zatalian · Post by **zatalian** » Tue Sep 09, 2014 8:18 am

Hi,

I'm flying an airplane, not a quadcopter...
I have a few questions about the new rc channels (aux 5-8) and maybe a few enhancement requests:

1. looking at the code, i see that rcmap is still an array of 8 positions. Does that mean that aux 5-8 can not be mapped to a specific rc channel?
2. how hard would it be to support sbus 16 channels instead of sbus 12 channels now. That would give us the opportunity to leave some channels unused (the first 3 for example, so we can use them directly from the transmitter)
3. It would be nice if some functions (Throttle, Aileron, Rudder, Elevator, 1, 2, 3, 4, 5, 6, 7, 8) do not get mapped if we don't need them
4. I really need a second aileron function for my premixed flaperons to work.

for example: if I have an X4R-SBUS and an airplane with 2 channel aileron, elevator, no rudder, 5 aux and i want to keep the first 3 channels free, then i would map my channels like this:

Code: Select all

map ---TEAA12345----

or if i use an X8R and i want to keep as much receiver channels available as possible i would use

Code: Select all

map -------TEAA12345

dominicclifton · Post by **dominicclifton** » Tue Sep 09, 2014 5:24 pm

Hi zatalian.

1) Please open a feature request on the github issue tracker.

2) I have an X8R and plan to do more work on SBus soon, I wouldn't be confident committing without hardware to verify my changes, please add a feature request for this too.

3) I would need to look into the code for that one a bit more, i think there are lots of places where there are expectations that all channels are mapped.

4) Please can you explain this a little more.

zatalian · Post by **zatalian** » Tue Sep 09, 2014 6:39 pm

16 channels frsky sbus request: https://github.com/hydra/cleanflight/issues/67
(BTW 12 channels sbus is working great on both my x4r-sb and x8r with my acro naze. I have used it on a couple of flights without problems)

channel mapping for aux channels 5-8 request: https://github.com/hydra/cleanflight/issues/66
maybe i should not have made this one... but this one is more like a bug, the next one is a real enhancement

channel mapping enhancement request: https://github.com/hydra/cleanflight/issues/68

concerning point 4:

I had flaperons mixed in my transmitter. Basically i have 2 different channels for my wings: aileron left and aileron right, going in opposite directions to roll and going in the same direction if i want flaps to land. Right now in the baseflight/cleanflight code, i can only use roll, rudder and elevator, and i can only map 1 channel to each function. So I can only use 1 channel for my ailerons hence i can't use my premixed flaperons.

If I can map a second aileron channel, i would be able to reprogram the airplane mixer.

Previous attempts to get flaperons working on mwii use a function and do all the mixing in the code. But that does not feel right to me and the code was stripped out of baseflight because of the uglyness. I would much rather prefer to mix my flaperons my transmitter and only do the stabilizing in mwii/cleanflight. It should be a lot easier too.

what i need is the possilibity to map a second aileron, for example:

map ---TREAA1234----

the first A is the left channel, the second A is the right channel.

zatalian · Post by **zatalian** » Wed Sep 10, 2014 5:11 pm

where and how can i deliver patches?
I have an untested patch for issue #67
Testing is a bit difficult without being able to map functions to channels above 8 but the patch is dead simple

tungsten2k · Post by **tungsten2k** » Wed Sep 10, 2014 7:20 pm

zatalian wrote:where and how can i deliver patches?
I have an untested patch for issue #67
Testing is a bit difficult without being able to map functions to channels above 8 but the patch is dead simple

You'd submit a pull request:

https://help.github.com/articles/using-pull-requests

-=dave

tungsten2k · Post by **tungsten2k** » Wed Sep 10, 2014 11:09 pm

FYI, I submitted feature request #70 for support of Spektrum X-Channels (higher channels) just so the code snippet would get captured before it disappears from the interewebz. I'm pretty confident the RCG thread it came from died immediately afterward because everyone took their marbles and turned the result into a private project. Feature request is obviously lowest priority.

-=dave

nebbian · Post by **nebbian** » Thu Sep 11, 2014 1:46 am

Hey Dominic, what's the deal with pid_controller "Baseflight"? It's pid_controller = 2. I've found that it gives me the best transition between acro, horizon and angle modes (ie moving the stick a certain amount gives the most consistent response). The default pid controller is rubbish with respect to horizon mode, the craft feels really sloppy and takes a while to respond to stick inputs.

I glanced in the Baseflight code, and you can't select pid_controller = 2, so it appears to be a cleanflight thing. I'm curious as to how it was conceived. Flying it yesterday showed up a bug in the horizon mode implementation: if you do a quick flip while in horizon mode, the first half of the flip is fine, but the second half turns into a shoulder roll as if the aileron is banged hard over. Doing the same flip in acro mode results in a normal flip. I can do a video for you if you like. Also, I noticed that if you don't get the "PID" parameters right then when in horizon mode, you can bang the stick hard over and it only goes over to 90 degrees instead of doing a full flip. This surprised me greatly the first time it happened.

Would you like me to give this mode a tuneup?

Also I'm wondering what the status of my pull request for the sonar flight mode is.