ElectroHub - Which GPS Flight Controller? (Spider Config) Flip 1.5 or other?

[Quad]

In looking at recommendations they seem to point to Flip 1.5 for a flight controller. However I would like GPS for the return to home feature and perhaps some other features. Is the Flip Mega 3.5 with GPS a decent choice?

http://witespyquad.gostorego.com/flight-controllers/flip-mega-3-5.html

Other thoughts?


More details:

This is for an ElectroHub in spider configuration.
Current plan is to use a FrSky receiver with a Turnigy 9x transmitter with FrSky module... (Yet to purchase)

 

[jhitesma]

The flip mega is new so I doubt anyone has direct experience with it just yet. But...it's based on the well proven arduino mega platform and the megawii just crammed into a much smaller package and without a magnetic sensor since it's designed to have the mag sensor on the GPS.

The MW Mega series is IMHO the best for GPS if you're looking for low cost and a simple position hold. I wouldn't count on it for RTH. And even position hold isn't great without a lot of tuning. I would take it over any other MW option or a Naze32 (or compatible) if I wanted GPS and wanted to stick with MW. But really on these platforms GPS is mostly only useful for adding more info to an OSD when flying LOS and isn't very useful for pos hold or RTH.

If you really want RTH the best bang for the buck is probably the Sparky board with Tau Labs, followed by APM/Pixhawk then Naza but by then you're talking considerably more money.

What's nice about the MW Megas is you get more memory and serial ports than any other MW based setup including the Naze32. That makes it easier to do things like waypoint navigation (though firmware for that is still in beta) and makes it possible to connect GPS and OSD at the same time without any compromises (like having to disconnect the OSD to use the USB port like on Naze.)

And I assume you mean FrSky not SkyFry?

BTW - none of these will use RTH as a failsafe if that's what you're looking for.

 

[joshuabardwell]

I'm not up on the latest and greatest, but my impression has always been that if you want proper GPS based flight, with loiter and RTH and so forth, that the most obvious choice was APM. It's not the cheapest, but my impression is that it's incredibly mature compared to most other offerings. Of course if you have money to burn, get DJI Naza, but who can afford that?

 

[Quad]

The flip mega is new so I doubt anyone has direct experience with it just yet. But...it's based on the well proven arduino mega platform and the megawii just crammed into a much smaller package and without a magnetic sensor since it's designed to have the mag sensor on the GPS.

The MW Mega series is IMHO the best for GPS if you're looking for low cost and a simple position hold. I wouldn't count on it for RTH. And even position hold isn't great without a lot of tuning. I would take it over any other MW option or a Naze32 (or compatible) if I wanted GPS and wanted to stick with MW. But really on these platforms GPS is mostly only useful for adding more info to an OSD when flying LOS and isn't very useful for pos hold or RTH.

If you really want RTH the best bang for the buck is probably the Sparky board with Tau Labs, followed by APM/Pixhawk then Naza but by then you're talking considerably more money.

What's nice about the MW Megas is you get more memory and serial ports than any other MW based setup including the Naze32. That makes it easier to do things like waypoint navigation (though firmware for that is still in beta) and makes it possible to connect GPS and OSD at the same time without any compromises (like having to disconnect the OSD to use the USB port like on Naze.)

And I assume you mean FrSky not SkyFry?

BTW - none of these will use RTH as a failsafe if that's what you're looking for.

Thank You! I did mean FrSky ( I have edited the original post). The Sparky Board looks promising. I thought I saw and APM 2.6 solution with GPS on RTFQ for $76.00 or so but I can no longer find it. does that sound like too low of a price?

 

[jhitesma]

RTFQ does have their own version of APM both 2.5 and 2.6:

2.5.2: http://witespyquad.gostorego.com/flight-controllers/readytoflyer-2-5-287.html

2.6: http://witespyquad.gostorego.com/flight-controllers/readytoflyer-2-6.html

The big difference is the 2.6 has the mag moved to the GPS instead of on the main board to help eliminate interference.

You'll have to go into the options and add the GPS and such which is why the initial listing price is lower than what you were probably looking for.

Honestly the official APM hardware is IMHO overpriced. It's basically an arduino mega with a few sensors integrated. Not very different from a MW Mega which is also based on an Arduino Mega. They both use the same processor they just set things up differently. It's one of the big reasons I've never been a fan of APM.

However it sounds like development on APM is more or less dying off now as they've maxed out the memory on the chip and are moving to the PixHawk for future development.

