One of the best new features of INAV 1.4 was Launch assistant mode (NAV LAUNCH). It greatly simplified the process of hand launching a fixed wing. All you had to do was to throw it into the air. INAV detected the throw, engaged motor(s) and stabilized flight and kept constant climb rate in the initial flight phase. INAV 1.5 will make it even better: it will also allow swing launch!
Since INAV 1.5 should be release in next 2 days, and there is very little info on INAV Launch mode, I’ve decided to create a short video showing how to do it.
Few days ago I've decided to do something new: timelapse video of a 3D print. It's kind of fascinating to watch extruder places layer after layer of molten PLA… too bad it's taking so long to print something bigger…
Printer: Malyan M150
Thing: 35 deg RunCam HD / Mobius stand for mini-quads
Let's be honest: in terms of mini-quad racing there is Betaflight (probably also Raceflight but I've never flew it yet, so will not comment on its flight performance), long long gap, and then it's everything else including Cleanflight, LibrePilot, INAV etc.
Originally INAV concentrated on "big" UAVs with GPS capabilities. After all NAV in name stands for Navigation. Mini-quads and acro performance were left alone, and once again, let's be honest: comparing to Betaflight, it sucked. It was possible, I've even written a short tutorial how to set it up, but it sucked.
Luckily, it is changing. INAV 1.2 had brought some improvements like Iterm limiting and acceleration limiting, and Acro flying in INAV became very nice. Small revolution, or maybe bigger catch up, is planned for INAV 1.3: asynchronous gyroscope, accelerometer and attitude processing. I've been working on it for last few months and results are very promising: INAV can drive a mini-quad with Betaflight comparable performance. Like this (please remember I'm not the best pilot!)
Marabou Stork, my Depron/Carbon/3D Printed FPV airplane is officially done. Although it had first flight a week ago, some technical problems postponed full feature trials until yesterday. I would not call it a "huge success", but it was fine.
Here is a video from some FPV flying:
After around 1 hour in the air, here are some conclusions:
Wing is closing to it's limits. Originally it was designed for an airplane that weights around 500g. Marabou Stork weights 900g. Do not get me wrong, it still flies good, I really love KFm-2 profile on it, but you have to start to remember about things like air speed, specially during turns: too much yaw, not enough speed and bam, you have stall. It's easy to recover, no problems there, but last years model (the same wing, less weight) was free of it
Neo-6m GPS is, hmm.., crap… I have to update to Ublox Neo-M8 as soon as possible
INAV is unable to process GPS altitude and barometer altitude simultaneously: altitude jumps up and down like crazy. For now, the only solution is to disable either baro or GPS altitude component from computations. It's simple and I will try to write few words about it next week
Did not tested fixed wing navigation features of INAV yet. Reasons: two points from above
Boscam TS-351 200mW 5.8GHz transmitter with crappy clover-leaf antenna behaves much better than expected. I had excellent reception on my Skyzone Sky-01 at 1km and had to return due to RC link RSSI warnings
I'm disappointed with FrSky X4R range. Looks like 1km is a safe side limit here. RSSI was dropping to 40 and did not wanted to push it further. Probably it's because crappy antennas. They are equipped with simple whips, not dipoles like X8R for example. Next week I will try connecting 2.4GHz dipole to X4R and will give it another try
For the last few week I’ve been little busy building my next fixed wing UAV: “Marabou Stork” Depron/Carbon/3D Printed airplane with pusher prop build for FPV. It’s improved version of “Red Cruiser” model from last year.
It’s equipped with KFm-2 wing, Turnigy D2826-6 2200KV motor, APC-E 7×4″ propeller, 2700mAh Lipo battery, FPV setup with MinimOSD and RunCam PZ0420H camera. And Flip32 running INAV for stabilization and navigation (no GPS yet).
As you can see on a video above, it flies. Even pretty well. It needs some tuning, but have big potential. Unfortunately elevator malfunction grounded it after few minutes in the air.
Last week I’ve been finally able to put my new mini quad into the air. It’s based on Reptile XR4 220 frame. Looks like I’ve succeeded with my build this time, since there were no major problems. Few minor, yes, but no major.
My Reptile X4R 220 mini quad has following specification:
Motors: EMAX RS2205 2300KV
ESC: FVT LettleBee 20A
Propellers: DAL 5040
Flight controller: SPRacingF3 clone running INAV with asynchronous gyroscope and accelerometer. I’ve already written few words about async gyro updates here
Radio RC link: ***FrSky X4R-SB***
Camera: Runcam Swift
VTX: TS5823S 200mW
Micro MinimOSD with MW-OSD 1.5
Here is short, uncut, video from maiden flight:
The only problem I’ve encountered, was with OSD. It stops overlaying data on aggressive maneuvers for a second and then OSD comes back again. Probably it’s because of voltage drop/noise. MAX7456 is extremely voltage quality sensitive. I will try to fix that with additional capacitor on 5V line this weekend.
Until recently, INAV concentrated on GPS and navigation support. Comparing to Betaflight, or even Cleanflight, its acro capabilities were rather limited. Flyable, but limited. Now we are trying to catch up. While upcoming INAV 1.2 will rather not change much in this topic, there are few experimental code versions that might greatly improve INAV acro capabilities. One of them is separation of gyroscope readouts from PID loop.
INAV and FP-PID with extensive floating point logic are rather slow. Looptime 2000us (500Hz update rate) is a limit for F1 targets and 1000us (1kHz mode) is barely reachable by most F3 targets. Version from mentioned above pull request separates gyroscope readouts and filtering from main PID loop. Thanks to that, gyro is updated much faster (up to 2.6kHz in case of F3 with I2C gyro). Faster gyro update means better signal signal quality, lower delay, better filtering and less aliasing. One the other hand, motors does not have to be updated that often. Not only they are unable to change rotation speed as fast as we can drive them, they are unable to notably change thrust as fast as we would like them to.
Let's do some math: what will the distance that tip of a 5" propeller running 12,000PRM will travel during 500us (2kHz update frequency)? About 40mm. More less 10% of a circuit. Not much distance to change generated thrust…
This might sound strange, but looks like it is working. Below is a short video of my 3S 250 quad running gyro loop at 2kHz and PID loop at 666Hz. Honestly? This quad never flew better! Please ignore my lame flying skills 🙂
If anybody would like to try asynchronous gyroscope on INAV, please drop me a message, I will compile and share this special version.
Below is a video I’ve recorder 2 weeks ago, showing almost fully automatic mission performed by INAV. The only “non automatic” phase in this flight was take off.
Besides regular nice views, this video presents a feature that will be available in future INAV 1.2: refactored and greatly improved MAGHOLD controller. MAGHOLD known from previous versions was very simple: rotation rate was dependent on a difference between actual and desired heading without any processing. Not only that, rotation speed was also strictly dependent on MAGHOLD P-gain and yaw rate. While this worked pretty nice for holding desired heading, it did not worked well in WAYPOINT or RTH modes when UAV was forced to rapidly change heading. Turns were usually too fast, could have caused roll/pitch instability and not smooth.
Because of that, INAV 1.2 will introduce new CLI setting mag_hold_rate_limit that limits the angular speed of rotation that MAGHOLD can require from UAV. At default 90 degrees per second it behaves almost like before. But it can be lowered to, for example, 30 degrees per second, and then, 180 degrees turn will take whole 6 seconds, instead of 2 or less like in older versions of INAV. Additionally LPF filter has been added to prevent any rapid heading jumps in MAGHOLD mode. And it does not affect manual turning. Pilot can still have fast yaw response in manual mode, and slow in WAYPOINT/RTH.
Effect? Take a look at this video recorder with mag_hold_rate_limit lowered to 25 degrees per second. Nice, smooth and long cinematic turns.
But that’s not all planned for INAV 1.2. There will be more!