Sparky Brushless Gimbal Controller testing

Time for a follow up on my previous post about the brushless gimbal driver add-on for Sparky!  It is now working and I even have some testing flights when I'm quite happy with the results.

Iconic-X Frame modification

I mounted two GoPro's on my Iconic-X FPV frame.

The first is obviously mounted like the normal FPV camera (which then uses a minimosd as described here).  I then bolted the RCTimer 2-axis gimbal to the top of the isolated part of the frame (very little vibration in this configuration).  Also, tanks to Kendall at UAVObjects for having the gimbal in stock and really fast delivery.  So at this point it's quite a monsterous beast (and one I don't want to crash).   You'll see it works really well for roll but I haven't tuned up the pitch quite enough.

It also still has the minimosd being fed directly from Sparky to provide an OSD which you'll see again in the video below.

UG-2 Gimbal

I was also really excited to get a brushless gimbal for larger cameras from Rusty at AGLHobbies which is using two motors that are prewound from RCTimer.  You can see it in the second half of the video above although I need to get some more flights in and do some more tuning to really show it off. Here are some pics of putting it together for anyone that was as clueless as me.

I have a little bit of testing in the video below and it's working pretty reasonably (like the RCTimer gimbal Sparky is under-compensating pitch) but this was the first flight and I need to spend some time tuning it.

Tests

So without further ado, a video:

Sparky Brushless Gimbal add-on success from James Cotton on Vimeo.

When demonstrating the gimbal in flight there are four screens.  The normal FPV from gopro, the version from the ground station (with OSD overlay), one from a fixed tripod, and finally the stabilized gimbal.  Overall I'm pretty happy with the results and want to take this out in a big field and do some FPV and enjoy the video madness.

You can see during some of the more aggressive maneuvers the attitude drifts - this is likely the complimentary filter drifting from acceleration.  I'll try tweaking the settings and seeing if I can get it more resilient.  There is also a noticeable under-compensation in pitch although I'd say it is eating up 95% of the movement.

 Control Scheme

So this threw me for a loop for a few days.  It was trivial to get it working ok but I wasn't getting great results.  Especially roll just had insufficient torque and felt sloppy.  I ordered a gimbal controller (the Martinez controller I believe) from UAVObjects (thanks again) and pretty quickly got the RCTimer gimbal working, so I now knew the hardware was capable and that I was failing.  However one thing I picked up pretty quickly from the tuning settings people were using was they typically used a lot less power than I started with (e.g. around 30%) which did improve things substantially.

I conceded defeat and looked into the code at https://code.google.com/p/brushless-gimbal/.  What seemed odd to me was that the gyro came in twice - once where it was integrated to determine the electrical output phase (scaled by what they called Kp) and a second time after the integration where it was added to the phase to create a phase lag or lead essentially (what they call Kd).  That seemed a bit odd, but when you write it out that basically is the same as normal Kd, except they bypass differentiating and then integrating it right back.  I'm guessing this improves the noise performance.  This term made quite a difference.  Here is a picture of the control scheme for the curious:

Where in my case I'm using essentially attitude control mode where the outer Kp maps to that Ki, the inner Kp maps to that Kp, and then I have an additional damping term that is fed into pios_brushless.c which creates a phase offset to the integrated position.  There are still lots more knobs to tweak, and I'd like to try setting that damping to zero and using a normal Kd since we have control over the bandwidth then.  At least convince myself I can get somewhere similar.

Anyway, that was fun.

Also I want to thank, ReadError who is awesome and threw a few brushless add-on boards in with one of his PCB orders.

Sparky: testing and building (no crashing??)

Update2: Sparky2 is available here http://www.hobbiesfly.com/taulabs-sparky2-0.html
Update: for information on Sparky 2 see this post

Warning: there are reports that some of the cheaper boards (e.g. from Witespy / ReadyToFlyQuads) have problems with the baro, so you will not be able to do altitude hold or navigation. There is also no "V1.2 2.0" - he is selling version 1.0 with known problems.

