Gemini (powered by Tau Labs) tear down and review

One of the more exciting added in the latest Tau Labs release is support for the Colibri flight controller. This is the flight controller that is used in the Gemini hexcopter (designed in collaboration with an awesome designer William Thielicke of shrediquette fame). I've been lucky enough to have access to a Gemini for several weeks now for development and wanted to write up my thoughts.

Here is a video of me flying which also shows you the ground station and some chase shots. It uses some early PID settings and is a bit wobbly.

And here is a video from TBS that is better tuned and flies more smoothly:

The short version is impressive. What impresses me most is the level of system integration involved. This is what you get when you design the whole system for a purpose, rather than taking parts and figuring out how to put them together. In a way, this is the type of achievement we had hoped people would do from day one with CopterControl - creating something that is elegant and easy to fly.

Unboxing

Ok, this is the first time I have had a real "unboxing" experience with a multirotor. Probably because I never get prebuilt systems, but this was great. It comes in a slick traveling case, nicely embossed with a TBS logo and a hexcopter symbol.

Inside I found Gemini, spare props and the FPV antenna. The whole system was already wired up and ready to go (except for the receiver). I'm assuming the production versions will come enclosed in the canopy, but mine did not have one.

Frame

So here you see it! A very compact elegant setup.

And a side view shows the tilted motors. This is really well done with the frame material actually conformed to hold the motors at the right angle. I dread to think the cost of setting up prototypes of this. Despite the shaping, the frame feels incredibly strong.

The motors are tiny little T-Motors. Basically the size of my thumb. What is really nice is that the ESC wiring is integrated into the frame. This means no confusing which lead is which and no ugly wires to try and hide. You can also see the little OrangeRX satellite receiver I'm using in this shot. Also, the mount for the mobius camera is evident and hanging from the frame by four vibration damping mounts (with the tie wrap I use to secure it).

I also really like the elastic strap for mounting the battery. In the early photo you can see there is a little plastic stick through the ends of it on the top to secure it, rather than wrapping it around everything. Attention to detail is obvious in this design.

The arms also come with vibration dampeners between the frame and the motor mount. This two stage vibration isolation (arm and then at camera) works really well for larger frames and I think contributes to the video quality I'm getting. Plus higher RPM motors just produce much less jello.

You can also see that the motors attach to the frame wiring via JST connectors. Again, a nice detail focus was keeping the pinout the same for each motor and handling the lead swapping in the PCB layout. This makes sure no one can get confused. I will comment that the final version uses the opposite motor direction as our default orientation, so if you are configuring from scratch one must remember to reverse the motor directions in software. However, most people will use the configuration file provided by TBS and not need to deal with this.

Flight Controller and electronics

Colibri is a really small flight controller designed by Team Black Sheet that takes the Quanton design (by lilvinz of Quantec) and shrinks it down. TBS did the right thing from day 1 here - they approached Lilvinz and asked to make a derivative of his CC-BY-SA-NC design and he acquiesced. This is open source working the right way!

As you can see the board uses microtouch connectors. It is a really small design, but still packs in the full suite of barometer, magnetometer, 3-axis accel and 3-axis gyro and flash. The breakout headers give access to all the Quanton IO so in principle it supports 8 channels in and out, as well as a number of serial and I2C ports. Here it is compared to a quarter. Sorry non-Americans, this might not mean much to you.

The approach of a high-density powerful flight controller is not ideal for end users making their own frames, but is absolutely perfect for this custom, focused, miniatured design that doesn't want to sacrifice features. Kudos to TBS for the work required to miniature this design so much.

This board then sits on an IO board that breaks out the wire from Colibri for use on Gemini. This IO board has the 6 bulletproof ESCs, an receiver port breakout (supports PWM, PPM, DSM2/X, SBus) and a second serial port which can be used for telemetry or GPS. You can see the wire going to my OrangeRX satellite in the lower right.

Here is a closer front view of the electronics. You can see the TBS UNIFY 5.8 GHz 200mW transmitter connected to the TBS Core and the camera. It is hard to appreciate in this photo, but all of this is mounted as a plastic sub assembly to hold and mount the camera, support the vibration damping to the mobius, and provide the vertical support for the VTX. Again, a nice custom solution that got everything needed into a compact space.