Personally I'm just not a fan of the community around APM. But that's just me, plenty of people love it. I've just found the MW and Tau communities far more pleasurable to take part in.

The hardware from RTFQ is fairly good - but he has some questionable business practices that make it hard for me to recommend doing business with him. From poor communication to slow shipping to cloning hardware that isn't released under open licenses (The Quanton for example) and just generally not playing very nice with the core developers of those who do release things under open licenses. I ordered from him once and was happy with the quality of the hardware - but one small item was missing from my order and he failed to respond to two attempts to contact him by e-mail about it which has left me in no big hurry to order from him again.

I haven't tried APM personally but most of the reports I've seen sound like it's great if you want the quad to do most of the flying for you, but not so great if you want to be able to fly it aggressively in a manual or slightly assisted mode. MW (And Naze) is great if you want to fly manually or slightly assisted - but not if you want it to any level of autonomous flight.

Honestly I'm absolutely loving Tau. I haven't used an official Tau board yet but I rolled my own using an STM32F4 discovery development board and adding my own sensors. I did run into a few minor issues and it did require some hacking of the code - but the Tau team was very helpful and responsive even though I was working with "unsupported" hardware. Tau's software has blown me away. Their manual modes feel just as good to me as MW/Naze (and they recently added a direct clone of the MW/Naze Rate mode to compliment their own manual mode but I haven't had a chance to try it just yet), and their assisted modes work WAY better than MW/Naze. I'm using the same exact sensors I used on my MW Mega and with no tuning the Tau board does altitude and position hold better than I ever got MW/Naze to with extensive tuning. I don't even have any foam over my baro sensor yet and it will hold altitude within a foot or two using my own BMP085 sensor which is way less sensitive than the one used on the Naze. The autotune on Tau is also very impressive and blew me away with how easy it was to use and how good of a tune it gave me on my knuckle quad.

The big issue with Tau is hardware availability. The Sparky is a F3 based board with some limitations if you're wanting to do autonomous flight. It's still way better than the Naze but not as good as the Quanton or the not yet available Sparky2. The Quanton is a great board based on the STM32F4 and the official Tau reference platform - but it's a big bigger than the "standard" 35mm square of most other small FC's and it's only available from Germany (the RTFQ version is an unauthorized clone produced in violation of the license the Quanton design was released under.)

 

[C0d3M0nk3y]

or the not yet available Sparky2.

Any idea on the Sparky2 release date?

 

[Quad]

RTFQ does have their own version of APM both 2.5 and 2.6:

2.5.2: http://witespyquad.gostorego.com/flight-controllers/readytoflyer-2-5-287.html

2.6: http://witespyquad.gostorego.com/flight-controllers/readytoflyer-2-6.html

The big difference is the 2.6 has the mag moved to the GPS instead of on the main board to help eliminate interference.

You'll have to go into the options and add the GPS and such which is why the initial listing price is lower than what you were probably looking for.

Honestly the official APM hardware is IMHO overpriced. It's basically an arduino mega with a few sensors integrated. Not very different from a MW Mega which is also based on an Arduino Mega. They both use the same processor they just set things up differently. It's one of the big reasons I've never been a fan of APM.

However it sounds like development on APM is more or less dying off now as they've maxed out the memory on the chip and are moving to the PixHawk for future development.

Personally I'm just not a fan of the community around APM. But that's just me, plenty of people love it. I've just found the MW and Tau communities far more pleasurable to take part in.

The hardware from RTFQ is fairly good - but he has some questionable business practices that make it hard for me to recommend doing business with him. From poor communication to slow shipping to cloning hardware that isn't released under open licenses (The Quanton for example) and just generally not playing very nice with the core developers of those who do release things under open licenses. I ordered from him once and was happy with the quality of the hardware - but one small item was missing from my order and he failed to respond to two attempts to contact him by e-mail about it which has left me in no big hurry to order from him again.

I haven't tried APM personally but most of the reports I've seen sound like it's great if you want the quad to do most of the flying for you, but not so great if you want to be able to fly it aggressively in a manual or slightly assisted mode. MW (And Naze) is great if you want to fly manually or slightly assisted - but not if you want it to any level of autonomous flight.