Now that I have some boards back of the final revision of Sparky, I've been hard at work upgarding my fleet from CC3D.  If you missed the previous posts, Sparky is somewhere between CC3D and Quanton/Revolution. There is also discussion the old Tau Labs forums.

Basically this board evolved cause I have a lot of frames and wanted something high quality and easy to make a bunch of for myself.  Hopefully others will like it too.  Here is a list of the features

• Smaller than CC3D by 20%
• Single sided for easy assembly and also you can double sided tape it to things
• It has a mag, accelerometer, gyro and barometer which means it is capable of full navigation (hopefully I'll do some RTH testing this week).  
• Two serial ports, one of which supports Mavlink + GPS so you can have OSD, GPS and Telemetry.
• Altitude hold
• Runs the full INS EKF at 500 Hz
• There are 10 channels of output (of you can use some of those for ADC inputs for battery / RSSI sensing)
• OSD via minimosd using mavlink protocol (so you can run the regular firmwares or the minimosd-extra)
• CAN bus support with built in driver for easy extensibility
• Daughter board that can drive a brushless gimbal system (still under development to get it really locked in)
• Camera stabilization support
• It is not designed to take PWM inputs though, to keep the size down.  It supports DSM2, S.Bus, and PPM.  I know not everyone will like this tradeoff although you can use a PWM to PPM converter if needed.

So I've been putting it through the ringer and having lots of fun.  If you saw my previous post, I built a pretty cool tricopter that has the servos on the front and can do horizontal forward flight.  Here are the rest of the things I converted over to Sparky:

So those are

• Triblivion
• UAP-1 with RusticWave gimbal
• Iconic-X FPV frame (from Quadaddict)
• Aggressor (again from Quadaddict, a great sport flyer)
• HT-FPV
• And a UG-2 gimbal I'm tuning up

The receiver port pinout is super useful, at least for me.  All my quads are flying using an OrangeRX satellite and the receiver port has both the board supply and regulated 3.3V. That means each board I just solder three wires of the satellite cable to the board and I'm good to fly.

It's nice to no longer need a satellite adapter like on CC3D.  Now I just need a few more OrangeRX satellites (hurry up Hobbking!).  I'm really happy with how they all fly, although I think one of the motors on aggressor is going bad (again, hurry up Hobbyking!).

Here is a video showing off a few of the features.  I need to spend a lot more time flying to really show this thing off, and hopefully I'll get some RTH tests in this week.

Sparky Testing from James Cotton on Vimeo.

The main things this shows off are

• Altitude hold
• OSD with home direction and coordinates (F3 ADC code is about to merge so then I'll redo this with battery voltage and current on the OS D too).  Sorry the video recorder was cropping the screen, and my RF link wasn't behaving terribly well :(
• Camera stabilization 
• Brushless gimbal control with a daughter board

I still need to test position hold and return to home - hopefully the wind drops in the next day or two.

Soldering

Now that I have six soldered up for myself and getting my fleet airborne again (selfish bastard I am), it was time for a solder party to make a few boards for devs and testers.  It was a long couple of hours, but actually went faster than when I made the first 15 prototype CC3Ds for testers (man that was ages ago).  That's the big benefit of keeping it single sided for home assembly.  Anyway, I took some photos for you guys if you haven't seen the process before.

Jigging them up and using the stencil to apply paste

All the ICs are now placed.  Woops, short one MCU.  Always should count parts before deciding how many to solder.

Ok, now all the parts are placed into the oven with you.  Careful not to put any on the bent wire since I did that the other night and knocked one down, ruining all the placements *sigh*.

And the finished product.  All flashed and ready to rumble.

So that was my Saturday evening.  Well there was also scotch.  I have a few spare so if anyone wants one drop me a line.  I'll make another batch if there is demand.

Update: Here is a demo of Sparky doing PH and RTH:

Sparky testing PH and RTH from James Cotton on Vimeo.

Brushless Gimbal Driver add on for Sparky

So back in January when I designed Sparky, one of the goals was to keep all the components on a single side.  Aside from making assembly a breeze, the advantage of this was that I could make an add on board for the back which would drive a brushless gimbal.

I finally got around to making a prototype a few weeks back and got to test it this weekend.  The results are pretty decent for a first test.


Sparky Brushless Gimbal add on board testing from James Cotton on Vimeo.

In the first part with the transmitter it is in manual mode.  In the second part it is holding the attitude based on the transmitter stick.  In manual it moves smoothly but I still need to do some tuning for attitude mode.  It seems to ratchet a bit which I think is essentially being overtuned and briefly having the velocity go too high.

I hacked up a different controller that seems to work a bit better, but I don't want to get too obsessive testing until I get a more realistic load (gimbal + camera) set up. It might also be fun to try using the LQR controller again for this.  Plus autotuning should let me characterize the whole gimbal performance just like a quad and optimize it.

Fun times!

Oh, and one other cool thing I need to try.  Since Sparky was sort of designed with this in mind, I'll connect two of them via CAN so I can relay the desired gimbal position from the main flight controller Sparky to the brushless gimbal Sparky.  That way both transmitter control and also things like POI tracking should work.  Similarly we can use CAN to the ground station modem and make an antenna/camera tracker pretty easily.

The last thing I really need to decide on: if I don't want to continue having lines to enable or disable the gimbal outputs, then I can use 9 channels and drive a three axis gimbal.

I'm also kind of tempted to hack the ESCs I made to drive a brushless as well so that it can be added to any FC as a PWM output (credit goes to dongs/timecop for doing this the other day).

Rover testing fun

So thanks you Vassilis for writing a path planner module for testing ground control navigation.  For those that don't know, Vassilis was one of the main designers behind the architecture that powers Tau Labs: UAVTalk, UAVObjects and how we clearly separate the code between the Modules.

I was testing this the other day to drive in a 10m box:

Rover Navigation Testing from James Cotton on Vimeo.

and a few things stood out.  First, I was using an OpenPilot GPS, which it turns out does not like to work near the ground.  Despite reporting a high signal quality, it was easily drifting around 10m in airplane mode.  It's possible other settings would work different, but be wary.  I've got a CN-06 module that just arrived which I'll replace it with.

Despite that, I could look at the high speed logs from the Overo and see that it thought it was doing well given that noisy information:

It's quite overtuned as you can see from the oscillation around the desired path, but not bad for out of the box initial settings.  Also asking a car to drive in a box at a fixed velocity is an impossible task so I'll try later with mitered edges.

The more striking thing was the knack of the it to spin around 360 degrees while driving south.  I reproduced this in normal attitude mode (where the sticks just say head North/South) and noticed it only occurred when being told something near -180, never near +180 (which are physically identically). Finally digging through the logs I found a case where it happened and sure enough desired was -170 and the current heading was more like 170.  I mocked up all the values in matlab and everything seemed fine, but the acuator output had the wrong sign!

Finally it turned out fmodf produces negative values, which is different from Matlab, and this bug can be fixed with a simple four character tweak.

Anyway, I drove this around and it works well now.  Once I get the GPS replaced with something that works better, I'm looking forward to making it drive around the park or use tablet control to follow me around.

TriBlivion and Sparky

Update2: Sparky2 is available here http://www.hobbiesfly.com/taulabs-sparky2-0.html

Sparky

I recently built a flight controller board for Tau Labs named Sparky.  It uses an MPU9150 for the main sensor, which combines a 3-axis gyro, mag, and accelerometer which allows tracking the attitude of the airframe.  In addition it has an MS5611 pressure sensor for altitude sensing and control.  One of the main goals for this board were to keep it small and single sided - so it could just be taped onto things.  I also kept three of the holes compatible with the same mounting pattern we have been using so it can easily be swapped out for CC or Freedom.

It has a micro-USB header and 12 PWM in/out pins.  The receiver header breaks out VCC in and 3.3V so it can directly power a spektrum satellite receiver (or in my case an OrangeRX) without an adapter.  There is also a JST-SH header for GPS.  I've already designed a revision with an additional serial port exposed for telemetry as I've become addicted to using my tablet in the field for tweaking.

The first flight tests were quite pleasing

Sparky First Flights from James Cotton on Vimeo.

The smaller frame (Silver Hornet) was using off-the-shelf ESCs so it can't be tuned as aggressively.  The larger one has my ESCs so tunes in really well.  Altitude hold worked quite well - the baro wasn't even covered.

Here is the schematic and code

pdf version: https://dl.dropboxusercontent.com/u/6645063/Sparky.pdf

code: https://github.com/peabody124/TauLabs/tree/sparky

TriBlivion

In addition, ever since I saw the trailer for the movie Oblivion, I really wanted to build something like the aircraft Tom Cruise' character flies.  It has two front motors that can rotate so it can basically behave like a tilt rotor.  I ordered some parts a while ago and they've been sitting around for a while and I finally decided to try and build something similar, which I call (for lack of a better name) TriBlivion.

The front two motors are mounted on servos (using an adapter from servocity to provide some strength).  The yaw channel is mapped to drive each servo in opposite directions to create a yaw torque.  In addition there is an accessory channel mapped to point them both forward to create forward thrust.  I'm really pleased that it stays extremely close to level in this condition with the motors pointed forward at about 30 degrees.  It did need the battery quite far backwards to balance the weight of the servo cages.

I know normal tricopters are meant to have a good yaw feel but I've generally been underwhelmed with my tail servo one.  In comparison this yaw feels EXTREMELY locked in - more than anything else I've flown.

This will hopefully make a really good FPV frame since the camera can be mounted on the front and have a forward view while flying forward.  Of course, it's going to be really important to not get confused since while in motors tilted mode full negative pitch will basically make it stop but you'll be looking at the sky.  This is also just stage one of my quest to build a tilt rotor aircraft and get the best of both fixed wing and quadcopter behaviors.

So here it is flying

TriBlivion from James Cotton on Vimeo.

Unfortunately flying into the fence at the end stripped both servo gears, so it will be a week or two before I get more gears and try it for FPV.

Build list:

• 2x Servo blocks http://www.servocity.com/html/standard_hitec_servoblocks.html
• 2x Hitec servo http://www.servocity.com/html/hs-6635hb_stan__hi-torque.html
• 3x KEDA 20-22L http://hobbyking.com/hobbyking/store/__4700__hacker_Style_Brushless_Outrunner_20_22L.html
• 3x ESC http://hobbyking.com/hobbyking/store/__6548__Hobbyking_SS_Series_18_20A_ESC_card_programmable_.html
• 2x align 450 size tubes
• 7x clamping blocks http://www.shop.aglhobbiesllc.com/Frame-Spare-Parts/Delrin-Clamping-Block.html
• 3x motor mounts http://www.shop.aglhobbiesllc.com/Motor-Mounts/UAP1-Large-Universal-Slotted-X-Base-Mount.html
• cut G10 plate to sandwich motor mounts at 90 degrees

Tablet control testing

So I finally got some flight tests done with Tau Labs' tablet control feature, although it was a bit on the windy side. In this mode the flight mode switch is flipped to "TabletControl" and which point control is ceded to the tablet. This means you can use labeled buttons to control from a large number of flight modes instead of confusing switch positions, as well as seeing the performance from the tablet.

Tau Labs Tablet Control from James Cotton on Vimeo.

This mode allows Position Hold, Return to Home, Return to Tablet, Follow Me, Fly Path, Camera POI mode and Land. Most of these are demonstrated in the video. This follows up on some previous work here

AndroidGCS Transmitter - Navigation Control Demo from James Cotton on Vimeo.

but I found the OPLink wasn't reliable to use as the only link and had some fly-aways. This system keeps the regular transmitter in ultimate control in case anything goes wrong. Safety testing is demonstrated as well to show that the motors shut off when the transmitter is turned off. The new architecture makes it easy to define other failsafe behaviors like RTH on transmitter loss, but not until navigation is extremely robust and well tested. The results of enabling Fly Path mode were a little disappointing. It would hit the first few waypoints but the requested velocity and path follower settings weren't aggressive enough to fly upwind. More testing soon hopefully! You can get the tablet software here although the tablet control interface is disabled by default until it is a bit more tested.

Tau Labs kicking along

So for those of you not following our forums, Phoenix Pilot has an official name: Tau Labs.  For the brief announcement see here.  Honestly, this group is just great.  All of the main developers from OP migrated over in the early days so it's nice to have the team still working together.  In addition we regained a few people who had left OP due to the various politics there and some new people.  Edouard Lafargue who was one of the main developers of the GCS is has been helping fix some bugs in GCS telemetry and also extend the plugin system to better support new boards.  David Carlson has just designed a shield for the F3 to make that easier for people to use (and making a really cheap full autopilot solution).  Angus Peart, one of the co-founders of OP, has rejoined the project and is a great guy.  He developed the first generation of hardware which was the basis for CopterControl, wrote a lot of the original core code, and also set up the original OP forums.  We also have Vincent Kessler now who developed the port to the F4 discovery board and then the F3 discovery.  He is a great developer with an eye for details, and his F3 port really opened up a new platform that makes it readily available and makes it easy for anyone to get involved (in flying or developing).

On a side note I owe a serious apology to David Carlson for how I treated him over some OP drama a few years ago.  I let myself be talked into scapegoating him and should have trusted my gut after meeting him in Portugal that he was a great guy.  After I was driven out too I ended up thinking a lot of similar things to him.  Essentially the complete lack of transparency or administrative and financial accountability left the project too much in the control of one person.  That is fine for a company but not for an open source project where people donate thousands of hours to have the rug pulled out from them.  It leaves you with no recourse of how to keep playing.  That's why I'm so please that he and Angus established the OmniLoco foundation which is the non-profit in charge of Tau Labs.  It really forces us to put policies in place to protect against that.  In addition we've tried to structure as much stuff to be as light-weight, low-cost and open as possible to avoid repeating previous slippery slopes.  Luckily everyone on the board is like-minded on these issues and I don't see any problems.

The project is just so much more fun now.  Things are much more productive when no time is wasted on bullshit politics: trying to belittle other people or projects, or plotting how best to protect a product at the expense of the broader community.  On a related note I've been reading this book Against Intellectual Monopolies which I'm really loving.  It discusses when industries stagnate and lose the ability to innovate a common response is to try and restrict things and protect their monopoly position by suppressing other innovators (rent-seeking behavior).  It's both eye opening about the general issue of IP (and relates a lot to Open Source) and seems to speak to recent issues.

So clearly we have a great group together.  It reminds me of the original Portugal summit where it was just a group of friends who got along well and really like working on the same problem; it feels like a real team.  Software-wise development is really storming ahead.  There is a test build up which is all nicely branded for Tau Labs and flies superbly for me on a number of aircrafts.  Hardware wise Quanton should be out shortly, the FlyingF3 is available, and the latest revision of Freedom is out being made.  We've gotten a lot of messages from research and academic teams and who want to use our software / hardware for their projects which is extremely exciting and one of our big goals we established in our original meeting.  There is still a lot of work to be one with documentation, wiki'ing etc, but it will happen.

Here are some fun things I got working recently.  First was getting my RusticWave gimbal kicking ass!  I've been trying to get good video from the Sony HX9V for more than a year and this is the first time I was really happy:

Best stabilization so far on UAP-1 with RusticWave from James Cotton on Vimeo.

Then I've been doing a lot of work on the android app (now up on the store).  Here is me switching quickly from viewing the quad with bluetooth during normal flying to controlling via the phone.  I wouldn't want to fly this much outside though.

Flying silver hornet with phone from James Cotton on Vimeo.

Then for anyone interested in trying out the auto tune functionality is here a quick how to video showing it off:

Autotuning Howto from James Cotton on Vimeo.

And last but not least, I finally got my Iconic-X upgraded to 10" arms and went out FPVing for the first time in a while.  There were momements where the sun glare really killed me contrast but it was lots of fun:

Iconic-X FPV flying from James Cotton on Vimeo.

So as you can see, exciting times!