NAV - Fixed wing support

[digitalentity]

No description provided.

[sppnk]

Hi, I have seen your last video in youtube with the copter. It is amazing and it seems everything works fine. Good job.

I would like to test RTH with one of my planes (CC3D). I think (not sure) that your code with RTH will work well, except for altitude hold. I will test this with 1.9.0 main this evening and I would like to try ASAP with your branch.

Could you add the altitude from the GPS as a source for barometer reading function (and probably a simple filtering)? And a variable in the CLI just for setup this and try?

I would test this inmediately, as I am already flying airplanes with Cleanflight. Thx.

[digitalentity]

The problem is that fixed wing support in my navigation code is completely absent! If you wish to try it on planes, you'll have to add fixed wing support or wait until somebody else does it. I have fixed wing support planned, but I don't have any timeframe for adding it yet.

[digitalentity]

@sppnk I am soon going to begin coding fixed-wing support and currently have a 1.2m flying wing lying around. Can you assist with setting up Cleanflight for a flying wing (delta mixer)? May be some suggestions of PIDs?

[sppnk]

Sure!! I want assist, but I dont have right now any flying wing. Just three airplanes (ailerons, rudder, elevator & throttle). They are an EasyStar (1400 wingspan) and two miniskywalkers (850 wingspan).

For now, two of them are flying with CF, and the settings are the standard with 1.9.0 version. I haven't touch still this, and they fly well with those settings.

For your info (altought I think you already know it), the main problems with flying wings are the correction in ailerons applied by automated navigation input. This settings should be later in the CLI, so it seems they have to be very diferent between airplanes.

In baseflight RTH airplane implementation, the altitude and heading are taken from GPS readings, and GPS altitude seems be better than real barometer measures in airplanes setups (see baseflight RTH airplane by PatrikE). Thanks to this, simplest boards w/o baro & mag are beeing used for automated navigation & RTH, PH, waypoints, etc. That is the main success for that firmwares, because there are some boards really cheap, like CC3D, that can transform any airplane in much more.

Other thing is the airspeed vs. ground speed, using pitot tube sensor, but I can't help here, so I have never used one.

[digitalentity]

Ok, just to let you know - the work has started on fixed-wing support. First thing to go is ALTHOLD mode. The logic will use BARO if present, otherwise it'll fallback on GPS. Soon I'm going to test GPS as an altitude sensor to see if it gives valid readings.

[sppnk]

Awesome !!! Thx !!

[digitalentity]

@sppnk you can now try the ALTHOLD mode with fixed wing. Grab a latest hex from my dropbox and give it a try.
PID to play with in configurator - "VEL". Defaults are probably too high for fixed wing, try zeroing I and D and reducing P by half at first. Please note - this is very experimental. Be ready to switch to manual at all times. This code might behave not the way I ment it to, it might even attempt to crash your plane. Also the code does not control THROTTLE yet, you'll have to manually maintain speed.

[digitalentity]

Also, there is NO manual altitude control yet. The plane should hold altitude, but you won't be able to adjust it yet. Essentially, you will be locked out of pitch control.

[marksev1]

Digitalentity it might be beneficial for you to look at the algos here https://github.com/EmilsPa?tab=activity (not sure if all the relevant source is there since he distributes in zips also) this thread is relevant also: http://fpvlab.com/forums/showthread.php?27854-NAZE32-for-fixed-wing/page185

[marksev1]

Since the "patrikE" baseflight for planes branch code is well tested, working and popular.

[digitalentity]

@marksev1 I am already looking at patrickE's code. His algos are pretty straight-forward, but difficult to directly port to nav-rewrite since my implementation is very modular but patrickE's code is a monolyth. Moreover his code is based only on GPS, while my code is designed to use all available sensors. Want more precise heading control? No problem - add a magnetometer. Want better altitude control - simply add a baro, no change to firmware or config.
A downside of this is that I can only take a basic idea and implement it from scratch in my framework. This adds bugs.

[sppnk]

@digitalentity , I will try ASAP and report, thx !!

[sppnk]

@digitalentity Should be nice if you announce your FW code and a link to it in the forums, so we could get much more beta-testers than just here in github.

rcgroups and fpvlabs seems to have many users interested in PatrikE code, so they should be also interested in cleanflight FW-NAV. Multiwii forum has also a dedicated cleanflight thread.

