EEG architecture and software development

Plan

So now the EEG board is out for manufacturing it is time to start designing the software. I figure I can use an existing Sparky to generate fake data and begin on the android application. Here are a few of the features I want to have in the app:

• Configuration (e.g. setting reference electrodes and bias configuration)
• Noise measurement
• Waveform visualization (with filtering)
• Spectra visualization (as well as pseudocolored time plots)
• Basic control app (e.g. 2-D cursor that you try and move around)

So this will be done by modifying the existing software stack (android app and sparky firmware). I think I will keep the UAVO manager in place and use that for general settings and status information. This can work via the USB HID interface.

Initially for the data stream I will attempt to run it via UAVO updates as well to try for the greatest reusability of the code. However, if this doesn't work then I'll use a VCP stream. This just gets a bit awkward when using TCP as then we will need two independent streams (e.g. separate sockets).

Since the data is 24 bits wide, I could either pack it into int32 fields or just use real units and represent it as a single - the latter seems preferable to me. I'll make an object which has a sample counter and an array of singles. In the future if I use multiple ADS1299 then I can just go ahead and use a multiple instance UAVO.

So with this plan the steps going forward are:

1. Create the data UAVO
2. Create a firmware module that in the future will read from the ADS1299. For now it will just generate synthetic data at 200 Hz.
3. Check that all the samples are received
4. Create an android activity that plots the traces

Implementation

Streaming bandwidth

With a modified firmware in hand sourcing sin waves sampled at 200 Hz, I got hacking on the Android app. I wrote a telemetry task that runs within the service context and keeps a running buffer of the last few seconds of data. It monitors for any skips in the sample counter and at that rate I see about 1 or 2 skips every second. Not perfect but good enough for now. It's comfortably sustaining 10 KB/s.

Later I'll try and determine if those are skips on the firmware transmission side or somehow they are dropped updates on the android side. The event system doesn't indicate any missed updates so I'm guessing that is what is happening. It's pretty nice because the built in logging for the UAVs is working for this transparently, so I can email the logs and process them with the matlab code for visualization.

The top row shows the diff on the sample index. It looks like most of the time there is a missed update there is a zero for the counter difference - so I'm guessing there is a timing error  on the flight side and it is skipping one sample and then sending duplicates of the same data point. Since the whole point of this is streaming this data I will modify telemetry to have a special queue that actually stores the history of values to send instead of pointers to which object to send. It might be easier to have the EEG module try and pack the data too if that doesn't break telemetry talking to the the USB comm device.

Visualization

For now I just wanted a simple streaming graph. I'm using the GraphView library which is pretty straightforward and seems to perform well.

And then you can plot all the channels. This gets a little tight on screen real estate and also the update rate starts to drop a bit. For fancier visualizations like this I will probably need to come up with a more performant library. Also, without modifying GraphView it isn't possible to get the graphs all close to each other. Perhaps one widget that is directly rendering it all. However, this isn't a huge issue right now so I'll put it off.

Spectrum

It can also plot the spectrum of the traces. No labels yet. The speed seems reasonable. 

Finally a simple spectrogram plot. None of the bells and whistles such as selectable channels or multiple channels yet, let alone windowing parameters. I'll leave that for when I know what I'm looking for.

This doesn't have a logarithmic scale yet, so the 2 Hz wave is close to the edge of the axis (full bandwidth 100 Hz).

Conclusion

Anyway, not a bad start I think. When it is charged tomorrow I'll try the app out on my Nexus 7. The bigger screen should be nice, although I think both it and the Nexus 5 are 1080p so no real pixels extra. Some of these functions I'll probably backport to TauLabs as having some of the plotting functions might be useful in the field.

Now It's really just wait for the board to arrive, or start reading about various signal processing algorithms and start hacking. However, those are typically better done on real data. The logging function will be extremely useful for having the code already written to record the sessions.

EEG Design - time for something totally different

So I've wanted to build an EEG since I was in college and have numerous times spec'd out parts etc but never really got going. I've followed the OpenEEG project for ages, but technology wise it has remained rather stagnant. However, I just recently came across the OpenBCI project which pointed me at the ADS1299 chip and that has reinvigorated my interest in building a simple EEG. It's a long shot, but my ultimate plan is to create a system like this:

