How to measure gyro noise frequency with Blackbox

Cleanflight / Betaflight / INAV lowpass filter tuning can be a hard thing to do if you have not idea what is noise frequency you want to cancel. Sure, you can blind test or read tutorials. But what if I tell you, you can measure it quite precisely using only Blackbox logs? Or measure rotation speed of motors? That would be nice, isn't it? The only requirement are few seconds of Blackbox log with visible gyro (it can be also motor output or Pterm or even ACC reading) noise.

Read more...

Air Crash Investigation: gone in 6 seconds

"What goes up, must come down". I had an opportunity to face this old truth 2 weeks ago, when my 600mm quadcopter felt from 30 meters straight into water.

It was supposed to be a simple flight:

1. take off
2. fly few hundred meters away with GPS assist
3. engage Return To Home and land

Dozens of missions like this in last few months, so really, nothing special. Unfortunately, like I mentioned above, not everything went as planned. 2 minutes after take off, UAV lost stability and went down with screaming motors. Read more...

PWM, OneShot125, OneShot42, Multishot and DSHOT comparison

Two years ago it was simple: you wanted to connect ESC to Flight Controller or radio receiver, you were just doing it. There were only one (maybe 2) protocols that allowed to pass information to ESC. It was a standard PWM protocol. And it was enough. No, with faster hardware, mini or even micro quads, this one protocol is not enough. So, we also have OneShot125, OneShot42, and Multishot. Should we care? A little.

• Legacy 'Analog' PWM signal - this protocol is not used in the multirotor world. It is supported only by an extremely limited number of ESCs and radio receivers. 0% PWM duty cycle means 'Stop' and 100% PWM duty cycle means 'Full power'. Modern UAV pilots/builders should not take about it at all. The interesting fact is that BLHeli supports it as PWM Input option that is disabled by default.
• 'Standard' PWM signal - I've previously described this protocol here. To recall: protocol encodes requested output as a length of a pulse. The pulse length of 1ms means 'Stop' and the pulse length of 2ms means 'Full power'. Because of this, maximal theoretical update frequency is 500Hz (490Hz in practical applications). Signal delay in case of PWM protocol is 2ms. It means, that ESC can start to update output 2ms after the flight controller started to send this information. All of that makes PWM rater slow, and using loop times below 2000us (refresh rate 500Hz) makes no sense.
• 'OneShot125' protocol - this protocol uses 8 times shorter pulses than standard PWM protocol: from 125us (stop) to 250us (full power). That means 2 things: it allows for 8 times faster PID control loop update rate (looptime 250us / 4kHz update rate). It also has 8 times shorter signal delay: only 250us instead of 2000us. Currently, OneShot125 is the minimum for mini quads. Even bigger machines will appreciate smaller delay. Supported by most flight controllers and ESC (SimonK, BLHeli, KISS, other). If both Flight Controller firmware and ESC supports OneShot125, it should be used.
• OneShot42 is 3 times faster version of OneShot125. Max 12kHz update rate and 42us signal delay. It was developed by Flyduino as part of KISS FC and ESC 'program'. Not widely supported yet.
• Multishot - the fastest ESC protocol in this comparison, developed by RaceFlight, allows for 32kHz update rate. It is almost 10 times faster than OneShot125 (80 times faster than PWM). Requires both fast FC (preferably STM32F4) and fast ESC (Silabls F390 preferably). Not widely supported mainly because of a limited number of 'Multishot ready' ESCs. And it has fancy startup melody too... man...
• DSHOT that comes in many versions, DSHOT300, DSHOT600, DSHOT1200... This is the "digital" protocol. It's not based on the length of a pulse but uses zeros and ones send just like over a serial port to control ESCs. With error control, fast update and commands like "beep" or "reverse". In theory the best on. It's not supported by all the software and hardware tho.

BLHeli firmware for ZTW Spider 40A OPTO Small ESC

ZTW Spider 40A OPTO Small ESC with stock SimonK firmware can be easily flashed with BLHeli using Cleanflight interface. I just did it, the whole process took few minutes. To be true, it took me more time to find out which firmware should those ESC be flashed with, than to flash them. For unknown reason this information is well hidden in the internet! So, here is short guide:

