More crazy homebrew FC experiments

jhitesma

Some guy in the desert
Mentor
Ok - I'm not giving up on the GPS experiments with the Naze32 on my emax 250. But those experiments are convincing me that the Naze while a great acro board - just isn't great for much more than acro.

Don't get me wrong, it flies GREAT. But the Naze32 is just too limited in a number of ways to be a serious hackers board for someone like me who likes to play with the software that runs on our controllers. It's using the lowest end STM32 chip with the least connectivity and memory - in fact it has fewer UARTS (serial ports) and less memory than the Arduio Mega that I used for my first multirotor build. It also has LED's wired to the pins that would support USB natively on the STM so it has to add a UART->USB chip and TimeCop picked a chip that I'm not a huge fan of for that as the drivers for it have caused me headaches on several occasions.

And while the Naze flies great it doesn't really seem to fly noticeably better than my MW controllers - which isn't shocking since Baseflight is just MW ported to a 32bit processor and even on the 8bit avr's flight code isn't pushing the limits of the processors.

So while I don't dislike the Naze32 I'm not all that thrilled with it right now either since I'm getting bored with "just flying" and am feeling the urge to do more hacking and playing with more semi-autonomous and autonomous flight.

Finding that the Naze32/Baseflight can't run a GPS, telemetry and OSD at the same time was pretty much the final straw.

I've been thinking about trying APM for some time, but I hear so much about how it doesn't fly as well as MW/Naze/KK and has a bit of a rep for unreliability in various ways and my general dislike of 3DR and their commercialization of an open source project...well it got me looking at alternatives.

I learned about Tau Labs a couple of months ago. But I saw they were basically a fork of OpenPilot which has quite a bit in common with APM and I had heard about serious issues with CC3D boards not behaving well...and pretty much wrote them off.

But then a few weeks ago I saw the lead developer from Tau Labs post on his blog about his new Sparky2 board which seems to hit all my buttons: http://buildandcrash.blogspot.com/2014/08/sparky-20-and-taulink.html

Beefy 32bit processor? Yep, STM32F4 (compared to the F1 on the Naze) Plenty of connectivity? Oh yeah, not only does it have plenty of uarts he also added CAN bus and the sensors are running on SPI instead of IIC which could potentially give better performance. Small? Yep, He hasn't posted exact dimensions but from what he has posted it sounds like it may actually be a little smaller than the Naze. Plenty of memory? Yep, the F4 over the F1 again...and he added a flash chip for storing stuff like flight plans, cool. He even enabled DAC output so this thing can generate audio (think spoken alerts from the FC hooked to the audio pin on your FPV VTX - kind of like telemetry only audio and super easy to rig up.) But the clincher for me is that while it's potentially a 1 sided board he used the back side to mount an optional RFM22B module.

The RFM22B is the same module used in openLRS. Basically this is a flight controller with RX built in. Something I've been wanting to make since I started messing with my first multi!