One thing I wanted to change from the OpenBCI design was to use an STM32 processor, since that is what I'm more familiar with. My goal is to avoid a lot of the safety issues regarding powering from a computer by running the data via my phone. This also gives me free perks like wifi, screen, bluetooth, etc. I should be able to pretty easily use the Android GCS as a basis, especially since that already has a lot of the core code for handling data via USB (HID and Serial) as well as WiFi (great for running simulations).

It was pretty straightforward to base the design off Sparky which seemed like a pretty good starting point - both in terms of electrical and mechanical properties. I had to extend the board a bit to fit the ADS1299 on there without going to four layers (I'm cheap and would rather a bigger board for the prototype). This is the end result:

The final board is 50 x 35 mm. I can easily shave 5 mm off the right side, but figured I'd leave it this size in case the next revision has more channels and needs that space.  Currently it is single sided so lots of room for expansion. And it's nice because I can reuse a lot of the code from Sparky and just write a new PiOS driver that speaks to the ADS1299 chip. For laughs, I left the accel/gyro/mag chip in case I want to have some kind of head tracking. Either that or try and use it strapped to my arm like a Thalmic labs wrist band.

Here is the schematic. Sorry the layout is really ugly - I should redo the TPS60241 component so the power comes in on the left and goes out on the right.

Layout

The ground plane is split to keep the analog electronics and digital electronics as separate as possible. The top plane on the analog side is AVDD and the bottom is AVSS. This is where a four layer design would be a bit better but for now I'll save some money.

Top:

Bottom:

Features

• 8 Channels of single ended input, 1 driven bias electrode and one common reference electrode
• Small (36mm x 50mm)
• Utilizes ADS1299 chip
• Optional reference and bias electrodes
• Powered by USB. Small step up inverter generates a clean 5V after the input diode (probably not necessary if I never plan to use battery input). This can supply up to 25mA of current and the analog supply only requires 10.
• Single sided power supply design (so patient will be at 2.5V relative to the board)
• Solder pad allows using any electrode (routed out via SRB2) to serve as the negative input for the others. Alternatively use an additional reference electrode such as an ear clip.

Notes and quirks of the ADS1299

There were a number of things that were not obvious to me from a first pass through the datasheet. This is mostly a reference for me when I forget them after I came to a conclusion.

biasin - At first I assumed this input was something to do with computing the actual bias value. However, it is actually for situations where you want to reduce the number of electrodes going to the patient. In this case, you actually connect the biasin signal to the positive pin of a channel (i.e. electrode) which creates the path for the driven bias current. This will (obviously) introduce a small bias into the signal recorded on that channel, but this should be small and slow compared to the signals of interest.

srb1/2 -  Again, like with biasin, at first I assumed that both of these were meant to be treated as inputs. Either to provide a reference for the positive or negative inputs. However, (and again like biasin) this is to allow reducing the electrodes to the patient. In this configuration, you select an electrode (positive input) that will serve as the reference for others and route it out of SRB2. Then there is an external bridge from SRB2 to SRB1 which passes this signal back in and allows it to be the negative channel for all the other electrodes.

Input configuration

The ADS1299 has a pretty powerful analog multiplexer - but what is a tad counterintuitive or non-obvious is that channels can be mapped to inputs or outputs implicitly. The input mixer also gives lots of options. I'm going with what I think is the standard configuration and what seems most referenced in the EVM notes. This means the CHxSET register will be 000 for the mux "main" with SRB1 high. The positive values will all be routed out to the electrodes and the negative values will all go to SRB1.

Anticipated bias and reference

The full cable set will generally be used, at least at first. This means a reference electrode (e.g. earlobe) will come in to SRB1 and be connected to the negative input of all the channels. All of those channels will be averaged internally to compute the biasinv signal. The internal bias generation (2.5V) will be used for the positive input. The output (biasout) will then go to an electrode (via a protection resistor).

Thoughts

Inputs - OpenBCI used the negative inputs at SRB2 for their channels. I can't really understand why they did this (although it looks like it should work) but it won't be in "normal electrode" mode. 

I'm pretty tempted to switch a bipolar power supply like that in the EVM. The advantage of this is the patient is driven to zero volts relative to the digital electronics. This shouldn't ever be an issue provided everything is running from batteries but still is a potential safety improvement. It adds another chip though.

Isolation - one thing OpenBCI did quite nicely was solid isolation. This is important, especially if you want to make something commercial. I'm just goofing around and will try and only use it via phone or worst case when laptop is not powered by mains. To be honest, I just don't feel like putting all the components down for it.

Ground - Related to the the isolation issue, I hope I routed the ground appropriately. The ground plane is split - digital ground over the digital electronics and analog under the ADS1299. The digital grounds from the ADS go over to the digital ground plane and then are star grounded to the analog plane near the analog regulator. The AVSS and AVSS1 are both just connected locally to the ground plane rather than separately routed back to the star ground. The AVDD plane is similar.

Also one limitation of using my phone to collect the signals (provided processing power isn't the limit) is that I cannot simultaneously connect to a USB radio and control a quadcopter. However - if I get to the point that is the limit I'll happy redesign and use something like Freedom with more build in processing in the embedded board, or combine an RFM22b onto it.

Anyone have any comments on the schematic? I don't think I've got any glaring errors but you never know...

References

• http://www.ti.com/lit/ug/slau443/slau443.pdf
• http://www.ti.com/lit/an/sbaa188/sbaa188.pdf - good DRL notes
• http://www.ti.com/lit/gpn/ads1299
• http://www.openbci.com/technology-update/

Android Update

I pushed a pretty major update of the Android application to the Google Play Store today that I'm quite pleased with.  Felix Da Cat suggested using a Navigation Drawer to get around the app (he actually suggested it on the OP forums, which puzzles me since they don't have an android app). A year back I tried getting rid of the home page by using a spinner bar at the top and really wasn't happy with the results, but this worked much better.

So you swipe from the left hand side or touch the title bar and you can directly jump to the other pages. The back button should work fairly intuitively to the previous view. This also led to me converting more pages into fragments and really working on how they store state. The most useful of these changes was in the map, so that when you rotate the tablet or phone it will preserve your current zoom level and location. Also the zoom level is cached between runs so no more starting at an awkward way zoomed out distance.

Tablet mode got some aesthetic love. The armed/flight mode notifications were added to the PFD which cleared up some space. Also it didn't seem necessary to show the alarms (cropped) at the bottom of the page when you can just touch the alarm summary button. Getting rid of that junk made it easier to handle rotations in tablet mode too - which behaves reasonably for phones (at least on my N5) and tablets.

The browser was touched up. Editing and viewing both take place in the side view (which behaves well with rotation also) and the back stack will take you back to the previous UAVO you were viewing (but skips editing). This system seems to work well, although it is a bit tight in portrait mode on a phone.

Finally the most useful change (at least to me) is the map now shows a history of where the UAV was. This shows up as a small white trail. Currently rotating or changing screens will flush this which is unfortunate. Later I need to make this aspect of the logging happen at the level of the telemetry service so it can persist between views. But that is for another update. Unfortunately I don't have a screenshot from when I was outside so feel free to send me one :).

Easy logging with OpenLog

So one of my friends has wanted something light and easy that he can use to log data, and also Aqualuna on IRC has been wanting something similar. After seeing some of the logs that Ardupilot produces that my friend was getting with his Revo port I was really encouraged to just come up with something quick and easy that would just work.

And this was definitely easy. I think it took about 15 minutes from when I told Aqualuna I definitely wouldn't start working on this to having a working log file. I used an OpenLog and then connected it up to the flexiport on Sparky. Then I configured it to run at 57600 baud and first showed that it would work and collect data using the mavlink output. 

However, this has a limitation that there is no timestamping data (or handy parsing code) so I decided to adopt the uavorelay module to this purpose. Luckily from the Overosync module I'd added a native timestamped packet to uavtalk so I just modified it to send that type of message and periodically send AttitudeActual, Accels and PositionActual. Then I grabbed the file off the SDCard and ran it through the matlab LogConvert.m (from "make matlab"). Easy peasy, plot of the attitude of the board on my desk:

One of the nice things about this design is it is super flexible. For example, you could just have this attached to the line going to your telemetry system and have it redundantly log all the telemetry data in case you drop out (or don't always have it running) or you could even write a custom data format that is highly efficient to collect as much data as possible at a fixed rate. You can find the branch I'm using here. Hopefully at some point I'll tie it into our logging metadata so you can easily select which objects update at what rate. For the time being I'm just hardcoding it to a fixed rate for preselected objects.

For now I'll probably just make another module (don't want to break UAVORelay) that just allows streaming a few of the major data objects at a fixed rate.

If anyone wants to play with this, the code I used it located here.

Return to home and landing

So at the last Houston meetup at that Haymerchant I was talking with Oso Grande and he described the Naza failsafe sequence. Essentially hover in PH mode for a few seconds, then fly home, hover over home and finally land. It seemed like a good idea, but our current Vtol Path Follower didn't support any multi-step sequences like that. A day or two of thinking about it and a pretty clean implementation crystalized in my head.

Essentially for any "goal" the path follower might have, which range from simple ones like "hover here indefinitely" to the one described above, there would be an FSM that is switched in, which allows arbitrary levels of complexity. The basic description can be seen on GitHub.

I went ahead and implemented it this week and surprisingly it worked in simulation right away, so I got ambitious and went ahead and tested it at our Houston meetup this weekend. The results were pretty good. Also it was flown on Freedom, which has the benefit of providing high quality logs for offline analysis. I had one flight where it wasn't performing terribly well because I forgot to calibrate the mags (no fly away but some serious toiletbowling). However you can decide for yourself on the other flights:

And here is an image of the position data as it returned:

The location control was pretty good and the path home nice and straight. The altitude control wasn't great. It was meant to hold a minimum altitude of 15 m above home, which it tried but gradually dropped. However the altitude drop came from two issues:
1. the accels were biased so the estimate of vertical velocity was a bit off so when it was still it though it was already going up 0.5 m/s
2. the max vertical velocity was set at 1 m/s so it spend most of the time with this request pegged and not making much progress

First the good points. You can see there is less than 1-2 meters of error in the PH segments. However, you can also see how the altitude slowly droops down in the upper right panel, and the velocity is basically thinking it is going up (down at -1) 1 m/s squared so it thinks everything is peachy. After recalibrating the z-accel, this is the result:

Luckily we added a button the other week to facilitate this.

I also had the opportunity to see Naza PH and RTH, and I have to say I was impressed. It holds well and is nice and stable. It definitely has me questioning whether our dual loop controller for PH is the right design, as opposed to a directly PID control on position. We used to have an implementation of the later, so I'll probably try and resuscitate it and play this week. Also our altitude controller in general needs some love.

So a suggested change is that, like Naza, it also ascends in place when it is going to, before returning home. Also making the time it hovers in place programmable before RTH is important. Then add a simple geo fence and we should be able to get some users testing this. If we can make it robust it might actually be an option for failsafe in not too long!

TauLabs gets MultiWii Horizon mode

Some people were asking about Tau Labs getting support for a mode like MutiWii horizon. Credit goes to them for describing it and testing, as well as the MultiWii guys for the idea. In this mode as you move the stick it smoothly transitions from an attitude mode controller (in the middle region) to a rate controller (in the outer region). This means you can have the benefits of a pretty tightly locked self leveling mode with an aggressive rate mode.

Anyway, I whipped it up this morning and managed to get some tests in this evening. It's not identical to MultiWii but it's pretty similar. It felt really fun to fly and was neat having the best of both worlds. It was also fairly natural to fly.



This tricopter wasn't really tuned up so the rates are a bit slow and my loops had to be quite high. The leveling performance was good as always and it felt good in attitude mode regions of the stick range. The rate mode also felt good aside from not being fast enough.

I also tested it on a plane and had no issues there. Nice stabilization in the center and was able to do rolls and flips fine (although again it did not have a fast enough rate so they were fairly slow rolls). Hopefully you guys enjoy the few bloopers at the end. It's been a while since I did any flips.

(Updated) Here it is on Aggressor with Sparky doing some pretty nice tight flips

Horizon Mode - Flipping from James Cotton on Vimeo.

As an aside - we recently added an exponential to Tau Labs rate mode. This allows you to set a really high maximum rate (e.g. 500 or 600 deg/s if you set your gyro max rate high enough) while keeping good control in the middle region. Using this also works in horizon mode, so you can keep all your settings that you tuned independently in attitude and rate mode and it will just switch between them.

If you want to test it here is a version for OSX and here is a version for windows.  BTW there was a problem with the GCS on OSX 10.9 but that is fixed now. (Warning, the firmware in this doesn't flip properly and will do a split-S maneuver automatically. Use this updated firmware)

• Sparky
• CopterControl
• Quanton

If you want to test it here is a version for OSX and here is a version for windows.

Controlling a quad with a wave of your hand

So I just recently purchased a Leap Controller.  For those of you not familiar with it, this is an amazing device that can track your fingers and hands extremely precisely.  So of course, the first thing I wanted to do was use it to control a quadcopter!

The API is actually fairly straightforward to interface to C++ and you can access it here.  I wrote a plugin for Tau Labs GCS which would access the hand position and the roll-pitch-yaw value of the palm of hand. Right now I'm not doing anything with the position (other than checking a hand is there) and the RPY value is packaged into a LeapControl UAVO and relayed via the telemetry link to the FlightController.

On the flight controller side, I extended the ManualControl module to support another flight mode position (LeapControl). When the flight mode switch is in that position, then the LeapControl UAVO is used to set the desired attitude (yaw is used to set the turning rate, not absolute heading) and the throttle from the transmitter is used.  If a hand is missing it turns off the motors (a nice safety feature you'll see in the video).

The code changes can be found here although check the commit history since it requires some hardcoded paths to the Leap libraries.

The flight platform was my IconicX, which is beautifully light, has good flight times and only uses 8 inch props.  All really good things for indoor testing of a brand new and probably terribly advised control scheme.  It used bluetooth for telemetry to get the LeapControl information from GCS (more on that later).

The flight controller is the Sparky board that I designed for Tau Labs:

But of course, you really just want to see the video, so without further ado:

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

Conclusions

It's definitely flyable. Especially after a few minutes practice (I'd recommend a larger space).  A few things I need to change or would like to address in the future

• Increase the yaw sensitivity.  Right now the highest value is only a few degrees per second. However, it's a bit tricky because the Leap seems to zero yaw at the something random (related to what it first saw) and I'm finding "zero" seems a bit arbitrary.  Probably a dead band and some exponential on the GCS side would go a long way.
• Lag. This is the biggest blocker I think.  This quad is well tuned and reacts _really_ fast and so I can tell the limitations from hand controller. Of course the Leap itself has some latency, but I think something is going on in terms of the bluetooth serial port backing up data.  When I set the update rate too high there is a very clear backlog that occurs. Using a PipX might help since we have a bit more control about the lower level buffers.  Probably the serial code needs a goo review and for things like this we need a low latency protocol for sending the same object. I did something similar for the Tau Labs android app I wrote which made a huge difference for telemetry control (also bluetooth).
• Use hand position - I feel like tracking the position could allow a stronger communication of "oh shit" when getting near something.  Possibly if the hand moves rapidly then it applies a short lived roll signal to the quad to pull it away from the object but avoid the pilot induced oscillations from the latency.  And of course the Z position can also be used for ...
• Integrate this with the sonar based altitude hold (after some improvement) I described last week so that the hand height directly indicated the altitude.  That could create a really cool control scheme.
• Using overo on Freedom for optical flow then the X and Y position can actually indicate a rate to move at.  That would be really awesome.
• Try this outdoors.  I'm not sure how well the Leap will work there.

But it was fun.  I definitely won't give up my transmitter this week though.  If you are interested in this or our other developments, make sure to drop by Tau Labs and say hi.

Tau Labs Sonar altitude hold

So following up on Stac and scenkov's really nice work I added support for SMD-IO-UART sonar module which I had laying around and connected it to Sparky. This one is a bit different than the HCSR04 which encodes the range in the duration of a positive digital pulse. Instead, it had a negative pulse with a duration of 150µs when it finds an obstacle and the latency from the trigger to the pulse indicates the distance.  For more details check this out.

I mounted the module on the bottom of my silver hornet, which is a bit too big for the landing gear but works for now:

With the module working, I hacked up some code to pass that data into the altitude hold EKF.  I played around with the tuning a bit and can't get to the point where I'm super happy with it.  The next step will be trying a different module (e.g. I have an XL-MaxSonar sitting on my desk right now which people on IRC say good things about).  However it does work.

Sonar altitude hold from James Cotton on Vimeo.

One thing that is a problem with the current implementation is that if you go too high and the sonar goes out of range, then the EKF no longer has anything to correct the altitude. This means it goes into a straight prediction mode based on integrating the accels but depending on the direction of the bias this can make it think it is going down and correct by going up.

I suppose an alternative might be to keep correcting with the previous altitude (or max for that sonar) which should in any case be higher than what you engaged it at and cause it to come back down. A better approach would be to fill in that missing information with the baro.

If anyone wants to play with it, the code is currently at my Tau Labs github fork.

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