And here are the electronics viewed from the back. This gives you another nice view of the 6 ESCs in parallel. The board mount approach is really space efficient and again contributes nicely to the compactness of the design. 

And lifting up Colibri reveals some nice foam used to protect the barometer from turbulence and get a clean measurement. The flight controller makes a very nice firm fit on these headers, despite the number of times I've had it on and off.

And finally the whole IO board can be lifted up to show the ESC connections from the bottom. The connections to the main frame is done through a series of standard 100-mil spaced headers. This routes the cables from the ESCs into the main frame wiring, as well as providing power to the IO breakout board.

You can see in this photos the soldered connections to the ESCs. It will be interesting to see how easy that is to remove and replace. The board mounts protrude 1 or 2 millimeters past the board which might make it easier to break the connection. However, it might be that a bit of flux and braid are required to really free them up. Either way, it wouldn't be worth the increased height and weight to have a connector for each ESC.

Finally the integrated wiring into the frame mentioned above is really nice. I'm not entirely sure the process that went into making a PCB laminate and then applying it to the frame with the twisted motors. The motor wires do run on straight segments of the frame, so perhaps that helped. Anyway, I don't envy the cloners who are trying to rush an mimic this process.

Crash resistance

Well I've only flown this for an hour or two. However, I have already done a good job of crashing it. One thing I'm less used to (flying mostly quads) is that it does a great job of crashing into things. I flew into a tree while in altitude hold mode and the flight controller totally recovered and had me floating in clear sky. 

I tried teaching a friend to fly it under a tree and only lost a prop.

I flew into a tree about 10 feet up and just had to pick it up and replace a prop.

Finally, I flew it at full throttle (probably 35+mph) into the bottom side of a bridge. Completely misjudged the height by a foot. I really expected to be picking up pieces, but in the end nothing important was damaged. The bolts holding the front two motors sheared. The frame was entirely intact. All electronics are ESC traces are good. Even the motor connectors on the frame are still attached. The plastic assembly that holds the flight camera either needs some glue or replacing. Overally, I was shocked by how minimal the damage was.

Summary

Ultimately, I am very impressed with this frame. There are a lot of fairly novel (if not entirely unique) concepts here that aren't in many frames. The integrated wiring with the frame as a PDB is pretty uncommon in anything this size (obviously things like Crazyflie have done it) and makes the lines really slick looking, not to mention aerodynamic. The twisted motors I first saw in William Thielicke's shreddiquette designs and they have done a nice job of taking that into a custom warped frame. 

The level of integration with the tiny Colibri flight controller, IO board that with integrated ESC connections and then the breakout into the frame is what really impresses me. This was all made custom for Gemini and just makes the whole thing light, compact, and probably quite robust to crashing. I also haven't see this approach to integration in any frame running open source software (maybe some proprietary frames are similar?).

A big congratulations to Team Black Sheep for making an awesome product and I'm glad they wanted to use Tau Labs to really get the most out of it. I'm sure this will be extremely popular with pilots and hopefully as a trickle down effect we will get some people active in the TL community.

Reflecting on four years of development

As I was digging through my bins of parts to find an original analog CopterControl, I was struck by how much work and how many things we have designed with both Tau Labs and originally with OpenPilot over the last 5 years. I thought I'd take a wander down memory lane and look at some of the boards (released and unreleased).

MainBoard, AHRS, CopterControl, CC3D, Revolution, RevoMini, Freedom, Sparky, Sparky2, SparkyBGC, TauLink, OSD

Mainboard and AHRS (2010)

And a closeup of the INS (slightly different revision - BMP085 and ports for GPS moved to AHRS).