The big bummer is that the sparky2 isn't released yet. It's only available to people who've tested his boards before and I'm not one of them :( But it has me very interested in Tau Labs and I want to try their code on the cheap...so back to my roots!

I ordered up a DiscoveryF4 board pretty much as soon as I realized it only costs $15 and has a built in ST-LINK debugger - so even if I abandon this project I'll have a nice development board with some serious hardware on it and a STM debugger that should be nice for working on things like the Naze32 if I dig deeper into the software. I also tossed in the flash chip (it was <$2) and a few replacement oscilators so I can repair a few broken ESC's and a few other little components I needed.

I then dug in on the software side. Tau Labs has a downloadable Linux virtual machine setup as a dev environment so it's really quick to get going on developing their software. I did hit a few little snags the first night due to the VM being a bit funky and some of the tools in it being out of date - but once I got it figured out I was able to build the flight controller code no problem. So far so good!

Next I tried to build the ground control software...that turned into a bigger hassle but again was due to outdated tools in the VM. I'll post more details about this all later tonight but basically going through the Linux dev setup instructions from the Tau wiki brought the VM back up to speed and I got the ground system to build (though the build took over 2.5 hours, been a long time since I compiled something that took that long to build!)

And that's where I've been the past few days waiting on my DiscoveryF4 board that wasn't scheduled to arrive until tomorrow. But when I went home for lunch today USPS surprised me and it was sitting there waiting for me. So between bites of my lunch I got to work.

Compared to my emax quad it's obvious that this is not going to be a small setup :) The Discovery is a dev board for playing around with the STM chip not an actual flight controller. And 98% of the stuff on there isn't even needed for a flight controller. There is a 3 axis accelerometer on there but with no gyro the board can't be used by itself as a FC.
10722357_10152305019951805_561814155_o.jpg

And while big it's not THAT much bigger than my Arduino megas. In fact it's a little shorter - but wider. So it should fit on my knuckle quad no major problem.
10722325_10152305036921805_1094712188_o.jpg


I quickly hooked it up - only to find that the built in sample program wasn't working. The instructions that came with the board said to push the blue "user" button and it would enable the accelerometer and light up LED's showing how fast and in what direction it was moving...pushing the button did make the lights go out...but didn't seem to make the board respond to movement. The instructions also said that you could plug in off the other USB port and it should work as a mouse - and while windows does identify it as a human interface device when plugged in like that...I couldn't get my mouse pointer to move. A little worried I decided to just push on.

I fired up ST-LINK and the board was recognized. So far so good. I followed the instructions from Tau on how to flash the bootloader: https://github.com/TauLabs/TauLabs/wiki/Creating-a-FlyingF4-from-scratch and found that the instructions were slightly off. I never got the confirm dialog they talk about and had to initiate a write sequence myself. No big deal and it seemed to complete successfully.

But when I powered it up I didn't get the slowly flashing blue light they said I should. My blue light came on...but was just kind of dim and not fading in/out. Hmmm.

Being in a rush and foolhardy I fired up the Tau GCS and tried to flash the firmware. It completed successfully and things seemed to be working...but the GCS wasn't connecting to the board and my computer kept beeping that something on the USB was connecting and disconnecting.

Oh yeah...I had read about this. If the firmware can't initilize it's expected sensors then it reboots. Since I hadn't hooked up any sensors yet the board was just rebooting since it couldn't init the MPU-6050. Doh.

Broke out the soldering iron and wired up a MPU, Tau uses the interrupt line which MW/Naze don't so I had to add one extra wire but still got it hooked up pretty quick:
10677185_10152305102436805_1297337513_o.jpg

Now the GCS recognizes it as a "DiscoveryF4" but still doesn't seem to connect. I'm guessing it's because I haven't added the flash chip yet so I'll be doing that tonight. But it is good to see things light up at least :D
10718177_10152305105226805_651397124_o.jpg

More to follow later tonight, I'm really hoping to get this at least to where GCS will connect and I can read the sensors before I go to sleep tonight. If I can do that tomorrow I should be able to get it wired up in place of my mega and may be able to test fly it on my Knuckle before the weekend if all goes smooth.
 

jhitesma

Some guy in the desert
Mentor
Oh yeah, one more little thing. Looking at .the Discovery board you'll notice two large chips. The largest in the middle is the STM32F4.

The other large chip centered between the F4 and the mini USB plug on top (the end without the audio plug) is a STM32F1 like the Naze uses. On this board it's used as part of the build in debugger. Seeing them both on the same board it's gives a bit of an indication how much more the F4 is capable of ;)
 

jhitesma

Some guy in the desert
Mentor
You have the skills I so wish I had!

Thanks, but I don't do much more than follow instructions from the guys with the serious skills :)

I made a bit more progress, but I'm not sure if I'll be making my goal of flying this thing this weekend or not now. Apparently the "FlyingF4" codebase actaully expects a MS5611 baro like the Naze uses, and all I have on hand is a BMP085, I do have a dead Naze I could scavenge the MS5611 off of...but that's a bit much to wire up dead bug like this. So instead I'm going to look into modifying the code to eliminate the baro or use a BMP085 instead. I found a thread on the tau forums from someone who tried to get it working with a BMP085 before but he didn't get it working and seems to have given up - not very encouraging. So disabling baro for now may be my best bet. Afterall I'm really mostly interested in seeing how this code flys and I really only need a gyro for that (though having the accel is nice as well and with the MPU-6050 I get both so I'm covered for auto-level modes as well.)


Basically right now my board is just flashing the LED 4 times which indicates an error with the MS5611 :(


So instead a flashed the "DiscoveryF4" code which I don't think is flyable as I think it has all sensors disabled. That worked and I was able to get GCS to connect to the board:
10703141_10152305641696805_355188327_o.jpg

Which means at least I can confirm my board is working and I can flash it enough to get it talking to GCS. Not bad for less than 2 hours of tinkering.

I'm typing this up as I wait for the soldering iron to heat up, then I'll wire up the flash chip. With the flash on I'll give it one more try just for giggles but don't expect anything to work any better.

After that it will be back to software hacking. There's a lot of code in Tau and I'm completely unfamiliar with how it's setup so tracking down what needs to be done to enable/disable a sensor on a board config is currently eluding me. But thankfully I like learning new things so we'll see how deep this rabbit hole goes ;)

If I get frustrated I'll stop back and write up my info on getting the VM working and updated to be able to build code.
 

jhitesma

Some guy in the desert
Mentor
Well that went better than I thought. I spent more time filming a little success video and trying to post process it to look halfway decent due to the horrible lighting back here right now and my unwillingness to rig up any better lights for a short "I did it!" video :)

