Micro MinimOSD stops overlaying in flight: solution

Both MinimOSD and Micro MinimOSD suffers from irritating technical problem. In some setups, they stops overlaying data during hard maneuvers or even right after arming. Problem is very simple: chip MAX7456 is extremely sensitive in terms of supply voltage quality. Working motors and/or servos, can introduce enough power supply noise to occasionally force MAX7456 to reset.

Luckily, solution is simple: separate LC power filter or big enough capacitor connected in parallel to 5V pads of MinimOSD.

Almost any big enough electrolytic capacitor will do (> 100uF, the bigger the better) but best results can be archived with low ESR > 500uF capacitor.

In my case symptoms were not very strong, usually only very fast flips caused MAX7456 to reset, but I've decided to go big: 1000uF low ESR capacitor.

Micro MinimOSD has 5V pads on a side and they are the best place to attach capacitor.

As you can see below, capacitor is bigger than MinimOSD itself and I had to think a little how to place it inside my Reptile X4R 220 frame.

Results are great: no more MinimOSD problems. OSD stays on all the time, no matter how hard I use the stics.

Preview: cheap APM Power Module for Cleanflight

Recently I've got my hands on a pair of cheap APM Power Modules from eBay with integrated 5V BEC and current meter (90A max). Although they are APM designed and will not work stright away with STM32 flight controllers like Naze/CC3D/SPRacingF3 (or rather would work only once since they are 5V scaled and those flight controllers require max 3.3V input) I have an intention to make them work!

So far, I've concluded that:

• current measurement is done with Texas Instruments INA169 and 0.5Ohm shunt resistor
• analog current out is 5V scaled, so probably 90A current flow results in 5V on meter output
• voltage sensor output has 1/2 voltage divider. We can ignore it, most SMT32 flight controllers have voltage dividers (CC3D does not, but 1/2 is not enough in this case)
• It more less works with a 1/2 voltage divider between current sensor and flight controller. Requires some tweaking, but something is measured. Will require scaling!
• Integrated BEC works, and this is all I can tell about it I'm affraid

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