These boards were designed by Angus Peart, one of the co-founders of OpenPilot and also a founder of the Omniloco foundation which is the foundation behind TauLabs.  They were painstakingly hand soldered by David Ankers, the other co-founder of OpenPilot. The F1 processors at the time were not (and still aren't) powerful enough to run a full suite of algorithms for navigation, so the decision was made to have one board (AHRS) acquire all the sensor data and fuse it (run the INS) and another (Mainboard) to handle all the control code and input/output. The sensors were analog 

The fusion algorithm is one we still use, an INSGPS algorithm written by Dale Schinstock. A lot of my original work on the OpenPilot project was originally getting this fusion algorithm working with our sensors and behaving well, as well as the original control code to stay in the air.
Here is the very first stabilized flight using the OpenPilot software.

 

And the first flight of a quadcopter with our hardware. Unfortunately, I had no idea how to fly one so it simply floated into a tree...

Then there was the aborted attempt to get more power from the INS. This used the F2 series of CPUs which had a bit more power than the F1. You can see little bridges of wire where we didn't quite account for the CPU differences and I had to hack it up to get it running. Where there is a will, there is a way. Ultimately this was one of many boards that were made but didn't become a viable product. I think we also did a number of sensor trials on these boards because I have some lying around with various sensors like BMA180. Lots of work writing and testing those drivers and getting the data to ultimately not use them. Still, gotta try it to know which is best.

The AHRS+Mainboard was ultimately a pretty powerful setup, although programming and syncing data between the two boards was a real PITA. PT_Dreamer did an impressive job of writing the bootloader so it would upgrade both boards at the same time. We even managed to get some demonstrations of position hold working on this hardware, around three years ago now at our developer retreat in Portugal (oh fun times: https://vimeo.com/23865574.

CopterControl (early 2011)

This board was designed by David with help from Pip (I think) and took the AHRS designed by Angus and added the input output ports to it. The processing / memory limitations of the F1 were still there, but this board was meant to be a stripped down user-oriented version of the original hardware capable of stabilizing a quad or plane. It used the same analog invensense sensors as the AHRS. These were fairly good sensors in terms of noise performance, but their drift (and especially zero bias at powerup) were quite problematic. It had a 3-axis gyro and 3-axis accelerometer.

Of course, here is the mandatory first flight video:

Because of the limited processing power of CC3D, the INS algorithm could not run without negatively affecting the flight performance. I designed a complementary filter implementation (based on Mahoney's papers) that was quite efficient and allowed us to process data at several hundred Hz. This really improved the flight performance, and having everything on one controller really improved the latency.

In retrospect, I can't decide if this was a good or bad direction for the project. In a lot of ways, it created a several year distraction from a lot of autonomous functionality. At the time we were probably comparable with Arducopter in terms of PH and navigation, but ended up quite a distance behind.

This little mag/pressure sensor was an attempt to bring more functionality to CopterControl (and CC3D) but ultimately there just wasn't enough processing power or memory to do it.

On the flip side, the focus on usability led to very nice improvements in the ground side of things. It (and CC3D) also created a lot of positive publicity as well as a revenue stream for the project.

The first several hundred of these were manufactured by CheBuzz, elafargue and Dankers - so a big thanks to them for taking that risk and getting OP on the map.

PipXtreme modems (2011)

These modems were designed by Pip, a really talented electrical engineer who was in the project and helped out a ton with lots of designs. They were much more convenient to bind and configure than my experience with other modems and were quite useful for debugging and testing. They also allowed us to build in awareness of UAVTalk into the modem.

Here is Edouard Lafargue testing his out (he also made a nice case for the modem): https://vimeo.com/17200010

CC3D

This was an update to the sensors for CopterControl. Above you can see two versions - one using L3GD20 gyros and BMA180 and the other using the MPU6000. That was interesting because I got to learn about Allan variance testing to compare the sensor drifts. Ultimately we went with the MPU6000.

One thing that really helped jump start this board was sending out samples to some pretty good pilots in the community, as well as a few developers. Here are 15 boards I soldered by hand:

Not a lot of fun to make, but everyone was really happy with how it flew. I believe one of these went to juz, and we all know how worthwhile those videos ended up being.

This board really sold well and it was hard to keep up with demand. In fact the first few batches were quite terrifying. The yields were extremely low, with sensors frequently failing. Over the batches of the CopterControl the yield had been steadily decreasing but never quite so bad (which also confused us since the first batch from CheBuzz was >95%). It turned out that the assembly house was using ultrasonic cleaning which the MEMS sensors do not like. David had to heroically replace hundreds of MPU6000 by hand, which was weeks of work and cost quite a bit as Invensense would not replace them all.

Again, in retrospect some decisions could have been done differently. One of the biggest criticisms of CC3D was that it was always unavailable. Once the design was released CC-BY-SA (due to pressure from the developers that things were meant to be open source and the design was years old), tons of manufacturers started making it. Lots of them contributed back to OP and thus provided a risk-free and stress-free revenue stream instead. Trying to corner all the profit ultimately created a lot of stress (and thus pressure on the developers and a lot of tension in the project).

ESCs (end of 2011)

Who doesn't want an ESC as big as their flight controller? Believe it or not, I actually flew with those. Back then, there was no simonK firmware and the speed of ESCs was the biggest limitation in flight performance. This was confirmed when I saw our software flying on a mikrokopter with their ESCs and it was just totally locked in. Unfortunately, my experience with those I2C ESCs was a lot of bus lockups and crashes (I would not recommend I2C as a protocol for an ESC to my worst enemy).

Anyway, I wanted to play with ESCs so whipped up that huge board you see above. That was a lot of fun. After some shrinking:

I had a board that worked pretty decently. However at the same time dirty cheap flashed ESCs became  available so these stopped being useful. I still fly them on a number of my boards though. Another pile of work that was wasted. I wrote a really nice system for switching the PWM lines into an emulated bidirectional USART and digitally configuring them via the GCS and the FC. You could even update the code via the PWM line. *sigh*.

Thanks to MattL for helping with the final shrinking of the design!

See more here: http://buildandcrash.blogspot.com/2011/11/esc-development.html

Revolution (end of 2011)

This board was designed by David to get development back on track for more advanced functionality. It had gyros, accels, mag, and baro so was capable of full navigation. It also upgraded to an F4 processor which had more than enough power to handle all these tasks. It was also nice for having tons of connectivity. Unfortunately I don't have any first flight videos, because for some reason we were trying to keep things quiet. Here is a video of the first altitude hold, though.

Of course, this board also had a number of revisions to try out various sensor combinations. Lots of hand soldering for me *sigh*. If you look closely below you can even see some nice blue wires and bent pins to work around various bugs in the early versions.

I'm calling this version the "nope". I got this board in the mail, took one look, and said no way am I populating that, because no one will ever want to fly it. Very big.

One thing that was super useful was designing a board that could carry an Overo gumstix connected to Revolution via SPI. I'm pretty sure I used this board to capture the data in this video (https://vimeo.com/42015859).

OSD

This board was motivated by Sambas who initially breadboarded some driver circuitry. I feel badly that I cannot remember the name of the guy that did the design and layout. The original design didn't work great for black and white so you can see the work I did jury-rigging up a different driving circuit. This worked reasonably (although still had issues drawing to the edges of the screen). Ultimately, this stalled due to lack of time.

This is where the strength of open source is great, though. Two people with Tau Labs have designed new flight controllers that have integrated OSD using this code. 

Draco

and Brain

RevoMini (2012)

RevoMini (which became known as Revo) was a stripped down (in terms of connectivity) version of Revolution with an integrated modem designed by David. It was good and bad, too. After spending almost a year working on Revolution it created another serious delay in progress on the flight front to focus on basic hardware bringup. In addition it went a bit too far (IMO) dropping connectivity since I use a digital receiver that left one port which isn't enough for GPS and an auxillary mag, or an OSD, etc. Another one that wasn't fun to solder, especially with all the EMI filters on every port.

Of course, the obligatory first flight video:

I ended up being quite unhappy with the flight performance of Revo (I could never get it tuned as nicely as CC3D). There was ultimately a question of whether the problem was hardware or software (although the same software was used on full Revolution, so that wasn't really a question in my opinion). There was also an issue that Revo wasn't looking like open source hardware and there were a lot of political problems within OP (such as doing a preorder for a board that didn't fly well).

Ultimately this and a number of other issues led to the majority of the developers being told their opinions don't matter and leaving OpenPilot to create Tau Labs.

It also led to me designing...

Freedom (end of 2012)

This board has an MPU6000, HMC5883, RFM22B radio, nice switching regulator, and F4 processor, not to mention a Gumstix Overo computer running linux on the back. The computer and FC stay in sync with a high speed serial bus. I have mostly used it for collecting high resolution sensor logs from flight for offline analysis and algorithm development. This is extremely useful, because you can replay the sensor data from the same flight through numerous algorithms or the same algorithm with different parameters and compare the performance.

It also resolved the question of tuning since it tunes up and flies very well and didn't have the same sensor noise as RevoMini.

Ultimately most end users don't want a linux computer on their flight controller so it didn't make much sense to make lots of these. There are still some issues with not using the ports optimally, and I'm always meaning to clean it up, update the sensors to more modern ones, and make a new revision. There is also something called Aerocore from Gumstix that is similar and I'd like to port the linux code to.It's always a matter of not enough time! I love it though and it is great for development, still. 

Sparky (2013)

At this point, I knew what I wanted in a flight controller. Reasonable expandability and IO, capable of altitude hold, position hold and return to home, cheap and easy to assemble, and open source. Since there wasn't something like that, I designed one.

I'm quite proud of Sparky. It flies extremely well. It switched to the MPU9150 which integrates the mag into the accels and gyros and keeps the sensors all together. It uses an MS5611 pressure sensor, which is quite nice. It has enough resources to be quite capable while keeping it fairly affordable (the Chinese make it for < 40$), all the components are on the top so it is not too bad for assembling yourself (the MPU9150 is a bit nasty). I find the receiver port extremely useful compared to tying up one of the serial ports for my Spektrum receivers.

I get some grief about the shape ;-). It was designed for my tastes, so that is fine. Typically I use a three point mounting and have never had an issue. I figured if I don't need to use board space, why keep it?  I did make an earlier version that kept the thing as small as I could get it (without using the back). This was a pain to mount since none of my frames had that spacing. Ultimately adding the tab made it compatible with other frames while able to have the tab cut off and fit in smaller spaces (since the back is flat you can mount it by taping).

Here is version 1.1 which updated a few of the passive on the sensors to be better in spec and also switched to a three pin header for the receiver so standard cables can be used. I still flip-flop on the 3 versus 4 pin distinction.

And they same imitation is the best form of flattery, so here are some boards made by Dragon Circuits. The design is CC-BY-SA so that is totally legal and ethical. I do not receive anything from them for the boards, but that is fine. They make it available more cheaply to more people and that is good.

Sparky Brushless Gimbal Controller

At the same time as Sparky, I also designed a "shield" that could be soldered to the back and converted the 6 PWM outputs to 2 brushless gimbal outputs.

This was a pretty different project and I won't write it up too much here.  I was happy with the performance.

Having the ability to talk (via CAN) between the BGC and FC is quite useful and can allow things like point of interest tracking:

The shield made it easy for me to test this out without designing a new board. However, ultimately having the whole FC+driver on the gimbal isn't the optimal configuration so I redesigned it with a more 'traditional' configuration.

TauLink (2014)

I wanted an radio link I could use to talk to Freedom and Sparky2 that stayed code compatible with the original PipX. This is the result, it's fairly straightforward - just a few serial ports and the RFM22b modem on the bottom.

Since I mostly use this on the ground side plugged into either my laptop or an OTG adapter for my phone, I realized the form of a thumb drive is actually a bit more effective for my purposes.

f It can also be used on the flight side with Sparky, in which case I'd probably leave the USB connector off ;-).

Sparky 2 (2014)

Finally Sparky2. This is designed more with navigation and advanced features compared to Sparky1. It switches to an MPU9250 which has a tiny bit worse noise performance (although so far below the motor noise it is irrelevant) but has the benefit of being an SPI sensor and not taking up as much CPU usage. It adds an RFM22b module for telemetry which is key for serious navigation (and honestly advised for even PH). It also adds an additional auxillary I2C port for communicating with a mag, which is useful for having more accurate reading. It adds flash for storing short logs or storing waypoints and picoC code. There is a DAC outputs for an audio downlink with FPV, although I haven't had the chance to play with that yet.

Summary

That is a lot of hardware. Tons of people were involved in all aspects - hardware design, soldering prototypes, writing code and testing. Thanks to everyone that has been involved and made it a very fun and interesting four years. I won't even pretend this is a complete list but special thanks to PT Dreamer, Edouard Lafargue, stac, pip, kubrak, CheBuzz, Vasillis, Corvus, Bwebbn, Angus, and David for their tireless work and contributes to keep this going in various forms.

This post also focused heavily on hardware that I had a hand in designing or getting flying. In fact I think all the flight controllers listed above were first flown by me ;-). Open Source is very powerful in the fact the Tau Labs system keeps growing and supporting tons of other targets not mentioned here. This includes:

• Quanton
• FlyingF3
• FlyingF4
• Gemini (Colibri flight controller)
• Brain
• Draco

and probably others I don't even know about yet!