Honestly I'm absolutely loving Tau. I haven't used an official Tau board yet but I rolled my own using an STM32F4 discovery development board and adding my own sensors. I did run into a few minor issues and it did require some hacking of the code - but the Tau team was very helpful and responsive even though I was working with "unsupported" hardware. Tau's software has blown me away. Their manual modes feel just as good to me as MW/Naze (and they recently added a direct clone of the MW/Naze Rate mode to compliment their own manual mode but I haven't had a chance to try it just yet), and their assisted modes work WAY better than MW/Naze. I'm using the same exact sensors I used on my MW Mega and with no tuning the Tau board does altitude and position hold better than I ever got MW/Naze to with extensive tuning. I don't even have any foam over my baro sensor yet and it will hold altitude within a foot or two using my own BMP085 sensor which is way less sensitive than the one used on the Naze. The autotune on Tau is also very impressive and blew me away with how easy it was to use and how good of a tune it gave me on my knuckle quad.

The big issue with Tau is hardware availability. The Sparky is a F3 based board with some limitations if you're wanting to do autonomous flight. It's still way better than the Naze but not as good as the Quanton or the not yet available Sparky2. The Quanton is a great board based on the STM32F4 and the official Tau reference platform - but it's a big bigger than the "standard" 35mm square of most other small FC's and it's only available from Germany (the RTFQ version is an unauthorized clone produced in violation of the license the Quanton design was released under.)

Thank You!

Is this http://dragoncircuits.com/product-category/flight-controllers/ the F3 based board as well? Can it do a spider configuration? Is there a better place to get it?

To my relief RTFQ did ship my order in three days but I do see some lack of email communications....

Was buying the STM32F4 reference board expensive?

 

[jhitesma]

Any idea on the Sparky2 release date?

According to the developer "When it's ready"

And since it's being done as a hobby and real life has been getting in the way...that basically means well "when it's ready" He has prototypes flying so it should be mostly there. But it could be awhile before he feels it's ready for production.

 

[jhitesma]

Thank You!

Is this http://dragoncircuits.com/product-category/flight-controllers/ the F3 based board as well? Can it do a spider configuration? Is there a better place to get it?

To my relief RTFQ did ship my order in three days but I do see some lack of email communications....

Was buying the STM32F4 reference board expensive?

Yes, that is the F3 based Sparky and probably the best place to get it. Spider should be no problem, just like any other it should fly ok as a normal quad setup but a bit of custom tweaking to the mixer can get it really dialed in (there have been a few posts on here explaining the math for that in regards to MW but the basic theory applies to any FC.)

The F4 Discovery board is only about $15, Then I added my MPU-6050, BMP085 and HMC5883 breakout boards I got off ebay...total cost was around $20-$25 or so. But it's ridiculously big and bulky, tricky to mount (there's no mounting holes and it has 2 40 pin headers) and depending on the sensors you use may require building a custom version of Tau. So it's not a good beginner choice or for anyone else who isn't interested in experimenting with the code Or just kind of crazy like me :black_eyed:

 

[Quad]

Yes, that is the F3 based Sparky and probably the best place to get it. Spider should be no problem, just like any other it should fly ok as a normal quad setup but a bit of custom tweaking to the mixer can get it really dialed in (there have been a few posts on here explaining the math for that in regards to MW but the basic theory applies to any FC.)

The F4 Discovery board is only about $15, Then I added my MPU-6050, BMP085 and HMC5883 breakout boards I got off ebay...total cost was around $20-$25 or so. But it's ridiculously big and bulky, tricky to mount (there's no mounting holes and it has 2 40 pin headers) and depending on the sensors you use may require building a custom version of Tau. So it's not a good beginner choice or for anyone else who isn't interested in experimenting with the code Or just kind of crazy like me :black_eyed:

Thank You! Does it matter which GPS I get for the Sparky? Is a shield on the GPS important? Is it simple to plug in?

 

[jhitesma]

I haven't used the actual sparky - just my homebrewed flyingF4 Tau setup. So I can't say with 100% certainty.

But in general the ublox gps units are the best to go with and are fully supported by Tau (and Naze and MW) The "Shield" usually isn't actually providing any electrical shielding but is just a support board to make the GPS a little easier to mount and sometimes including a mag sensor as well. Getting the mag sensor away from power wires and other sources of interference can be important. Though again the quality of the firmware can make a big difference - on my knuckle the same sensors in the same position on MW showed a lot of apparent interference on the mag making mag assisted heading hold unusable. But with Tau (and everything else setup the same) I'm not seeing that issue and it holds heading wonderfully. That could be the Discovery F4 board just not making as much noise as the Arduino Mega I was using for MW - or it could be a difference in how the raw data from the sensors is interpreted. I'm guessing the later just based on my impressions of Tau's code and how it uses sensors and manages control loops compared to MW.