[marksev1]

The accuracy statement is legit, but still nothing can beat the convenience of just using a gps for a plane. So no need to calibrate magnetometer and cover the baro with foam .. Is airspeed sensor support also planned?

[marksev1]

In any case it is nice that your code covers all the possibilities :)

[digitalentity]

@marksev1
Airspeed sensor is planned, but only as a very distant possibility. Airspeed estimation desribed in http://diydrones.com/forum/topics/wind-estimation-without-an will be done much faster than physical airpseed sensor support.

@sppnk
I don't think my code is ready for public beta-testing yet, but this moment is approaching. I'm going to announce public testing on rcgroups when Flyable milestone is reached (https://github.com/digitalentity/cleanflight/milestones/Flyable)

[sppnk]

@digitalentity Thx, Anyway, I hope I could test the new ALTHOLD in my 1400m wingspan plane this week. I will report ASAP.

The expected behaviour should mantain the altitude independently if I use ailerons, throttle and rudder, like a 2D movement, isn't it?

[digitalentity]

Yes, you you won't be able to use elevator yet, I'm working on that part of the code.
Also thanks for trying out the FW-code for me! Currently I don't have a plane to test my fixed-wing code - I've crashed my flying wing yesterday due to failed servo.
EDIT: GPS is not very precise source of altitude, so expect plane to drift up and down several meters.

[sppnk]

@digitalentity Could you compile a .bin file?. I am having big problems to flash my CC3D through Chrome & USB. May be I have to use FTDI, but not sure if I have also to short some pads inside. That should be annoying if I have to do every time I flash it. No problem if it would be only with FTDI.

To flash Cleanflight I have usually used OpenPilot GCS, which can flash CC3D with .bin files and just USB cable. Sorry.

[sppnk]

Hi, I have been reading about this and it seems that the only way to flash CC3D through USB without shorting the SBL pins inside is if the .bin file is "openpilot bootloader compatible".

The .bin files from CF download pages are like that, so I could flash my CC3D with OpenPilot, but may be I cannot do that with your .hex.

[digitalentity]

A today's build is available here. CC3D BIN is also available. Also, I've implemented manual altitude control - please test and confirm it's working (or not) 😄

[sppnk]

@digitalentity many thx. I have flashed your .bin with OpenPilot GCS. It shows 1.10.0 Running firmware released on: Sep 2 2015 01:30:33 Board: CC3D, version: 0. Good !

But... I dont see the new "ALTHOLD" mode in the Crhome GUI, so I cannot assign a switch in my transmitter to test this feature !! Can I setup that through the CLI?

[digitalentity]

Oops, sorry, must have missed adding fixed-wing support in flight modes. Will fix asap.

[sppnk]

Please add it also in AIRPLANE config, not only in FLYING WING, because I have only planes to test. Thx.

[digitalentity]

@sppnk grab a Sep03 build. Now flight modes can be configured correctly. You should also now have ability to adjust altitude using pitch stick - in ALTHOLD mode it will control climb rate. Everything related to airplanes is still completely untested.

[sppnk]

@digitalentity Hi, I flashed and now I can see ALTHOLD, POSHOLD and other new modes.

What I have problems now is to configure servo rates. In the Chrome GUI/servos page I have weird numbers, if I change them and save nothing happens. If I choose mixer custom the servos get very hot and noisy (may be the board send high Hz as they woyuld be Escs, not analog servos, I dont know). So I come back to mixer AIRPLANE, and everything go well, except the servo configuration, page. So I cannot invert aileron servos or rates.

Should I use the "servo" command in the CLI to get this working?

I my other planes I have also CC3D, but 1.8.1, because 1.9.0 has the same problem with the configuration of the servos in the GUI. With 1.8.1 I can do this very well.

The problem with CF is there are still few people flying airplanes. This will change with your amazing new code, man !!

[digitalentity]

@sppnk, @MDM63
Waiting for an airplane to arrive soon actually gives a very strong motivation to fix the code as soon as possible 😆
Wrong servo mapping on CC3D and NAZE is fixed by cleanflight/cleanflight#1425 . Hope @hydra will merge it soon enough.

[sppnk]

Many thanks again @digitalentity . For me, the main need in an airplane is a working RTH. This should be the first thing to work in. A good RTH should have options to take the plane higher and then back to home with a fixed altitude.

After that working well, a position hold (circles) should be nice, because you can use that function to land the plane,in a failsafe for example, just cutting throttle.

Please, try to mantain if possible the Openpilot bootloader files, so I am not able to flash CC3D in other ways (I have tried again and again, but no success). I dont see in your dropbox .bin files anymore.

[digitalentity]

@sppnk
In my firmware RTH is dependent on working poshold (its pretty much the same code). RTH will have options to control return altitude.

OBPL is no longer available - it's taking up too much valuable flash memory. I am already dropping features to fit the code in 127kb. Next thing to go is pid controllers. Only pidc 1 and 2 will remain in nearest future.

[sppnk]

Ok, I will try again to flash your .hex. I have ordered two more cc3d just to test.

One question, is poshold already working for fixedwings? (in my lasts attemtps you were working a fixed altitude mode).

[digitalentity]

@sppnk
Are you available on RCG or Cleanflight's IRC channel? I might be able to help you out with flashing the hex onto CC3D.
Poshold code is committed today, I have no idea if it will work or not 😃

[sppnk]

Yes, Im in RCG, but not in IRC. Will post my problems there. Thanks

[marksev1]

I haven't read through the code, but currently probably flying wing and traditional airplane mixers are supported right? May I suggest adding also a V-tail mixer so that all the widely used configurations of airplanes are supported.

[digitalentity]

All airplane mixers are now supported, but there was a report of a failure on a flying wing. We need to look into it.

[digitalentity]

As for V-tail mixer, can you add a separate issue for that?

[csurf]

Hi,
I'm trying to get up to speed on the FW development.
I've been looking at the code & have a few ideas/suggestions. not sure if this is the correct forum to suggest, but here goes...

• the code in nav_rewrite seems to be setup as a catch-all for both multi-rotor and FW, with a few, scattered if/else statements to distinguish between both cases (FW & MR). I propose that we completely eliminate those FIXED_WING if/else statements, and move that condition/test to a higher level, and initially distinguish the platform either on boot (perhaps based on a saved EEPROM flag?), or, in the future, based on a platform-specific firmware build (such as for setting up a separate firmware for FW & MR).
• • *** example of the above...
    there's a nav flight-mode event called "NAV_STATE_RTH_3D_HOVER_PRIOR_TO_LANDING" which basically only applies to MR's, yet it's currently applied to both cases (technically, it's skipped for FW due to an "if/else(FIXED_WING)" statement, but the code still runs through it for both cases). I propose that this algorithm be re-adjusted in order to accommodate both cases (both FW&MR) as more of a general -pre-landing case (something such as "NAV_STATE_RTH_3D_PRE_LANDING"), and then have the appropriate function be called based on platform, whether it be FW or MR...