Still have to wait on it to re-encode and upload though so may not get it posted until tomorrow. Here's a static photo in the meantime:

10722733_10152305936686805_386676235_o.jpg

But I have the flyingF4 configuration flashed and talking to GCS with the MPU-6050 working!

Still a long way from being something that can fly. But the basics of a FC are there and working correctly!

All I had to do was comment out two lines in flight/targets/flyingf4/fw/pios_config.h

Original:
/* Select the sensors to include */
#define PIOS_INCLUDE_HMC5883
//#define PIOS_INCLUDE_ETASV3
//#define PIOS_INCLUDE_MPXV5004
//#define PIOS_INCLUDE_MPXV7002
#define PIOS_INCLUDE_MPU6050
#define PIOS_MPU6050_ACCEL
#define PIOS_INCLUDE_MS5611
#define FLASH_FREERTOS

My edit:
/* Select the sensors to include */
//#define PIOS_INCLUDE_HMC5883
//#define PIOS_INCLUDE_ETASV3
//#define PIOS_INCLUDE_MPXV5004
//#define PIOS_INCLUDE_MPXV7002
#define PIOS_INCLUDE_MPU6050
#define PIOS_MPU6050_ACCEL
//#define PIOS_INCLUDE_MS5611
#define FLASH_FREERTOS

Then I just had to compile and flash it...and boom it works!

And in my video I'm only getting an artificial horizon, the main status panel isn't responding. However I do mention in the video that I was running the wrong version of GCS for the firmware I have flashed and having those match is both vital - and a bit of a pain when you keep up with the dev code because changes to one affect the other. I just grabbed the official nightly build for windows and tried it - and it works great now since I'm running the latest code. So until I can get the build environment for windows setup (which I may or may not ever do) I can just use the official nightly builds to keep up.

I may have to scrap what I've done so far though and set this all up properly and cleanly based on what I now know. I'll also clone the repo on github and keep my own fork so I can both keep my personal changes in sync with the main code - but also if anything I do is worth sharing I can easily submit it back. (Baseflight and Cleanflight are also using github but they're not nearly as active or as granular with their commits as TL is) I kind of want to get it flying first though, if it doesn't fly well I don't see much point in continuing to mess with it.

But so far the more I do the more impressed I get. I just went through the setup wizard and have to say this makes Baseflight feel like a KK before the LCD as far as setup. Since I don't have a RX or motors hooked up yet I wasn't able to do very much with it. But...yeah...their GCS is pretty amazing. If the flight code is half as good I expect it to fly great.

Which is great because once again I'm purposefully making this hard on myself to make myself learn. You can pick up an official Sparky board from Dragon circuits right now for...well...maybe you can't right this minute as their website is having problems. But here's the link when it works: http://www.dragoncircuits.com/shop/ And IIRC the boards are a bit under $70 which IMHO is a bit pricey. But RTFQ has as usual made a clone and they go for $40: http://witespyquad.gostorego.com/flight-controllers/sparky-flight-controller.html

I did a bit of research and with boards from SEED and parts sources from Digikey making 10 boards in a batch they could be produced for about $30 each. Step that up to 100-200 boards in a batch and you could get the price even lower. But I suspect the Dragon boards are more than a little higher quality than what SEED makes and assembled better than what most people could do at home, certainly better than I can do with my current abilities (I really need to build a controller for that spare toaster oven one of these days.)

The big catch on the sparky is it's PPM only (well, PPM, Sbus and DSM sat to be technical) and only has two serial ports. Oh and it's kind of a funny shape. But I could easily see it replacing the Naze for me in some multis.

The other commercial Tau board is the Quanton which is $70 and comes from europe. (RTFQ of course has his clone for $60) They support more features but are also larger (54mmx54mm)

So the commercially available hardware is pricey and has some downsides. But the designs are all open and can easily be cloned at lower costs and the firmware is flexible enough to run on a number of less supported platforms (like Naze and CC3D - though with severe limitations)

Personally I'm excited about this not just because of the Sparky2 adding built in RFM22B support, but also because everything is open enough it's a joy to hack on and the development community around it seems a lot more active and friendly than other options.

Grrr, avisynth just crashed processing my video about 85% through :( Gotta go restart that so I can get the video up.

Now...to hook it to the knuckle and get reckless...or try to get the BMP085 code working first...the bmp085 is pretty securely mounted in the knuckle right now so it will be easier to hook it up by installing the board on the quad first....
 

Attachments

  • 10703141_10152305641696805_355188327_o (1).jpg
    10703141_10152305641696805_355188327_o (1).jpg
    272 KB · Views: 41
Last edited:

x0054

Senior Member
You are making awesome progress! I think I am going to pick up one of those Sparky boards later on this week from wither RTFQ or Dragon, so I can play around with it on a smaller quad like my Foldy. It would be interesting to see how well TL does at flying a miniquad. With APM I had problems running a small H-Quad, even though it runs my bigger Tri just fine. Hopefully this wouldn't be an issue with TL.

Oh, and if you typed all that while your soldering iron was warming up, you either type really fast, or you have a very slow soldering iron :) Locking foreword to building one of these!
 

FinalGlideAus

terrorizing squirrels
Cool stuff Jhitesma.

I do believe I've been saying this the whole time about the Naze 32 ;). Great acro board but not so much for a full GPS setup...
 

jhitesma

Some guy in the desert
Mentor
You are making awesome progress! I think I am going to pick up one of those Sparky boards later on this week from wither RTFQ or Dragon, so I can play around with it on a smaller quad like my Foldy. It would be interesting to see how well TL does at flying a miniquad. With APM I had problems running a small H-Quad, even though it runs my bigger Tri just fine. Hopefully this wouldn't be an issue with TL.

Oh, and if you typed all that while your soldering iron was warming up, you either type really fast, or you have a very slow soldering iron :) Locking foreword to building one of these!