I think what impresses me most about Tau is how much more analytic the design seems to be. MW feels more like someone implemented a PID loop for control based on reading about it...saw that it flies...and just went with it. Tuning is generally done by feel more than anything and the design of the control loops is a bit of a mess due to trying to optimize things for lower end avr processors like the '328. Tau on the other hand feels more like a proper research project where results are analyzed and used by the developers to improve things based on real world performance rather than gut feel. The Tau developers do a LOT of logging and analysis on those logs to refine their control schemes. Their approach towards auto tune really shows off what this can achieve. Basically they just seem to have a deeper understanding of the underlying algorithms and math and rely more on data than gut feel.

Adding GPS isn't that hard but does take some setup changes in the firmware. Location of the GPS is somewhat important to make sure it gets a good reliable signal. Then it's simply connected to a serial port and in the Tau GCS you tell the firmware which port and at what speed and what protocol the GPS is connected. Once the GPS is talking to the board you can enable the Path Planner and Path Follower modules to enable position hold and RTH. The Sparky can't do waypoint navigation because of memory limitations (at least not at the current time...there is an experimental fork using chibios as the underlaying RTOS which frees up more memory and may make some waypoint navigation possible.)

The big catch of adding GPS to sparky is memory - on the Tau forums a number of people are starting to hit memory limits when they add GPS and find they have to disable other modules to have enough space for the GPS code.

It sounds more complex than it is really though. The hardware is simple - just 4 wires for the GPS Power +/- and TX/RX. Technically you can get by with 3 wires by leaving off the RX wire but then the GPS module has to be pre-configured - wiring up both TX/RX lets the control board do all the setup of the GPS and is really the easiest way to go. Configuring the software isn't that difficult...but does take a bit of reading/research in the Tau Forums/Wiki.

 

[Burly]

The big catch of adding GPS to sparky is memory - on the Tau forums a number of people are starting to hit memory limits when they add GPS and find they have to disable other modules to have enough space for the GPS code.

Hi jhitesma,

I've followed a lot of these control board/firmware discussions, and you seem to be conversant in the Tau offerings.
I'm curious about why Tau chose to employ an RTOS?
How much total program flash memory is available on the chips they are using?
How much of the flash is being consumed by the RTOS footprint?

Thanks.

 

[jhitesma]

I'm not sure exactly why they're using an RTOS - Tau is a fork from OpenPilot which is where the decision was originally made and I'm not a big fan of the OP community so I haven't dug too deep into their archives. I suspect it's since the goals aren't just to create a flight controller for multirotors but rather a comprehensive autopilot system which developed the ability to control multi rotors. MW on the other hand was designed just for flying multis and has had some fixed wing stuff and later navigation grafted on. OP/Tau on the other hand started as a full navigation system for fixed wing and came to embrace rotor craft of various types as well. So the use of a RTOS gives them a bit more abstraction and modularity while controllers like MW and KK were more purpose built for one task. That's purely my speculation though.

The best info I can give about memory usage is what the guy doing the conversion from FreeRTOS to ChibiOS shared here:
https://gist.github.com/lilvinz/6ac8620856c97c90c809

(The flyingF3 is based on a STM32F3 Discovery board while the Quanton uses a STM32F4)

The full discussion about the change of RTOS is here: http://forum.taulabs.org/viewtopic.php?f=17&t=3

 

[Quad]

I haven't used the actual sparky - just my homebrewed flyingF4 Tau setup. So I can't say with 100% certainty.

Thanks for all of the help.
I really want the way point navigation... I am a firmware / device driver developer. If I did make a home brewed system could you share source code in some fashion? Or would it be too much tinkering...

 

[jhitesma]

Thanks for all of the help.
I really want the way point navigation... I am a firmware / device driver developer. If I did make a home brewed system could you share source code in some fashion? Or would it be too much tinkering...

No problem, my fork of Tau is on github:
https://github.com/jhitesma/TauLabs

It's a little out of date...but not badly, the only major thing it's lacking over the latest next builds is the MW rate mode.

The only major differences between my code and the official code is that I configured the FlyingF4 setup to match my particular set of sensors. But if you're a developer you shouldn't have any major issues making the same changes yourself. The official Tau wiki has pretty good instructions on setting up a dev environment: https://github.com/TauLabs/TauLabs/wiki/Development-Developer-Documentation

