How I set up iNav – Version 2.0
How I set up iNav Flight
I wanted to document the process that I use to set up iNav Flight on a new flight controller, and what I’ll do when I update to a newer version. I also plan to include a database of working iNav dumps for my models, so that it’s easier for me if I need to re-flash, and other people may find them useful. This process is for fixed wing models, I don’t use iNav for multirotors. To follow this guide, you’ll need to download the latest copy of the iNav Configurator and a USB cable to connect your flight controller to your computer.
This article is currently based on iNav 2.0.0 using iNav Configurator 2.0.0, the images were grabbed from iNav Configurator 2.0.0-rc3
This document is currently a work in progress and not complete. I recommend checking with the iNav WiKi to check for missed steps. I will not be held responsible for any issues that occur.
Contents
- Setting up a fresh install of iNav
- Getting the correct target
- Flashing the firmware
- Updating iNav
- Downgrading iNav
- Initial iNav configuration
- Soldering to the flight controller
- Getting the transmitter talking to iNav
- Testing the control surfaces
- Testing our new setup at the field
Setting up a fresh install of iNav
Getting the correct target
The first thing you need to do before setting up iNav is to find out the correct target for your flight controller. You may find this on the product description page for your flight controller, or you can take a peek at what’s already on there. To do this, open the iNav Configurator and plug in your flight controller. Click the connect button. If the flight controller already has iNav flashed to it, you’ll get the full array of tabs down the side, in which case, click on the CLI tab. If iNav is not already installed, you should be taken straight to the CLI tab. Enter:
version
in to the CLI and press enter. You will be presented with the current firmware version and target of the flight controller, for example.
# version # INAV/MATEKF405 1.9.1 Apr 21 2018 / 13:25:29 (03a5c1922)
We are interested in the first part of the 2nd line where is shows the FIRMWARE/TARGET. In this case the firmware installed is INAV (could read BETAFLIGHT or whatever else is installed) and the target is MATEKF405. We now know that we need to install iNav for the target MATEKF405. As a word of warning, some BetaFlight targets may be more specialised or named slightly differently than with iNav, for example I had an Omnibus F4 V3 which on BetaFlight used the target OMNIBUSF4SD but on iNav used the target OMNIBUSF4V3.
Flashing the iNav firmware
New iNav installation
Click the disconnect button at the top of the screen and click on Firmware Flasher in the side bar. Next select the target from the top drop-down box, followed by the version that you would like to install. If I want to ensure that it is a 100% clean install, I turn on Full chip erase. Next click Load Firmware [Online] to download the firmware from the internet. Once downloaded, click the Flash Firmware button to write iNav on to your flight controller.
Updating iNav
There are a couple of things I should mention with regards to updating, some depend on how big an update is being performed. There are some stages that I gloss over, but they are covered in more detail later on this page. The first thing I always do before performing an update, no matter how big, is connect to iNav, go to the CLI tab, and enter either, for a minor upgrade:
diff
all
or for a major upgrade:
dump
Scroll right to the top and copy from the # version all the way to the bottom. Paste this in a new text document and save it in an appropriate folder and give it a name so that you know what it is and which model it is for, for example: iNav Backups/iNav 1.9.1 – Nano Goblin.txt.
Having a backup of your settings is so useful, it allows you to roll back to any previous version you’ve used. If you don’t do this and it’s discovered that iNav 2.0.0 has a bug, without the backup, it would be hard to go back to previous settings when downgrading back to 1.9.1. Another example of backups being useful would be if your flight controller dies, you can just set it up a new flight controller, perform the calibration, and write your backed up settings dump to it.
Minor iNav updates
Minor version updates, for example 1.9.0 to 1.9.1, I just do the same as a new installation, making sure that Full chip erase is not selected. The only difference is that after downloading the firmware from the internet, I will read the release notes to see if anything has changed that may effect the settings on the board. For example, in a past release, the developers changed the multiplier on the current sensor by a magnitude of 10, so previous settings of 12 would now be 120, this allowed these devices to be tuned more accurately. Any changes that may effect my settings, I make note of and correct after flashing the firmware.
Major iNav updates
With major version updates, I do things differently. Usually major version updates change the way things work, and older settings may cause issues. After saving my settings, I do a new installation of iNav with Full chip erase enabled. I’ll then connect in to iNav and perform the sensor calibration, Save and reboot, followed by applying the preset for my model, and Save and reboot. Next, I will enter the CLI tab and get a dump of the new iNav installation. We now need to use a notepad/word processing application that can compare two file. On Windows, I use the free program Notepad++ and a plug-in called Compare. Load the backup of the previous version’s dump into the text editor, now create a new document and copy in the new dump from iNav. Compare the 2 dumps and the differences should be highlighted. Go through the differences between the two dumps and make a decision on whether or not to copy the old value from your previous installation to the new. You can use the release notes for help, but in all cases, I would not copy values related to the PIFF/PID settings. If you want to use your old values, insert the value into the new dump file. I understand that this may not be the clearest of explanations, however, Joshua Bardwell has a video on how to upgrade BetaFlight, and it’s the same process. Once you’ve made your changes to the new dump, copy that back in to the iNav CLI and save the changes. You should very much treat this as a new install, and test everything thoroughly.
Downgrading iNav
To downgrade to a previous version of iNav, flash the firmware as if it’s a new install with Full chip erase enabled. Perform the calibration and write previously backed up settings dump for that version to the flight controller. If you don’t have a settings dump for that version, you will need to do a dump and compare between the closest backup you have and the freshly installed iNav dump, in the same way as a major version update above.
Initial iNav configuration
Calibrate the accelerometer
The first thing I do in the initial config is to calibrate the accelerometer. To do this, connect to the board and click on the Calibration tab. To calibrate the board, you must first set it level, top side up and click the Calibrate Accelerometer button. The first time you do this, it may not actually take a reading, but post a brief explanation of what to do. Click that box away, make sure the board is level and click Calibrate Accelerometer again. This time it will record the position. Looking at the screen, you can see images of the board/aircraft in multiple orientations. You need to position the board in these orientations one at a time, and click the Calibrate Accelerometer button in each orientation. Other than the first position, it doesn’t matter which order you perform the rest of the calibrations. Once complete, click Save and reboot, something you’ll find you do quite a lot with iNav.
Setting the mixer
The next step is new with iNav V2.0.0 and it’s to set the mixer for the model. This is much improved and simplified over the previous system. Head in to the Mixer tab and first select the type of model in the platform type box. Next you will be able to chose the mixer preset that best suits your model. These presets make setting up the model so much easier compared to the older versions of iNav where you’d manually have to mess about with mixes in the CLI; 99% of the time, the preset will work with what you have, and it makes it easier to tweak and add things to the mix via the configurator. NOTE: Servo reversing is still done in the servo tab. Once you’ve selected your preset, click Load and apply, then Save and reboot.
Setting a preset
The next step is to set a preset for your aircraft. For fixed wing this is usually going to be either Airplane General for planes or Flying Wing Z84 for flying wings or planks. These presets will set appropriate starter PIDs, gyro filtering, and other settings for these types of aircraft. Select the appropriate preset and click the Apply button. You will see a warning of how selecting the preset will overwrite some settings and how you should still tweak the settings for your specific aircraft. Click Save and reboot to apply the settings.
Running a CLI script to set common properties
The last thing I do in the initial configuration is to run a script in the CLI window to set common settings. Going through the iNav Wiki, you’ll read about things to set in the CLI for fixed wing aircraft, my script encompasses all this plus settings for auto launch, features, failsafe, GPS, OSD layout, return to home, and throttle. I’ve included my script below, with the exception of the OSD settings. I highly recommend setting up the OSD how you like it, use get OSD in the CLI to copy the settings and paste them in your own script. You will need to add set to the start of each line, so that it looks like the script below. # indicates a comment, so those lines aren’t read by the CLI. After entering the script into the CLI, you must type save and hit enter to save the changes.
Though this main document has been written using iNav 2.0.0, whenever I update my script because of a version change, I will add a selectable script below. Choose the version best suited from the list.
Read through the comments of the CLI code above, as you may need to change some values for your model. These defaults are set for a flying wing, if using an airplane, you will need to change some of the settings. All the commands are commented (green) so that you can understand what they are doing. You can copy and paste this into iNav’s CLI and hit return. Remember to enter save afterwards and hit return, otherwise the settings will not be written to the flight controller.
Soldering to the flight controller
It’s at this point, with a new build, that I start soldering everything up. I’m not going to enter into that here in detail, as it will be different for different flight controllers. However, I’m going to give a list of the parts that you’ll need to get in the air and some pointers.
Parts
The most obvious parts you’ll need is the airframe and everything required to fly it as a naked model, so a motor, ESC, propeller, servos, and receiver. With the receiver make sure that it supports 1 or 2 wire protocols, for example with FrSKY you want a receiver with SBUS and S.PORT connectors; with Spektrum, I believe that satellite receivers are used which directly plug in to the flight controller, but, you need to use a full size receiver with the satellite installed to bind to the transmitter first. A receiver takes usually uses 1 UART, but due to inversion some FrSky receivers may need 2 UARTs on some flight controllers. Next you will need the parts related to getting iNav working:
- Flight Controller. If you’re reading this, you most likely already have a flight controller. If not, go for a minimum of an F4 board, I’d recommend the Matek boards, for example the F405-STD, F405-WING, and F722-STD. With the flight controller, you’ll need to make sure that it has enough UARTs (communications ports) for what you want to connect to it, and bare in mind that some things, like FrSky receivers, send and receive their communication inverted.
- GPS Module. You should get an M8N compatible GPS module (beware, there are a lot of modules going around that are M8M and should be avoided. If they mention M8M or no flash memory, leave them on the shelf). Good examples of these include the Beitian range. I mostly use the Beitian BN-180 (which is tiny), and the Beitian BN-880. One thing to note, you don’t need to worry about built in compasses at this stage. Fixed wing aircraft in iNav don’t need to use them, however, you may find them advantageous later on. A GPS module requires 1 UART.
That’s all you need to get iNav working, though it would be a lot more fun if you could see where you’re going. For that, you’ll need some FPV equipment:
- FPV Camera. Your eyes in the sky. There are plenty of cheap cameras for getting started like the Eachine C800T (16:9) and Eachine 1000TVL (4:3, but watch the form factor on this one), but there’s no questioning that better quality cameras are worth the extra, the RunCam Micro Eagle is an amazing camera.
- Video Transmitter. You don’t need to spend loads on a VTx to get a decent signal, you’re better off getting decent antennae, but here are a few VTx that I’ve used of have seen in friend’s builds: Eachine TX526, RunCam TX200 (great for close range micro/light weigh builds), Matek 5.8G VTx, ImmersionRC 600mW (highly rated but pricey and limited, also may be illegal in your country). Some VTxs allow you to change settings through the flight controllers on-screen menu, through protocols such as TBS SmartAudio and Tramp Telemetry. If you wish to use this, it will need a free UART.
- Antennae. You will need a few antennae, 1 on the model and 1 or 2 on your receiver, depending on if you’re running a diversity setup. It is well worth investing in decent antennae. They can make a huge difference in the effectiveness of your FPV system. I highly recommend Video Aerial Systems antennas.
- Goggles. A lot of people will say that box goggles are fine for beginners, but in all honesty, I wasted enough money on box googles to buy a 2nd hand pair of decent goggles in the first place. Maybe it’s my eyes, but I wish I’d gone straight for the goggles I have now, FatShark Dominator V3. There are plenty of decent goggles for every budget from the Aomway Commanders/Skyzone SKY02’s to the FatShark HD3. One thing to remember though, is that with the FatShark goggles, you’ll need a receiver too; with the Aomways and Skyzones they’re built in. This is a good and bad thing. Good because if the receiver fails, you just replace the receiver; bad because there is a little more money involved initially, though this can be as little as £30.
- Video Receiver. For the FatShark goggles, you’ll need a receiver These don’t have to be super expensive LaForge V3s or anything like that. I’m getting really good results from a circa £20 Eachine Pro58 module, flashed with the Achilles firmware.
Flight controller orientation
When you install the flight controller in the model, pay attention to the arrow on the flight controller as this will effect our set up. Ideally try to get the arrow facing forwards, but if this is not possible you need to tell the flight controller so that it can compensate. To do this, go to the configuration page and you will need to set the Yaw degrees in the Board and Sensor Alignment section. Enter the angle of rotation, Save and reboot, then in the setup tab verify that moving the physical model makes the same movements on screen. The simplest way is to have the back of the model facing you, reset the view, and then move the model. This has to be right otherwise the stabilisation and navigation modes will not work correctly.
Getting the transmitter talking to iNav
The first thing that you need to do is create a model on your transmitter. Regardless of what you’re flying, the model on the transmitter should be a standard classic plane configuration with no mixing on the transmitter whatsoever. This process varies for different brands of transmitter, so wont be covered here. Keep note of the channel output order as this will be needed in iNav, for example a Taranis (see image) the order will be (A)ileron, (E)levator, (T)hrottle, and (R)udder – so you’d need to remember the acronym AETR.
Next bind your receiver to the transmitter. Again, this process varies between brands, so won’t be covered here. The final step on the transmitter side is to set failsafe, once again it varies, but you want the receiver to output no commands when it loses connection with the transmitter, on Taranis this setting is called No Pulses (see image) and on Crossfire it’s Cut.
- In iNav, the first thing that you need to do is go in the ports page, and enable Serial RX on the UART that the receiver is connected to, UART 2 in my example, then save and reboot.
- Next head into the configuration page and find the receiver section. You will need to set the protocol type and receiver type to what you are using, so for me it’s Serial-based receiver and SBUS, then save and reboot.
- Next head in to the receivers tab and check that the channel order matches that of your transmitter (remember our Taranis example was AETR).
- Next move one axis at a time and make sure that when the stick is either up or right the value for the correct channel is at 2000, down or left the value is 1000, and centred the value is at 1500.
The channels should be correct as we have matched the channel order to our transmitter. If a channel is reversed, you can reverse it on the transmitter until it goes in the right direction. If the values aren’t exactly 1000, 1500, and 2000, you will need to adjust the channel end points in your transmitter to get these correct.
Testing the control surfaces
Now that our transmitter is talking to iNav, the next step is to test the control surfaces. To do this, make sure your prop is removed and plug in a flight battery. Move each gimbal and make sure that the correct surfaces are moving in the correct direction. If a surface is not moving correctly, do not reverse that surface in the transmitter, it must all be corrected in iNav. If a control surface is moving the wrong way, head in to the Servos tab and click the reverse button on that surface and re-test. Aircraft with mixed surfaces, for example flying wings or V-tails, will always need one servo reversed on these surfaces. For example, 90% of the time, a flying wing will need servo 3 reversed. Most of the time, you will be able to get the control surfaces working correctly with servo reversing, in very few cases the mixer may need altering, however that’s outside the scope of this page. Once your surfaces are working correctly, head over to the motor tab and click the enable button. Slowly increase the output to the motor until it starts to spin smoothly (you can move the sliders with the up and down arrows on the keyboard). Underneath the slider is a number, I round up to the nearest 5, then disable the motors and go to the configuration screen. On the right hand side, find the box for minimum throttle and enter the number in there. While here set minimum command to 1000 and maximum throttle to 2000, then Save and reboot and disconnect the flight battery.
Modes
For the next part of the testing, we need some flight modes. I recommend following my 5 flight modes and arming on a single channel tutorial to set up your arming and flight modes. For full disclosure, I no longer use this method as I have modified my Taranis with a 6 position rotary switch, which I use for flight modes. However, if I had a stock Taranis, I would 100% use this method.
Stabilisation
Now we have some flight modes, we need to test that stabilisation is working correctly. Connect the flight battery and put the model in to horizon mode (will need to be armed also if you’ve followed my tutorial). Bank the model to the right and the left aileron/elevon should raise to try and level the model. If you roll left, the right surface should raise. Next dip the nose down and the elevator or both elevons should raise to try to level the nose. If you point the nose up the surfaces should lower. If you have yaw control, this should be tested too by spinning the model to the right and seeing the rudder move left. This should all work perfectly as we have ensured out transmitter matches what the flight controller is expecting. The biggest cause of problems with stabilisation is incorrectly set transmitters or flight controller orientation.
Failsafe
While we are at the bench with our flight controller plugged in and our transmitter connected, take a look at the top of the iNav configurator for a set of icons, in particular the parachute icon. This is the failsafe status indicator; it will either be grey – transmitter not connected, blue – transmitter connected, or red – transmitter no longer connected, failsafe activated. Right now the parachute should be blue, switch off your transmitter and if all is setup correctly the icon should turn red, indicating that failsafe has activated. If this is not the case, you will need to double check your transmitter/receiver and how they interpret failsafe. The iNav Wiki can point you in the right direction.
Testing our new setup at the field
At the field, there are a few checks to make before we take to the skies. I have a few checks to do on the ground, and then a testing procedure for the first few flights, to make sure that everything going forward works without a hitch.
Ground tests
Test 1 – Range test
The first test is one that should be carried out for every RC model as it can detect issues with the radio link before even leaving the ground. The for the range, you put your transmitter in range testing mode, then walk away from the model while moving the control surfaces. Each transmitter will have a different procedure and checking distance, so please read the manual of your system to get this right.
Test 2 – Failsafe
Even though we tested this on the bench, it’s always good to double check it in a real world situation. Make sure you perform this test with the prop removed as the motor will spin.
- Switch on the transmitter, insert the flight battery, wait for a GPS fix, then arm the aircraft.
- Apply the throttle to no more than 1/3rd and run with it at least 50m away from the power on point.
- Switch off the transmitter.
All being well, the aircraft should try to climb (increase throttle and may move control surfaces). Make sure that you can regain control by switching the transmitter back on and move the pitch and/or roll stick. If this works, your failsafe is set and will perform as desired in flight.
Test 3 – Preflight checks
I do these check before every flight, so it makes sense that they should be done before our maiden flight too.
- Test flight battery – Use a battery checker to make sure that its full, or at least has enough power for the flight.
- Control Surfaces – Plug in the battery and check that the control surfaces move in the correct direction and that they are not impeded in any way. This will also ensure that all linkages are attached.
- FPV system – Make sure that you’re on the right channel and that you have picture.
- Power check – Have someone hold the model securely and give the motor some beans to make sure there’s enough power for flight.
That’s it for on the ground, the next step is to get that plane in the air and carry out the maiden and test flights.
Test flights
Test 1 – Getting in trim
This flight is all about manual mode and again is similar to the first flight of any RC model. As it’s the maiden, you may want someone else to launch the model so that you have both hands on the sticks; but if you are on your own, try to launch with a hand on the pitch and roll stick and set the throttle with your mouth. Get the model in the air and trim using the transmitter trims until you achieve straight and level flight at cruise throttle. Once you’re happy, land the model and have something available to measure the control surface deflection, I’ve bought myself a cheap digital angle measure for this. Measure the control surface deflections, noting them down, then reset the trims to centre on the transmitter. If you’ve had to use sub-trims, make sure to remove these too. Physically set the deflection of the control surfaces using the measurements that you just took. The transmitter should now have no trims set and the surfaces should fly the aircraft straight. Launch and test. If it needs adjustment, repeat this step until it’s good. Once you’re straight and level with no trims, continue on to the next test.
Test 2 – Putting the stabilisers on
The next thing we’re going to test is the stabilised mode, and get this flying level. Take off in manual and get a few mistakes worth of altitude, and switch into a stabilised mode. I usually use horizon for this, so I’ll just write horizon, meaning the stabilised mode, for the rest of this test. All being well, nothing much will happen except for a smoother flight. If something does go wrong (it’s not happened to me yet) flick back in to manual mode, land the model and start finding out what’s wrong (check the transmitter movements in the receiver tab are correct and the board alignment for starters). If horizon works correctly I’ll set the throttle to cruise speed and take my hands off the sticks. If the plane doesn’t fly level, watch for changes in roll and pitch, land and adjust the flight controller pitch and roll angles slightly (2 to 10 degrees based on the amount of movement seen) to counter this movement (If the FC is rotated 90 or 270 degrees, pitch and roll are swapped). Take off and try again, it’ll either be better or worse. If worse go the other way, if better keep changing that way until you achieve level flight. Once you have hands off level flight in horizon or angle, all the other automated/stabilised flight modes will work better.
Test 3 – Maximising the flight envelope
This test, isn’t really a test, but a performance enhancer, and it’s all about making the most of the stabilised modes. Switching on roll and pitch angles on in OSD makes this a lot easier, but you can estimate if you’ve not enabled them. Make sure you are recording DVR footage, then in manual do some full deflection rolls and loops, not exceeding the limits of your airframe. The 2nd part of this is done later at home, when you find the start of the loop and roll (level flight), then go forwards 1 second measuring the loop or roll. If you have the angles on the OSD, this will be straight forward; but if not, estimate the number of rotations, for example 1.5 rolls and 0.75 of a loop, then multiply those number by 360 to give the degrees per second. My example would be 540 degrees per second in the roll axis and 270 degrees per second in the pitch axis. In iNav configurator, go to the PID Tuning page and on the right side, near the top there are boxes to enter the roll rate and pitch rate, enter your figures in these boxes and click save. Your model will now roll and loop as fast in stabilised modes as it does in manual mode.
Test 4 – Testing the automated flight modes
Once you’re happy with horizon (stabilised flight), get some altitude and start testing other flight modes. Cruise should just work as we’ve got horizon working, but you just want to make sure the altitude stays consistent. Once cruise is confirmed working, I’ll test loiter, again being ready to switch out if anything looks wrong. Finally, once I’m happy that the previous modes are working fine, I’ll test return to home. I’ll first test at above 300′, where it should just turn to home and loiter when it gets there, slowly descending to 200′. If this works, I’ll switch back to another flight mode, and fly away staying at around 200′. When I activate return to home this time, it should turn to home and climb to 300′ before loitering around home and descending to 200′. If this all works, I’m confident that everything is set up correctly and working.
After that if I’m feeling saucy and it’s a calm day, I may do an auto tune to improve the PIFFs. Then I just enjoy flying the damn thing. After this, other than if I’ve made changes, the only in the air test I do is a quick return to home trigger each flight to make sure the home point is set correctly.