If I had the money and/or patience I'd grab one of the Sparky boards to play with. But this gives me an excuse to learn the internals and I think you have a good idea why that interests me ;)

As for the soldering iron, I do type fast...but I ended up not needing it since it turned out that the flash chip isn't even enabled in code on the flyingF4 even though the "how to build a flyingF4" page lists it as required. Wouldn't wouldn't be so bad except the only two things it lists as needed are the MPU-6050 and the Flash chip. When in reality the code is setup to work with a GY-86. (Side note - that's something I haven't looked into yet...how to change sensor orientation, I haven't seen a way to change it yet in the board config files but it should be there. It may be runtime configurable though and I'm still exploring GCS.)

So the fix was all software no hardware.

FinalGlideAus said:
Cool stuff Jhitesma.

I do believe I've been saying this the whole time about the Naze 32 . Great acro board but not so much for a full GPS setup...

Thanks, I was worried people wouldn't find it interesting but the way the view count is climbing I guess I was wrong about that. Then again having just watched todays FT episode maybe I just timed this really really well and am catching the eye of new visitors :D

(Side note: I had to SEARCH to find todays episode because I didn't see it in my feed. I also subscribe to Make's channel and they had so many maker fair videos posted this weekend that robot just blended in and I never thought it would be FT's video :D )

And I don't believe I ever questioned or doubted what you've been saying - but since there are so many Naze boards out there I still want to push mine to it's limit to see how far it will go ;)


I was hoping to write up what I learned about setting up the VM and build environment tonight...but...well it's past my bedtime. So that will have to wait a day or two I guess. Just want to do it before I forget how I did it :)
 
Last edited:

Twitchity

Senior Member
Fantastic write-up so far, jhitesma. I'll eventually dive into GPS/altitude hole and OSD one of these days and it will be nice to have a board that fully supports all of these features.
 

cranialrectosis

Faster than a speeding face plant!
Mentor
Thanks, I was worried people wouldn't find it interesting but the way the view count is climbing I guess I was wrong about that.

Are you kidding? With all the nerds on this forum, this will be a HUGELY watched thread.

I'll be reading with relish. :)
 

SOOFLY

Senior Member
While reading this I felt like I was watching the Facebook movie when he was writing the code and linking the databases. This is all way over my head, but it's still interesting to follow along.
 
Last edited:

makattack

Winter is coming
Moderator
Mentor
Thanks, I was worried people wouldn't find it interesting but the way the view count is climbing I guess I was wrong about that. Then again having just watched todays FT episode maybe I just timed this really really well and am catching the eye of new visitors :D

Speaking of Maker Faire and flight controllers -- while I was there, I saw they were selling the Intel Edison at the Makershed, and with some sparkfun add-on boards coming out, such as these:

accelerometer, gyro, compass: https://www.sparkfun.com/products/13033
battery: https://www.sparkfun.com/products/13037
the interface boards for PWM, I2C, etc: https://www.sparkfun.com/products/13043
and the microsd board: https://www.sparkfun.com/products/13041

Could all combine to make for a compact (if pricey) flight / rover controller... but, then I noticed 3DR have a partnership with Intel:

http://3drobotics.com/2014/09/3d-robotics-partners-intel-develops-new-drone-power/
 

jhitesma

Some guy in the desert
Mentor
The Edison is intriguing...but out of my price range for now :D Definitely looks like a heck of a powerful setup - but then again it's not like we're lacking for power on FC's.

My Video from last night finally finished processing and uploading - so here it is in all it's horribly underexposed glory. Please excuse my presentation - haven't been getting enough sleep this week :D



One thing I will add is that if I had a GY-86 10DOF sensor board instead of just my MPU-6050 then this would have all worked right out of the box. The things I had to change were due to my lack of baro/mag sensors. With a DiscoveryF4 and a GY-86 you could flash the official release's bootloader and firmware and be off and running.

Except of course one of the biggies I'm interested in is their autotune code - and that's only in the dev branches for now and the official release is from March IIRC so it's pretty far out of date right now. But...it looks like TL is getting ready for a new release very soon.

Thanks for all the feedback and support! Hopefully tonight I'll get the arduino mega off my quad and get this on instead.
 

jhitesma

Some guy in the desert
Mentor
Well, that was embarrassing. Ate a quick lunch again so I could do more hacking on this. Grabbed my homemade arduino pro mini with A7105 module FlySky RX and tried hooking it up. The instructions on Tau weren't clear just how to hookup PPM though they do make it clear that PPM is the best choice. https://github.com/TauLabs/TauLabs/wiki/User-Guide:-Connect-Receiver

To connect a sum signal receiver, you have to select PPM. Receiver have to be connected to first input. Thart's the best way, its easy and you have more flexibility to connect additional Hardware (Flex-Port).

"Connected to the first input". Ok...but is that the first PWM input or the first UART input? I figured they probably meant PWM and wired it up there. Hooked the VCC/GND wires up to suitable pins on the Discovery (It has both 5v and 3.3v available) and connected it all up. Something was bugging me though. I could have sworn I had a big bulky 5mm blue LED on the RX but there was no LED wired. On the upside I thought I just had bare wires on it but there was a servo connector wired up - guess I just forgot I had done that. Hmmm.

Spent the rest of my lunch trying to figure out how to set things up for PPM input. Think I figured it out and it's not that tricky...but I was still getting to inputs. Hmmm.

Then I looked at the RX again and it hit me. This wasn't my homemade RX. Yeah, it's an A7105 hooked to a pro mini...but it's NOT my RX. It's my Hubsan TX module <smacks forehead>. Yeah, that's not going to work.

Back to my work bench and sure enough there's the RX with it's big 5mm LED and bare wires. Doh! Unfortunately at this point I had to run back to work so I didn't have a chance to try wiring it up :( But I know what I'm doing soon as I get home from work now ;)
 

