Getting iNav ready for the SkyHook Discovery 2.6 – enter the cardboard V-Tail

Last month I got the biggest plane I’d ever held in my hands for a review.  This is the Skyhook Discovery 2.6.  It’s a really quite stunning 2.6m motor-glider that’s made of balsa and composite and has been careful thought out for flying FPV.  It is huge, but thankfully it all breaks back down a goes happily back into the box it arrived in.

 

 

I made a “first look” video on this at the time, showing how it goes together, and why I had to put it together outside.  If you haven’t already seen that, then take a look here –

 

So in the month since, aside from ordering some bits and pieces to build the plane, I’ve been considering an autopilot.  A traditional AP on the plane could be problematic as many AP’s expect both ailerons on a single servo control wire.  Whilst this would all work in terms of flying it normally, one of the Skyhook’s designers, Rob Thomson, explained to me how important it was to be able to use crow braking to slow the glider down.  Without it, it has a tendency to come in much to fast and glide on forever !

Some of what I would call the “premium” AP’s, such as the Eagletree Vector could handle the setup, but I just couldn’t afford to buy one at the moment.  So my first instinct was to not use an AP and just do everything I need to via radio mixing.  It’s not difficult to setup on the Taranis, and by not having an AP, we reduce the complexity of the build, which is always a good thing.  But I had a rethink – with the Skyhook so slippery in the air and able to potentially thermal for hours at a time, a simple radio link loss could result in it disappearing to mainland Europe.

Something that seems to be flavour of the month right now is iNav.  For the uninitiated (which was me a few days ago) iNav is a fork of the code from Cleanflight (in the same way that Betaflight was) it’s aim is to add the navigation facilities back into the code – which were in the original MultiWii code, but pretty much ignored in Baseflight, Cleanflight and Betaflight.  Most usefully, aside from being able to fly multicopters, with this code and suitable flight controller, it also supports fixed wing configurations.  Looking very quickly into the notes, I noted that it supported two individual controllable servos for aileron control.  So I decided to order an Omnibus F3 flight controller from Banggood as I could fly the glider with this, and have a useful OSD to boot.

iNav, like Cleanflight and Betaflight, uses a Chrome based configurator – so things feel familiar, while at the same time all a bit different.  It’s still a very functional configurator for multirotors, but there are fixed-wing presets available and new flight modes over the normal Betaflight.  I have to say that at this stage it all feels a little bit experimental – which I guess it is, as it’s still in the quite early stages.  This is reflected  with the amount of configuration you need to do with raw CLI commands.

My first problem is that of the available fixed-wing presets, there was only the choice of a general airplane (traditional ailerons, elevator and rudder), a flying wing, an quite curiously a very specific preset for a Wing Wing Z-84.  I had a V-Tail glider, and so dived into the documentation to find out what to do next.

Usefully on the GitHub page, there’s a section on how to setup iNav for fixed wing and from that page a link on how to setup a custom mix for a V-Tail.  It’s based on the setup for a Mini Talon, but it’s essentially the same setup.  What we need to do in this case is feed the commands into the cli

 

# mixer
mixer CUSTOMAIRPLANE
mmix reset
mmix 0 1.0 0.0 0.0 0.0         # motor

smix reset
smix 0 2 0 -100 0 0 100         # servo 2 takes Stabilised ROLL
smix 1 3 0 -100 0 0 100         # servo 3 takes Stabilised ROLL

smix 2 4 1 100 0 0 100          # servo 4 takes Stabilised PITCH
smix 3 5 1 -100 0 0 100         # servo 5 takes Stabilised -PITCH

smix 4 4 2 -100 0 0 100         # servo 4 takes Stabilised YAW
smix 5 5 2 -100 0 0 100         # servo 5 takes Stabilised YAW

I went ahead and typed these commands in, then typed save to write the configuration to the board.  I don’t like just taking stuff as read though, so I wanted to check how the commands worked.  The smix command takes the following parameters –

smix    Mix_Number    Servo_ID    Signal_Source    Rate    Speed    Min    Max

Some of these parameters seem a little undocumented, so a bit of figuring out and guesswork is required.  The Mix_Number is fairly straightforward, it’s just a number you assign each of the mixes you do.  Start from 0 and increment the number for each new smix.

The Servo_ID would also seem straightforward, but for the difference in human numbering systems and computers.  What we are referring to with this number is the servo pin on the board, but with a caveat.  What is PWM pin 1 on the flight controller, is 0 as far as iNav is concerned.  The first two ID’s of 0 and 1 are reserved for motors.  So when we talk about using Servo_ID 2 in the first mix, we’re talking about PWM pin 3 on the flight controller.

The Signal_Source is fortunately well documented.  It needs to be as well as it tells iNav what this will be used for in stabilisation.  The list of available ID’s looks like –

  • 0 Stabilised ROLL
  • 1 Stabilised PITCH
  • 2 Stabilised YAW
  • 3 Stabilised THROTTLE
  • 4 RC ROLL
  • 5 RC PITCH
  • 6 RC YAW
  • 7 RC THROTTLE
  • 8 RC AUX 1
  • 9 RC AUX 2
  • 10 RC AUX 3
  • 11 RC AUX 4
  • 12 GIMBAL PITCH
  • 13 GIMBAL ROLL
  • 14 FEATURE FLAPS

The remaining parameters is where things turn a little confusing.  We can look at Rate as both the direction and amount of movement, Min and Max as a possible percentage to move from to.  Speed though, I don’t know.  I’m sure there’s a document hidden away that might explain it.  But I’m prepared to take certain things as “this is how it is”

