This is an update on the BrushedSparky that I posted about a month ago.

I got version 0.2 back.  There are a number of improvements over the previous revision.

• A bigger motor mount hole allows for stronger mounts.
• Using a 1.2 mm PCB shaves a bit of weight off. 
• Changed the 5V step up regulator for a new one that is more efficient (and doesn't hum).
• Using a more available VTX module so I can build more :)
• Shuffled some components around for a slightly slimmed profile (also got a stencil to make it faster to populate).
• Current monitoring (enables mAh consumed calculation)
• Switch to disable VTX for flying LOS
• VTX channel selection via the FC
• LEDs on the arms for following via FPV
• Two additional PicoBlade connectors for clipping arms to it and making a hex. Also two more buffered outputs on the back such as for LEDs.

So far I'm really happy with it and having a great time with it. A longer writeup can be found here: http://buildandcrash.blogspot.com/2015/03/brushedsparky-v02.html

OsoGrande got me into brushed microquadcopters recently. Sparky2 has some buffered outputs so at first I was just slapping it on frames and jury rigging things together. Very quickly, I wanted something more elegant.

I also wanted to make it easier to use an RFM22b TauLink for control while relaying the data to android, so I made a radio link board that is designed to go into a JR socket.

Which leaves me with a pretty nice system for micro FPV flying.

For a longer writeup check out my blog post.

I thought you guys might find this interesting. Support for OneShot ESCs was recently written for Tau Labs (http://taulabs.org) and it seems like most of the claims that it is good are largely subjective (which is perfectly fine). However, I wanted to really test the performance improvement with this different pulse scheme.

Here you can see the latency from an update from the gyro (MPU9250 IRQ) to the completion of the pulse is about 300 µs, which is much better than the several milliseconds with traditional asynchronous PWM.

I used our autotuning algorithm which estimates the system properties like the reaction speed of the ESCs on the same quad before and after engaging One Shot mode. The end result is a significant improvement in ESC latency as shown above. The results are statistically significant. Since the ESC latency is the prime performance bottleneck for quadcopters, this improvement will allow tighter PIDs and higher bandwidth control. That is the result of the autotuning algorithm - higher PID settings with OneShot than without.


For the longer writeup see here http://buildandcrash.blogspot.com/2015/01/oneshot125-quantitative-testing.html

So for the last week or two I have been looking a bit at the performance of the Tau Labs altitude control and INS filter we have and the altitude control loop.

One issue I was suffering from is that the velocity estimate would be biased because of variations in the accelerometer bias. I switched to using a 16 state version of the INS written by Dale Schinstock that included an estimate of the bias terms for hte accels which improved things somewhat.

I'm still not happy with the performance It is a dual loop control - the position error sets a velocity desired which then runs through a PI controller. 

So the first question I had was whether there was a problem in the estimation or in the control system. I grabbed some logs with my Freedom board and then also did some video processing. I swept a number of settings for hte baro variance and definitely if I assign to much noise to the barometer, then it doesn't track well enough. However, with the typical settings I use then it does a pretty good job of estimating the altitude. I made a video showing it with two values of the variance:

The plot on the right in some segments shows the segmented quad location from the video stream (i.e. ground truth)

One thing that struck me. When I tune it up to get a good estimate of position, that increases the noise in the velocity estimate. I feel like this ends up limiting my tuning parameters. I've also implemented the ardupilot complementary filter,  (keep meaning to grab a video log of that too) and cannot tune it to the point I'm happy.

Anyway, the solution I'm considering is to apply some low pass filtering to the velocity estimate in the controller. Essentially the velocity control component is like a derivative of the position estimate, and this seems like a reasonable / sensible technique. However, I'd love to hear any comments from others here.

Discussion at new Tau Labs forum: http://forum.taulabs.org/viewtopic.php?f=17&t=27&start=20

So Tau Labs just released a new software and firmware package. This works on windows, linux and mac. From the list of features:

• Horizon mode
• Exponential control for rate mode. Enables extremely fast flips likethis.
• Improved battery processing
• HoTT telemetry and receiver support
• Safety fixes
• Setup wizard
• Modules configuration tab
• UI improvements
• Altitude hold refactoring and baro accuracy
• I2C code rework
• Unified bootloader code
• Gimbal and CANBus support

It also works with our Android GCS which recently got a UI overhaul. So if you have a Quanton or Sparky then you should check out this upgrade. Or if you are looking to revitalize your CC3D or Revo, check it out.

For those of you flying Tau Labs or just looking to re-invigorate a CC3D and get some more fun, we implemented a "Horizon mode" based on the MultiWii code. What this does is when you keep the sticks near the middle, it will be in attitude mode (self leveling) and as you move the sticks further out it transitions into a rate mode. This is really fun for FPV because you have the ability to flips and more aggressive maneuvers while having the safety of a self leveling mode. I think the video above from Oso shows it off best.

Tau Labs Horizon working from Oso Grande on Vimeo.

If you want to try it out, here are the builds:

So I managed to interface my Leap Controller to the Tau Labs GCS and use it to control my Sparky based quadcopter by waving my hand around the sensor.  It's a pretty weird way to fly but became somewhat natural quite quickly.

Here is a video of it working, and if you stay to the end the first five attempts which were not quite as elegant:

Controlling quad with a wave of the hand from James Cotton on Vimeo.

A full write up can be found here http://buildandcrash.blogspot.com/2013/08/controlling-quad-with-wave-of-your-hand.html