Burly

New member
Intel dearly wants to take part in this DIY Maker Craze.
The trouble is...they really don't make a microcontroller that has the necessary low level I/O.

They make big chips designed for OS driven Machines.
So trying to make the Atom look like Arduino(Atmel) is overkill.
That's the reason they have to kick in Intel's version of a microcontroller...the Quark.
Intel wanted the Quark go up against the ARM.
Is a Quark used anywhere?
Oh...and the Atom/Quark combo runs some sort of exotic flavor of Linix...good luck making that work.

Go out to SparkFun and look at the Edison page...and count all the shields you would need to stack up before this base Edison Module is anywhere near useful. The result would have more layers of PCB salami than the finest Manhattan deli sandwich.
 

jhitesma

Some guy in the desert
Mentor
I have to admit the Edison kind of falls into that same category as the RasPi for me. Too small and underpowered to replace a computer for most things and too big and overpowered to replace a uC. They're useful and people are doing lots of cool things with them. But so many of those cool things I think "why? They could have just tossed a $3 arduino on there and saved a lot of time and money!" or the project seems to stall out because the platform can't keep up with the developers ideas.

Anyway. Back to the flyingF4.

I'm stuck. I can't get it to read any of my RX's, tried both PPM and PWM setups. I think I'm doing something wrong in configuration. I had it working for a minute...but then when I rebooted the board I lost it :( Which is funny because rebooting it was what got it responding finally in the first place!

Wanted to post more but still dealing with debugging. Really want this thing working and it's so close....