NAV - Fixed wing support about inav HOT 65 CLOSED

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.

from inav.

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.

from inav.

@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?

from inav.

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.

from inav.

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.

from inav.

Awesome !!! Thx !!

from inav.

@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.

from inav.

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.

from inav.

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

from inav.

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

from inav.

@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.

from inav.

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

from inav.

@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.

from inav.

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?

from inav.

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

from inav.

@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)

from inav.

@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?

from inav.

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.

from inav.

@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.

from inav.

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.

from inav.

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) 😄

from inav.

@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?

from inav.

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

from inav.

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

from inav.

@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.

from inav.

@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 !!

from inav.

It is a known problem - cleanflight/cleanflight#991 (comment) , cleanflight/cleanflight-configurator#238 so I guess you'll have to use CLI to configure servos. I don't yet fly airplanes with Cleanflight so I can't help you with this, sorry. Asking on IRC channel or RCGorups will probably help.

from inav.

This is what I get:

The tab servo in the GUI doesnt work, and I am not able to configure with the CLI. It seems the "servo" command doesnt work and I have to use the new "smix" command, but "smix" only works with CUSTOM mixer. I am really confused now.

Are you branch based in 1.10 or 1.9 ? Should be dificult to compile one based in 1.8.1? As 1.8.1 is the only that works well....

from inav.

I am also confused since "servo" command and "smix" command seems to have the same use. I don't know if they are compatible. In your code both of them appear in the CLI...

from inav.

Hello @digitalentity , I have opened a issue in main code with number #1288, because all the mapping of the channels don't work well in 1.10 (I think 1.9 neither) and it is impossible to setup an airplane for now. Nor through the configurator, but neither through the CLI.

I have burned two servos making tests....this is annoying. I will look at the code if I can find something to solve the issue, so I dont know where o when they changed the mapping of the channels for CC3D and airplane from 1.8.1, (where everyting is ok) to 1.10 (where it is hell on earth).

from inav.

@sppnk thanks for opening the issue with this. Somebody will look into it soon enough. Might even be me 😄

from inav.

Blocked until cleanflight/cleanflight#1288 and cleanflight/cleanflight-configurator#238 are resolved

from inav.

Hi, added #1290 PR (dirty), and cleanflight/cleanflight-configurator#242 (comment), trying to solve all this thing. Now I can configure some things thanks to your last build, but now I can't connect through Chrome....:-(

from inav.

Good to know that you are working on this. I'll keep an eye on your progress. Thanks!

from inav.

Didn't want to open a new issue, so I will explain here my last tests in CC3D.

I have been able to make a complete airplane setup, using digitalentity's last build (06 sept). The steps have been:

• flash .bin with OpenPilot GCS (as I cant do is through .hex files in CC3D).
• setup ports, GPS, PPM input and so on in Chrome
• setup AUX switches for ARM, ANGLE, PASSTHROUGH & NAVALTHOLD
• go to CLI and setup mixer customairplane, mmix load airplane, and smix as in #1290 (because the indexes for servos are wrong).

Then I send save command and test all the control surfaces work well, and angle mode also, but...

when I switch off and plug again my lipo, the servos respond well to mi transmitter, but when activating angle mode or acro mode the servos dont move when moving the plane. I have checked that the sensors dont send data to the graphic screen in chrome. It seems they are stopped. The box ANGLE goes green.

I could try to test the new NAV_ALTHOLD in passthrough mode, but is too dangerous, haha :-)

from inav.

Updated infos on CC3D servomixer issues here: #1076

Something is wrong there, so I am stil not able to test airplane mode.

If anybody has tested 1.10 with CC3D in airplane (digitalentity or master branch) and is flying, please report. Thx !!

from inav.

This issue is still blocked by these: cleanflight/cleanflight#1323, cleanflight/cleanflight#1324, cleanflight/cleanflight-configurator#238

from inav.

@sppnk
I think you'd want to know that I'm about to buy a Volantex Ranger 757-4 (http://www.banggood.com/Volantex-Ranger-757-4-FPV-1380mm-Wingspan-EPO-RC-Airplane-KIT-p-985099.html) for purpose of getting airplanes supported by Cleanflight.

from inav.

WOW MAN !! Nice bird, congratulations.

Because of the issues with the mapping of CC3D I bought some naze32 and at least I am flying my three birds with baseflight right now (RTH working fine), but in the last days the issue #1323 is active, and hopefully it will be solved soon, so I will be ready to test your code.

And...It seem they want remove openpilot bootloader feature, so it is possible I wont be able to flash my CC3D boards....:-(

from inav.

Here is one tester signing up!
I have Bix 3 with flaps, two HK450 helis, CC3D, two STM32F103C8T6 dev boards that support naze32 fw, ST32F4 Discovery dev board and I just got my self made shield PCB's from the manufacturer for it. They where originally meant for TauLabs fw, but since I have developed a interest to make cleanfligh run on it.
I also have bunch of sensors (Airspeed with pitot-tube, lots of HC-04's, bunch of different IMU boards, GPS's, etc.) and some FPV gear.
My plan is to stuff the poor Bix 3 with the STM32F4 Discovery board and all possible sensors, couple of cameras and make it as autonomous as possible. The goal is to make my own open source HW at some point, because I think currently all the interesting HW is (IMHO) quite over priced. I just can't justify my self spending 100$+ on something I can make my self cheaper, and probably better.

The STM32F103C8T6's are for the helicopters. One of them is going to be a autonomous camera platform and the other I am going to make a nice scale build of Bell 206, with couple of cameras and good flight stabilization and PH.

I am more than willing to help in any way I can. I actually tried to take crack at the servo configuration issue in the configurator, but my (very) limited knowledge of java became too big an obstacle given the amount of time I had to throw at it. I am much more familiar with C.

from inav.

@sppnk
I flash my cc3ds through the main port and ftdi adapter.
Ranger won't arrive fast, it'll probably be no less than a month before I would have anything to test. I also have to learn to fly airplanes beforehand :)

from inav.

@MDM63, welcome to the club :-)
At the moment fixed wing support in my navigation project is almost completely absent. You can have look at navigation-rewrite branch in my repo and give me a hand with developing fixed wing stuff if you like.
I'd be happy to receive ideas, insights, bug reports, working code, semi-worki code and even not working code if the idea behind it is good enough :)

from inav.

@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.

from inav.

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.

from inav.

@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.

from inav.

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).

from inav.

@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 😃

from inav.

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

from inav.

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.

from inav.

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

from inav.

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

from inav.

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...

from inav.

@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.

from inav.

@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...

from inav.

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

from inav.

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,

from inav.

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

from inav.

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

from inav.

@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

from inav.

@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 :-).

from inav.

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

from inav.

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

from inav.

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

from inav.

@sppnk great!

from inav.

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

from inav.