But now, how to test this out – the Skyhook is just too big to have indoors with the wings on, and I needed the wings on the test the surfaces.  So I came up with the idea of building a simple mock up that would fit happily on my desk and allow me to play with the settings until I was happy with the way everything was working – and could install on the Skyhook itself.  Enter, the cardboard V-Tail.

 

The concept here is pretty simple, I just wanted to duplicate the servo setup I’d have on the SkyHook, but in such a way that I would test the stabilisation as well.  So I cut up a box from Amazon I had laying around, used a bit of hot glue to stick it down and a BBQ skewer to make the V-Tail.  Surfaces were just more pieces of cardboard taped on.  The control horns little triangles of cardboard, and the push rods a mix of a few Z bended piano wire I already had, and some unfolded paper clips.  It’s neither meant to look pretty, or give uber-accurate movement.  I just want to see an indication that surfaces move the way I expect them to.

When hooking up for the first time though, I had some very weird results.  I connected up my receiver to the dedicated SBUS connection on the FC, missed the first two PWM pins (reserved for motors) and so connected my two aileron servos to PWM pins 3 and 4, and then the V-tail servos to 5 and 6.  The results were that the ailerons worked, and the V-Tail did not…. at all.  This confused me for several hours, until I found a specific iNav doc about the Omnibus F3. What this told me is that if I use the SBUS connector that I’d been using, this was effectively UART3, and if UART3 is used, then PWM pins 5 and 6 aren’t available for PWM.  But more than this, it also told me that PWM pins 7 and 8 are reserved for IC2.  Leaving me with just 2 usable PWM pins !

So what to do ?  Well, happily PWM pins 5 and 6 were only disabled if UART3 was used, so what I could do was run SBUS through UART2 instead, which *should* leave me UART1 to ru the GPS on. So I configured my “plane” as follows.  I run the lipo to my ESC via an XT60 connector and take the BEC output from that to my receiver.  A JST lead also comes off the XT60 and this plugs directly into the Omnibus GND/VBat pins (which powers it and reads the lipo voltage).  I then separate the signal wires from the servo leads and plug these into the FC.  The 4 servos that make up Vtail and Aileron, and the SBUS signal pin that goes into UART2’s RX.  The ground/5v wires of the servo leads are plugged into the receiver.  I also plug the additional 2 servos into the receiver (signal and voltage pins) which will act as my flaps.  It’s messy, but looks like this.

Once again, this isn’t going to quite mimic the setup on the SkyHook (a separate UBEC will be used) but it’s close enough.  From this setup, I could see that my servos now moved as I expected them to – in “passthrough” mode at least, but when I changed mode to angle in order to test the self levelling, the servos were all a bit twitchy.  Back to the iNav docs and I discovered the very important 6-point accelerometer sensor calibration.  I did this and read further on with the docs making sure I hadn’t missed anything else.  I ended up using the commands

set max_angle_inclination_rll = 600
set max_angle_inclination_pit = 600

These increased the angle of the stabilisation so it would be easier to see (although it’s not recommended to fly with them this high).  I also changed the arming angle so that my plane wouldn’t have to be completely flat to arm with.

set small_angle = 180 # arm in any position

Next up I followed the instructions on Tuning the iNav PIFF controller for Fixed Wing.  Zeroing out my P and I gains, before increasing the FF-Gain (D Gain) until I had around 90% movement on my surfaces with stabilisation switched on, then adding P and I back in.  At this point you should of course be flying to sort out your tuning properly, but these gave me a good basis to check things.

This got me the basic movement I wanted.  I had two modes setup in the flight controller so far.  Passthrough – where the flight controller does nothing except pass on your inputs, and Angle – which will self-level the plane and limit it’s pitch/roll angle.  Holding up the plane in Angle mode and leaning it over got the appropriate counter servo movement to right the plane.

So next, onto flaps, and more importantly crow-braking.  Flaps were easily implemented as the servos weren’t going through the FC.  I just added a switch on the two channels I used to connect the servos and put a mix in for about a 40-50% deployment – potentially,   the camber angle for launching.

Adding crow braking was a little more involved, but I was starting to become slightly familiar with the way iNav worked, so I thought they could be implemented through the flaperon mode.  The way this mode works is that it applies the flap output to the servo mixer input with ID=14.  If you recall from the ID table I added previously, ID 14 is “FEATURE FLAPS”.  Although the mode mentions using the ailerons as flaps, it does nothing on it’s own, so what I found I needed to do is add another smix command in order to tell it to do so.

smix 8 2 14 100 0 0 100
smix 9 3 14 -100 0 0 100

What this command does is tell the flight controller to is to treat servos 2 and 3 (my aileron servos) as flaperons when this mode is activated.  Currently I’ve left it at the default offset – as I’m not sure exactly how much is required, but this is tunable with the flaperon_throw_offset parameter that can be changed in CLI.  My final action was to add another mix on my Taranis so that the same switch that puts the flight controller into flaperon mode also deploys full flaps – achieving the desired crow braking.

As flaperon is an add on mode, it means I can still use stabilisation and have crow braking on.  So landings should hopefully be made easier.  I also made a YouTube video showing this concept in action.  Check it out below.

Now, my proof of concept looks good, I’m actually going to go and put the Skyhook together with some of this gear – so fingers crossed, the maiden isn’t too far away.

8 thoughts to “Getting iNav ready for the SkyHook Discovery 2.6 – enter the cardboard V-Tail”

Leave a Reply to CurryKitten Cancel reply

Your email address will not be published. Required fields are marked *