• As I kinda stated above, we need to consider adjusting the nav 'event chains' in order to function as general-purpose navigational algo's that can serve as a basis for either FW or MR navigation, and then let the underlying nav driver determine the appropriate behavior/functions/return values for each nav "function." DE has kinda already set this structure up, but there are still some specific differences in the nav algo's that differentiate between MR & FW, which are currently giving more of a bias to MR (understandable). So, my proposal is to keep things very general within the upper-level code, and then identify the specifics down in the targeted nav drivers (either FW or MR). EEPROM flag (or firmware build) should ultimately determine what nav driver is implemented (either FW or MR).
• fixed-wing 'hover' descents should be defined as low-throttle banking circles that dive downward and have their poshold coords & alt constantly updated as the plane descends toward landing...
• fixed-wing climb-outs, as defined in iNav, seem to be 'ok' on initial inspection (algo is defined to set a distant waypoint, & climb toward it), but more testing is needed for verification... can others verify that this currently works? IMO, straight-away climb-outs are acceptable, vs. trying to manage a position-held 'circular' climb/ascent, which, I believe, would complicate things....
• we need to consider the addition of a "CRUISE" GPS mode for FW, where both heading & altitude are held for an indefinite distance, with both YAW&ROLL inputs being taken into account in order to setup a coordinated turn (RUDDER+ROLL+PITCH+THR). PITCH input determines ALT state (increase/decrease). A distant, constantly-updated waypoint (~1km away) should be setup where the plane will constantly attempt to navigate to. User yaw&roll inputs will update the heading&distant waypoint.
• EMERGENCY LANDING for FW:
• • IMO, E-landing for a plane should be setup as a blind, gliding, downward-circle...with motor(s) off, light bank angle maintained, a slight downward pitch angle, and (if mag is available) a circular heading tracked in order to cause the plane to quickly circle downward&descend. The bank & descent angles should be setup as user-config variables, "FW_ELAND_BANK" & "FW_ELAND_DIVE", or something similar.
• I propose the same as above for regular FW landings, such as for the "hover prior to land" case or waypoint-driven nav missions... I.E., Set the plane into either a 'cruise'-mode or 'glide' throttle, and then put the plane in a slight downward, position-holding circle while the land-detect routine runs over&over... Once ALT is equal to or below some user-config FW_LAND_HGT threshold value, kill the motors and just glide down, wings level, while still making pitch/roll/yaw servo adjustments.
• as msev has suggested, FW needs a means to over-ride&disable compass/ baro support (even if they're available on the hardware) and allow the code to rely solely on GPS for heading & altitude (legacy testing has shown that GPS alt&hdg are sufficient for FW flight).
• in the long-term, we definitely need to include support for an airspeed sensor for FW, which will require a separate algorithm & math in order to determine AS vs GS (airspeed vs groundspeed). APM code can serve as examples...

I would be willing to assist with coding, but I'd need some backup help with testing & suggestions/feedback. Please advise, feedback is requested...

[oleost]

@csurf I know there is ongoing discussion on separating fixedwing and multirotor firmware. cleanflight#1621

Testing I can help you with, currently setting up an airplane with iNav.

[csurf]

@oleost, cool, good to know, thanks...
for now, please take a look at my comments above & provide feedback/brainstorm. I'd greatly appreciate all of the input possible before I start any coding. If u can, please test the climb-out, pos hold, and RTH stuff.

FYI, I'm on the CF IRC channel, which might be easier & more productive in terms of dev communication...

[oleost]

#89 Added new issues regarding fixed wing, limited servo throws in stabilization mode without throttle.

[sppnk]

Hi, I have setup a CC3D plane with iNav 1.0.1, but in ANGLE and HORIZON modes all the servos move to one side (plus the stabilization corrections) when arming and raising throttle stick.

This movement is slow (1 - 2 seconds), just when motor starts and then the servos go full to one side (I still have control throught sticks and I can see the stabilization corrections). When I move the throttle stick to the minimum and the motor stops , then the servos go back to their normal positions.

This doesnt happen in passthrough mode (I can fly well with this mode).

It seems it is some weird mix, but checked the code I dont see the problem. May be other kind of correction is actuating, but I am not in RTH or POSHOLD or any navigation modes.

Also, like @oleost I think the throws of the servos are very limited in this modes,

[marksev1]

Do you think its maybe a power supply issue? Or code issue?

[sppnk]

I think it is a code issue, 'cause passthought works fine

[digitalentity]

@sppnk, It's I-term on Roll/Pitch in action. Plase the board perfectly level and you won't see the issue.
This is what happens:

1. FC notices that airplane is not level (ANGLE mode)
2. FC gives some output to servos
3. FC doesn't see airplane getting more level
4. FC gives more defelection to servos
5. FC still doesn't see airplain leveling out
6. FC gives even more defelection to servos
7. repeat

[sppnk]

@digitalentity, thanks, I have calibrated again several times (trying the six position acc calibration doesnt seems to work for me) the gyros and accelerometers through EZGUI and with TX sticks and now the behaviour is more normal.

So I think the model should be flyiable now in autolevel modes, and today or tomorrow I will test in air and report. Sorry for the mess :-).

[oleost]

Just a reminder instead of forum post.
Make "Elevator compensation" adjustable in as CLI command.
http://www.rcgroups.com/forums/showpost.php?p=34338337&postcount=4392

[digitalentity]

@oleost thanks, will keep track of it in #142

[sppnk]

plane tested (CC3D + GPS) and the stabilized modes working fine. Now testing RTH and NAV WP modes. Preparing for FPV. Thx.

[digitalentity]

@sppnk great!

[digitalentity]

People are flying airplanes with INAV, I think we can close this.