I haven't tried to use windows to build Tau yet...I did all my dev on Linux. I started with the virtual machine availalbe on the Tau dev docs but it's kind of out of date. Right now I'm not even using a IDE - just a text editor and command line since I haven't had time to get an IDE setup.

If you haven't seen it yet I documented my homebrew Tau build here:
http://forum.flitetest.com/showthread.php?12670-More-crazy-homebrew-FC-experiments

 

[Burly]

jhitesma...thanks for all the links.

 

[Quad]

No problem, my fork of Tau is on github:
https://github.com/jhitesma/TauLabs

It's a little out of date...but not badly, the only major thing it's lacking over the latest next builds is the MW rate mode.

The only major differences between my code and the official code is that I configured the FlyingF4 setup to match my particular set of sensors. But if you're a developer you shouldn't have any major issues making the same changes yourself. The official Tau wiki has pretty good instructions on setting up a dev environment: https://github.com/TauLabs/TauLabs/wiki/Development-Developer-Documentation

I haven't tried to use windows to build Tau yet...I did all my dev on Linux. I started with the virtual machine availalbe on the Tau dev docs but it's kind of out of date. Right now I'm not even using a IDE - just a text editor and command line since I haven't had time to get an IDE setup.

If you haven't seen it yet I documented my homebrew Tau build here:
http://forum.flitetest.com/showthread.php?12670-More-crazy-homebrew-FC-experiments

Thank You! Very helpful!

 

[Quad]

No problem, my fork of Tau is on github:
https://github.com/jhitesma/TauLabs

The only major differences between my code and the official code is that I configured the FlyingF4 setup to match my particular set of sensors.

[/url]

Should I just get the sensors that match the original code or better to go with your sensors?

 

[jhitesma]

I'd say go with what the original code is setup for. The only reason I used what I had was it was what I was already using with my MW setup and had on hand/installed in the airframe.

The only real difference is I'm using a BMP085 instead of a MS5611 as my baro sensor. And the BMP085 is now discontinued and getting hard to find so there's not much point in going with it. The MS5611 is more expensive but much more accurate. A BMP180 would be a current low cost choice that's higher accuracy than the 085 but not quite as high as the MS5611. But I don't see a driver for the BMP180 in the Tau source. It probably wouldn't take much to modify the BMP085 driver to work with the BMP180 though.

If I was doing it from scratch I'd probably just get a GY86 board off ebay which includes the MPU6050/MS5611/HMC5883 all together ready to go. But costs $20 (mostly due to the MS5611).

Or I'd find a MPU-9250 breakout which is gyro/accel/mag all in one and is what Peabody is using on Sparky2 (at least so far..and he's using SPI instead of I2C but hasn't released his code for it just yet) They go for about $10 on ebay. Then add a MS5611 breakout for about another $10 or so.

Though of course at that point you're spending $20 on sensors and $15 on a Discovery board so you're almost spending as much as just getting a Sparky which would be smaller lighter and is more proven.

And on the other hand doing it like I did with individual sensors is probably the least cost effective method...but lets you add sensors one at a time to build up.

 

[Quad]

I'd say go with what the original code is setup for. The only reason I used what I had was it was what I was already using with my MW setup and had on hand/installed in the airframe.

The only real difference is I'm using a BMP085 instead of a MS5611 as my baro sensor. And the BMP085 is now discontinued and getting hard to find so there's not much point in going with it. The MS5611 is more expensive but much more accurate. A BMP180 would be a current low cost choice that's higher accuracy than the 085 but not quite as high as the MS5611. But I don't see a driver for the BMP180 in the Tau source. It probably wouldn't take much to modify the BMP085 driver to work with the BMP180 though.

If I was doing it from scratch I'd probably just get a GY86 board off ebay which includes the MPU6050/MS5611/HMC5883 all together ready to go. But costs $20 (mostly due to the MS5611).

Or I'd find a MPU-9250 breakout which is gyro/accel/mag all in one and is what Peabody is using on Sparky2 (at least so far..and he's using SPI instead of I2C but hasn't released his code for it just yet) They go for about $10 on ebay. Then add a MS5611 breakout for about another $10 or so.

Though of course at that point you're spending $20 on sensors and $15 on a Discovery board so you're almost spending as much as just getting a Sparky which would be smaller lighter and is more proven.

And on the other hand doing it like I did with individual sensors is probably the least cost effective method...but lets you add sensors one at a time to build up.

Thanks for the detailed response. I like the sparky and the price is right. I would like the extra features available with the custom route. In particular way point navigation... The quanton would be perfect as well but spendy out of Germany...