1. We will be using Cleanflight BLHeli passthrough interface. It is build in in laster Cleanflight / Betaflight / INAV firmwares
2. Use latest BLHeliSuite. I used 16.3.14.7.0.0
3. Connect ESC to flight controller
4. Connect flight controller to USB port
5. Run BLHeliSuite software
6. From Interface menu select ATMEL BLHeli / SK Bootloader (Cleanflight)
7. Select COM port and click Connect
8. Connect ESC to battery
9. Click Check to detect connected ESCs
10. BLHeliSuite will detect unknown firmware with SimonK bootloader
11. Select ESC (1, 2, 3 or 4) and click Flash BLHeli
12. Here comes funny part. There is no ZTW Spider 40A OPTO Small formware! Documentation states that ZTW Spider 40A should be flashed with BlueSeries 30A firmware. But images in docs and mine ZTW Spiders differs a little. But, looks like it is not a problem. Select BlueSeries 30A MULTI firmware and flash
13. BLHeli 14.x enables Damped Light by default. That might not be a best idea for big (> 8") propellers so you might want to disable it

Bottom line: ZTW Spider 40A OPTO Small ESC should be flashed with BlueSeries 30A BLHeli firmware!

EMAX SimonK Series 30A ESC - 3 months later

When 3 month ago I was doing "Hands on" review for EMAX SimonK Series 30A ESC I was quite optimistic about them. Well, why should I not be? Quite cheap, decent quality, easy to configure. Did EMAX 30A SimonK Series ESC met expectations I was putting on them?

Simple and short answer is: no, they did not met expectations. Reason is: one of them caught fire during flight causing whole UAV to fell from 30 meters into water.

As you can see on the pictures above, ESC is completely burned. Both MOSFETs and electronics. How do I know it burned during flight and caused a crash and not the oter way? Thanks to Blackbox logs I have a proof that this single ESC and motor connected to it were gradually losing power before UAV crashed. Since motor and attached propeller survived without a scratch, ESC is the one to blame.

To make things worse, it was not too much load that killed it. Before crash ESCs were running at around 45% throttle. That is around 7A per ESC. Way below promised 30A.

So, final conclusion: no, maybe they are cheap and easy to use, they are not reliable! And that is the critical flaw of those ESC!

Reptile X4R 220 - maiden flight

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
• Matek PDB-XT60
• 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.

Hands on: Piranha Multitool from Banggood

All RC enthusiasts know this algorithm:

1. Build
2. Fly
3. Crash
4. Repeat

Sometimes there is "buy" instead of "build", but rest stays the same. What goes up must comes down and very often there is a need to fix/repair something on a airfield. Basic tools are a must when going flying! I've decided I carry too many of them and I must combine some of them into one multitool. So, I've purchased a Piranha Multitool from Banggood.

One tool combines:

• Pliers
• Wrench
• Knife
• 2 screwdrivers

Whole tool makes a solid impression. It is made from steel and at a first glance it does not looks like it wants to fell apart after first usage. Pliers has a cutter and a safety switch and looks strong.

Wrench also feels solid, but there is no limiter, moving part can fell off. Not highly probable, but possible.

Knife looks like the weakest element of whole set. It feels flimsy. I hope I'm wrong.

Conclusion? For ~$12 it looks and feels fine. Hope it will work fine too.

INAV 1.2 RC1 has been released

After 3 month from previous release, INAV is preparing for a new version. INAV 1.2 will be quite massive, with a lot of new features and improvements. Full change list is available here. I will only describe the most important and "visible" changes.

• Rates are no longer stored in arbitrary units like 0.4. Who knows what 0.4 means? How fast UAV should rotate when this rate is set? Is 0.8 twice as fast as 0.4? (The answer to that question is "No") To solve this problem, INAV uses degrees per second [dps] to define maximum rotation speeds. INAV Configurator provides nice and simple user interface for that. The ones who uses CLI has to remember, that INAV stores rates in dps divided by 10. So, set roll_rate=72 means that roll rate equals 720dps. GitHub INAV Wiki has a page that describes how to convert INAV 1.1 rates to new system. Also, RC Rate setting, as obsolete, has been removed.
• FP-PID has been rescaled to match LuxFloat and MWRewrite PID controllers. That means, if you have tuned drone in either Cleanflight or Betaflight, you can just use the same PID settings in INAV now, without a need to retune. That also means, that tunes from INAV 1.1 will not work in 1.2. This page or this Google Docs Spreadsheet can be used to convert INAV 1.1 PID to INAV 1.2
• Just like latest Betaflight 3.0, INAV 1.2 has a feature that allows to limit angular acceleration. This might be very useful when tuning big and heavy frames with a lot of inertia. They are just not capable of angular acceleration that operator might require from them even with stick movements. If frame oscillates/shakes during stops, that means that it is unable to satisfy required acceleration/deceleration, Iterm winds up and as a result, frame overshoots target only to try to correct that fractions of a second later. To get rid of that effect rate_accel_limit_roll_pitch and rate_accel_limit_yaw CLI variables can be used. They represent maximum angular acceleration/deceleration in degress-per-second^2 [dps2] UAV operator can request. By default it is disabled for roll and pitch and set to 10000dps2 for yaw.
• Improved MAGHOLD controller that results in much smoother yaw movements in RTH and WAYPOINT flight modes. New mag_hold_rate_limit setting limits yaw rotation rate MAGHOLD controller can request. Default of 90dps is enough for agile UAVs. For slow, cinematic, turns, value of 25dps generates good results. I already described this improvement here
• Flaperon flight mode. Available only on fixed wing (not on flying wing) platforms. When enabled, both ailerons will be deployed down to act as flaps. Flaperon behavior is driven by 2 CLI variables:
  • flaperon_throw_offset determines how far ailerons will be deployed
  • flaperon_throw_inverted allows to invert aileron throw in Flaperon mode. Can be used to create spoilerons instead of flaperons
• Greatly improved GPS performance
• Maximum climb/descend rate in WAYPOINT mission flight mode is now limited by nav_max_climb_rate setting (in centimeters per second)
• More precise expo curve resulting in smoother UAV behavior near sticks center positions
• Greatly improved landing detection mechanism that can effectiveness detect landing and disarm motors in RTH mode
• Just like Betaflight, INAV saves configuration (PIDs, rates, etc.) with Blackbox logs. Both Betaflight and INAV blackbox viewers can be used to get config from logs. Great for tuning, since log contains both flight data and configuration used to obtain this data
• Turn assistant flight mode - when enabled, yaw movement will be done in parallel to ground plane, not UAV plane
• Full stick range is now used in ANGLE and HORIZON flight modes
• More data reported via LTM protocol
• Initial MAVLink support. It is far from completed, but MAVLink enabled ground stations should be able to receive telemetry from INAV.
• Support for nRF24L01 transceivers. Fly Naze32 with Syma radio? Now it will be doable
• Multiple bugfixes and other improvements

How to dispose / utilize LiPo batteries

LiPo batteries that run RC hobby are potentially dangerous devices. When not handled properly they can ignite or even explode. And they do not live forever. Even the best battery, no matter how taken care off, loses capacity, swells and has to be disposed. When we combine both facts we face a problem: how to dispose old LiPo batteries if they can catch fire? It's extremely hard to find a place that accepts them for utilization. Throwing out with garbage is not a good idea. Disposing with popular alkaline batteries might sound as a good idea, but it is not either. So, how to utilize old LiPos? This is quite easy...

1. Build a LiPo discharge device using 24V halogen light bulb. No high-tech here, just a way to connect light bulb to a battery. 12W halogen is generally a good option for both 3S and 4S LiPos
2. Put a battery inside ceramic pot with some sand (not flammable if thing go very very wrong for any reason), connect "discharge device" and let it do its job. Light bulb limits discharge current, so LiPo should discharge nicely without extra swelling or overheating Read more...
3. Aug 8, 2016

   INAV 1.1 for Naze32 with working telemetry

   As long as Naze32 / Flip32 are decent flight controllers for those who does not demand too much, they share very big flaw: low flash memory size. While even a year ago 128kB of flash was enough, times changed, and limited flash makes a problem for advanced flight controller software like INAV. Starting from INAV 1.1, STM32F1 flight controllers started to pay a penalty of disabled features. That time it was "only" telemetry providers other than LTM. Next time it might / will be more.

   During last few weeks I've received few request to compile INAV 1.1 with enabled FrSky and/or SmartPort telemetry on Naze32 target. While I have nothing against doing that on request, I've decided it would be better to just prepare special version of INAV 1.1 for Naze32 users with all telemetry providers enabled. Link to ZIP file is at the bottom of this post.

   • This version has LTM, FrSky, SmartPort and HOTT telemetry enabled
   • To fit telemetry in limited flash memory, following features has been disabled:
     • OLED display support
     • DJI NAZA GPS module support

   INAV 1.1 for Naze32 with telemetry enabed

   Read more...