More crazy homebrew FC experiments

[jhitesma]

Progress! Turns out after making changes on the hardware settings you have to reboot the board. No wonder all my changes didn't seem to be having any effect.

I got both my PWM and my PPM RX's working. Though not well enough to fly with.

With both RX's for some reason I get my pitch responding to the inverse of my throttle - even through throttle and pitch are on different channels. Not sure how that can be happening. But I can't find any screen that will show me my RX other than going through the setup wizard or doing a manual setup which means having to reset all 8 channels again which is no fun to go through.

Even more odd, the stock 9x PWM RX passes the failsafe test even though I know it doesn't have a failsafe. And the homebrewed PPM RX that supposedly does have failsafe (though I've yet to test it anywhere else) doesn't pass the failsafe test.

But it seems to be mostly there...just a few minor things to work out. Maybe tomorrow I will be able to get it in the air.

 

[x0054]

Progress! Turns out after making changes on the hardware settings you have to reboot the board. No wonder all my changes didn't seem to be having any effect.

I got both my PWM and my PPM RX's working. Though not well enough to fly with.

With both RX's for some reason I get my pitch responding to the inverse of my throttle - even through throttle and pitch are on different channels. Not sure how that can be happening. But I can't find any screen that will show me my RX other than going through the setup wizard or doing a manual setup which means having to reset all 8 channels again which is no fun to go through.

Even more odd, the stock 9x PWM RX passes the failsafe test even though I know it doesn't have a failsafe. And the homebrewed PPM RX that supposedly does have failsafe (though I've yet to test it anywhere else) doesn't pass the failsafe test.

But it seems to be mostly there...just a few minor things to work out. Maybe tomorrow I will be able to get it in the air.

This is a wiled stab in the dark, without hardware I can't really use the TL GCS. But one of the data objects in the properties tree is DataObjects>ReceiverActivity. That sounds like something that should in theory show you what the RX is doing. Perhaps it will help figure out the strange pitch problem.

- Bogdan

 

[jhitesma]

It does, but it only updates every 2 seconds by default. So it's kind of hard to tell just how well sticks are reacting. There's a "controller" module you can enable and I replaced one of the graphs with it but it doesn't seem to be showing any stick movements - even though I can arm/disarm by stick.

I did learn that the issue with the Pitch and Throttle appearing to be linked is a bug in the version of GCS I was using. So I've got a new linux build of the latest GCS going now and will grab a jenkins build of the latest windows nightly tomorrow.

The fun of running development instead of release code Because I just had to make this that much more difficult on myself!

Still need to cleanup the RX wiring a bit, but tomorrow I should be in good shape to swap this for my Mega board and see if I can get the BMP085 to work or not.

 

[jhitesma]

Well, didn't make the progress I had hoped to today. Figure out all the pin mappings but I'm just too tired to wire anything up. Our weather is finally turning nicer and the first of our city 5k races was today and I try to run in all of them ... but since it's still in the 90's this one is an untimed evening race on Friday instead of morning on Saturday like they normally are. And this year my wife is doing the fun walk while I do the run. So we had to drop our daughter at the drop in daycare before the race and pick her up after...by the time she was in bed and we got dinner...I'm just too exhausted to do much.

I did get the mega board off, and was about to wire everything else up when I suddenly remembered that MW only uses SCL/SDA for the MPU-6050 but Tau uses SCl/SDA/INT so I've got to add another wire to my homemade IMU - and that means opening the center section of my knuckle which I had hoped to avoid. Suddenly what I thought would be a 20-30 minute project is looking more like an hour and I just don't have the energy for it.

Plus I have to figure out how to mount this Discovery board. I'm starting to think my best bet may be to put some sockets on perf board with everything wired to them and mount that to the quad then just plug in the discovery. But I don't have suitable sockets on hand and doubt Radio Shack carries them Maybe I can hack something out of some old IDE cable connectors. They're the right pin size...but they aren't quite long enough so I'd have to grind the ends a bit to get them to fit...they are long enough to hit all the pins I need to connect to though so this may work. Maybe tomorrow I'll cut a new lexan top plate for the knuckle (I've been thinking about doing that since I still have lexan from the UBMQ and I'd like to show off the rats nest of power harness in there...oh wait...no maybe I don't want to show that off. Maybe I'll just cut a wood plate instead Either way cut a plate, epoxy the IDE headers to it - then solder my wires to the headers pins and plug in the discovery. Should make for a very clean setup.

But it's not happening tonight, so probably no flying it tomorrow Maybe I'll get lucky and get it finished tomorrow and find time Sunday to fly...though we've got a pretty full family day planned.

Meh, we'll see. I'm dying to get this in the air so I'll probably find time tomorrow

 

[jhitesma]

Oh yeah, also found out why failsafe isn't working on the homebrew RX. Turns out the default failsafe on it is to set everything to midpoint - so it still looks like a valid signal to the FC. Only way to change that is to reflash the RX. So I'll have to dig up the source, reflash then reconfigure everything and test it again. Did not expect the RX to give me so many hassles on this!

And since this page is completely devoid of photos I better fix that with a few progress shots before I call it a night:

Here's the Discovery in it's current state sitting on top of the knuckle. The RX will stay on top wired directly like this. But the MPU will be swapped for the one installed inside the quad (along with a mag and baro that are in there - and which will require some testing once I get the wires switched around.)


IDC connector removed from IDE cable:


And test fit - turns out once you remove the retaining piece on the other side of the wires it fits without any grinding. Nice. Scavenge one more of these, glue them to a new top plate and I'll be ready to do some final wiring. It's an ugly hack...but since everything else about this is an ugly hack why not!


And finally a close up of the homemade RX that still needs to be cleaned up a bit. Debating whether to replace the resistor and LED with SMT bits tacked directly to the board/each other to keep it small...or just trim the leads down a bit and add some heat shrink. The RF module isn't very visible but it's peeking out on the lower left side of the arduino board. You can see it better in the top photo and that it has a couple inches of wire on it so I can move it away from the rest of the boards easily.


Ok, off to bed now, for real this time

 

[x0054]

How cool, you are almost ready to fly! That board is indeed huge, but it looks at home on your quad. Looking foreword to you flying it.

 

[jhitesma]

I could be almost ready to fly...but I decided tonight to slow my pace a little and do it right rather than keep pushing just to get it in the air. I'm not on any schedule after all

First I dug into the guts of the knuckle since I have to add that int line. It's just as ugly in here as I remembered, maybe going to a lexan plate isn't going to be a good idea after all


Next I added the INT line, the area under the pads was clear so I just tinned it up, tinned the pad, then shoved it in while the pad was hot. It's not a perfect solder joint but I figured the risk is lower than if I was to pull the MPU up and really start moving things around. I used a bit of broken prop (the same bit I used to hold my ancient camera) to protect the wires from the heat of soldering and any accidental slips. It all went smooth and I now have an INT line from the MPU on the Knuckle. I thought about removing the level shifter since everything here should be 3.3v - but I'm trying to remember why I had to keep it in on the mega as I thought on there I would have been able to run everything at 3.3. I'll have to double check the wiring and see if I really need to keep it in there.


With the INT line attached I moved on to cleaning up the RX. I tried to do a SMT - but with the 0603 sized parts I have on hand it wasn't going to happen. Maybe if I had four arms. So I just cleaned up the existing wiring a bit:


In addition to repositioning the LED and resistor I cleaned up the wire connections and replaced the bit of servo wire with melty insulation with a bit of enameled wire instead. I got this ultra fine wire from dave1993 on RCGroups and it's got some really nice enamel that melts off instantly at lower temps. Very easy to work with but very tiny and fragile:


I then tested it to make sure it's still working and once it passed I put on some heat shrink. All told it's <10g which is a lot better than a stock 9x RX or even my stripped down one!


Of course - after I finished I remembered I have to reflash it to fix the failsafe settings. I was able to poke holes in the heat shrink to get the FTDI on there tough so that's the last step in wrapping up this RX and it will be ready to go.


Tomorrow night I'll probably work on actually wiring the discovery up. Then I'll find out if I can get the mag and baro working. Then I can deal with mounting this monstrosity.

Getting closer and closer though!

 

[makattack]

Well done on your progress so far! Thanks very much for detailing your progress. I'm definitely happy and impressed to see how quickly you've progressed and how you make it all seem somewhat straight-forward!

I agree with what you and Burly think about the edison. When I first heard about it, I couldn't help but think that with the built-in CPU (atom)/uC (quark), with one side (atom) running linux, and the uC side arduino compatible, it would allow for running arduplane/copter/rover on the uC side, and the CPU side handling more sophisticated flight automation functions. I guess 3DR saw the same possibilities as that sounds like their direction. Use the atom for visual recognition, route following algorithms, etc.

Anyhow, I agree that if you're focusing on flight mechanics, using a uController is much more sensible. Yeah, I also wonder about folks who use the rPi, edisons, etc to programmatically light up LEDs, when an arduino or it's many uC ilks with a RT-OS can do the same with less hassle than a computer running a full multiprocessing OS.

What really impresses me is, it's taken you less time to get a DIY flight controller setup than it has taken me to finally debug a minimOSD board I bought months ago. Turned out it was a weird PAL/NTSC detection issue.

 

[jhitesma]

Thaks for the compliemnts and don't feel bad, it took me longer to get my minimOSD working too Mainly because using my 3.3v UART->USB adapter the config program would connect and all would seem to work...but I finally figured out that the settings don't actually save unless you're using a 5v adapter

Spent most of a week fighting with that!

As I feared our plans today precluded any further progress. I was really hoping to cut a new top plate and get the pin headers glued into it to ease the rest of construction since that's a job that's tough for me to do on weeknights. May have to do it on a lunch break this week which will make taking photos trickier since I'll be in a hurry.

I may still solder up those sensors tonight to test...I really want to see how it does with my full MPU/mag/baro setup. But I'm pretty tired and early bedtime is sounding very temping

 

[jhitesma]

Progress report. Over lunch I fired up the soldering iron and connected the wires to sensors built into the knuckle. Just barely had enough time to hook it up to GCS and test...but it's responding!

Don't know if I'm getting any IIC errors or not yet and haven't recompiled to try and get the mag working (let alone the baro) - so still a lot of testing to to tonight. I did notice the rotation is off. Not sure if I can rotate that in software for the sensor or if I'll have to physically re-position the individual sensors on my homemade IMU. I'd rather deal with removing and remounting them so adjusting in software would be preferable for me and I'm sure there's got to be a way to do it.

I'm half tempted to just jump ahead and connect the four motor wires and give it a go...but I'll be good and wait until I've finished software testing with the mag and baro before taking that step. But so so tempting to hear those motors spin up

 

[jhitesma]

Well I've got a working MPU-6050 and a working HMC5883 mag sensor

It was a bit of a long trip because I decided to get a bit serious about this and wiped out my entire source tree in the virtual machine then replaced it with my own fork: https://github.com/jhitesma/TauLabs

Nice thing about doing my own fork like this is if I ever do anything useful to the code I can create a pull request to offer my changes back to the main project. It also helps me keep my codebase up to date with the latest changes which is fairly important since the code changes so quickly.

The big downside to this is I wiped out eclipse in the process so now I'm using command line tools in my VM to develop. I didn't realize that the eclipse installation was inside the code tree like that I could re-install eclise but the project setup is really complex and I can't find any reference on how to set it up. Eclipse is one of those tools I don't mind using if someone else configures it for me...but I just can't get my head around how to setup projects in it myself

So I'm going to dig in on adding the BMP085 files now and while that complies I'm going to keep tweaking my virtual machine to try and get it so I can share folders between the virtual machine and my host. That way I won't have to e-mail myself the new firmware each time I build it

Fingers crossed I can get BMP085 support working. The only other guy I found who tried it gave up...and he sounded like he knew what he was doing more than I do so I'm a little worried about this!

 

[Twitchity]

I'm half tempted to just jump ahead and connect the four motor wires and give it a go...but I'll be good and wait until I've finished software testing with the mag and baro before taking that step. But so so tempting to hear those motors spin up

It's only four wires... go for it! No one said you had to fly it yet, but hearing those motors spin might give you encouragement to work harder to get it in the air

I'm really interested to hear how this FC handles while in the air. Would it be possible to program this FC to automatically adjust PID's based on vibrations/oscillations? It would be interesting to see how a feature like that would work to at least get you close to the optimal settings, and then you fine tune from there.

 

[jhitesma]

It's only four wires... go for it! No one said you had to fly it yet, but hearing those motors spin might give you encouragement to work harder to get it in the air

Well I'm stuck on the BMP right now, I added the code to enable it - but now I'm getting a compilation error due to an undefined type when trying to compile it...even though it looks to me like all the includes that should be needed are there so I'm not sure why the type in question is coming up as undefined Since none of the TL boards use the BMP085 it's kind of tricky for me to figure out what's causing the problem as there's no example to go off of. And it looks like it may be related to a major refactor going on with the TL code (they're experimenting with a different real time OS which is more efficient than the one they're currently using so it frees up more memory and processor resources.) Even though no boards use the 085 the code has been edited twice in the past month or so and the changes look to be related to the refactor - but I'm still not clear enough on what's going on in the code to say for sure.

Got a post on their forums looking for guidance, hopefully I'll get some. Until then I may have to back up and work on getting the board mounted and wiring up my motor wires. The mag doesn't do me much good without the baro so I may end up flying on just the MPU at this point.

I'm really interested to hear how this FC handles while in the air. Would it be possible to program this FC to automatically adjust PID's based on vibrations/oscillations? It would be interesting to see how a feature like that would work to at least get you close to the optimal settings, and then you fine tune from there.

[/quote]

Well, it doesn't autoadjust in real time but it does have what sounds like a really good autotune (technically still in development but sounding pretty solid.) The auto tune actually tries to learn the airframe and model it mathematically then calculates the best PID's for it. The tuning is actually done in the ground station rather than on the FC due to how computationally intensive it is. Bit more advanced than what others are doing for autotune and I'm really excited to try it.

The way it works is you setup a flight mode for autotune, take off - enable autotune and then just try to keep it in the air while it does some funky oscillations learning how the vehicle reacts. You then land with autotune mode still enabled and hook it back up to GCS where you can review the proposed tune and load it in to try. One or two people have got some funky results but on their next tries they got good results. So it sounds like overall it's doing a pretty good job, several people have said it got their multi flying better than they were able to with manual tuning.

 

[jhitesma]

Well, had some time at lunch and didn't feel like looking at code. So I went ahead and wired up power from a BEC to the Discovery board and hooked up the motor wires.

But...after doing so my RX didn't power up anymore. Odd. Moved it to another BEC instead of powered off the Discovery...and it powers up, but now TL still shows no RX

So since it's not getting out of error mode it's not sending a signal to the ESC's so I don't even get to hear them make their pretty sound. Bummer.

But I realized I need to rebuild the firmware again anyway since I forgot that I need to rotate the orientation on the MPU.

All of which means - no real "progress" to report despite now having everything connected enough it could potentially fly if I fixed the sensor rotation and got the RX responding again. So kind of close....

 

[jhitesma]

Well, I got to hear the motors spin at least

I'm running the Discovery board off one BEC on the VCC/GND pins. I had my RX hooked up to a 5v/GND pin which was provided by the Discovery board. This worked when I was powering it off the USB port for the st-link. But when I switched to the BEC on the VCC pins my RX stopped working. I tried hooking the RX up off another BEC - now it powered up but it still wasn't communicating with the FC for some reason. Neat feature of the Discovery board is it has extra long pins that protrude out the top and bottom far enough to be connected to. So I moved the RX over to the VCC/GND pins - one side of the pins have the RX on them the other have the connection from the BEC. Boom, it all works.

This is one thing I've noticed with the F20's and I'm not entirely sure what causes it but I have a few theories that are rather tricky to explain. When I was running blue series ESC's on this frame I had no problems running the arduino off one BEC, the GPS off another, the RX off a third and my OSD or other things off the 4th. But once I switched to F20's I started having intermittent issues with communication between things powered by different BEC's. My theory is basically that it has to do with how the BEC's are doing their voltage regulation and how protected they are and that it results in slight voltage differences between parts that are resulting in issues. To explain it quite poorly.

Point is RX is working now, and everything can power up.

I just recompiled and reflashed the FW (with baro disabled still) and think the orientation is now correct on my MPU...except the artificial horizon seems backwards...not in the way people normally mean that though. I mean it in a I tilt left the horizon goes left kind of way. But the 3D model seems to be responding correctly...so I'd guess it's just the artificial horizon operating backwards...but the pitch is backwards as well. Now this may just be me...due to my sensors but I wonder if it's a bug in this pre-release version of GCS similar to the one I ran into with the RX wizard. I need to do some more investigation.

Did some more digging on the code as well for the BMP but still can't get my head around what's wrong. I suspect it's due to to my C++ being so rusty mixed with me not understanding the way everything is setup yet. I'm worried it may not be so simple though, the bmp085 code seems radically different than the code for all the other sensors...I fear it's way out of date and not actually usable..but it's been edited lately so that seems unlikely as well. Just kind of odd.

 

[jhitesma]

Ah, there we go.

In flight/targets/flyingf4/fw/pios_board.c I had to change:

static const struct pios_mpu60x0_cfg pios_mpu6050_cfg = {
.exti_cfg = &pios_exti_mpu6050_cfg,
.default_samplerate = 666,
.interrupt_cfg = PIOS_MPU60X0_INT_CLR_ANYRD,
.interrupt_en = PIOS_MPU60X0_INTEN_DATA_RDY,
.User_ctl = 0,
.Pwr_mgmt_clk = PIOS_MPU60X0_PWRMGMT_PLL_Z_CLK,
.default_filter = PIOS_MPU60X0_LOWPASS_256_HZ,
.orientation = PIOS_MPU60X0_TOP_180DEG
};

to

static const struct pios_mpu60x0_cfg pios_mpu6050_cfg = {
.exti_cfg = &pios_exti_mpu6050_cfg,
.default_samplerate = 666,
.interrupt_cfg = PIOS_MPU60X0_INT_CLR_ANYRD,
.interrupt_en = PIOS_MPU60X0_INTEN_DATA_RDY,
.User_ctl = 0,
.Pwr_mgmt_clk = PIOS_MPU60X0_PWRMGMT_PLL_Z_CLK,
.default_filter = PIOS_MPU60X0_LOWPASS_256_HZ,
.orientation = PIOS_MPU60X0_TOP_270DEG
};

If you missed it all that changed was that last line:
.orientation = PIOS_MPU60X0_TOP_270DEG

That defines the orientation of the MPU chip on this board. the default as "180" and I needed "270" but I got there by way of "90" which had front/rear and left/right responding in the right axis but wrong direction. 270 now has everything responding correctly for me.

Thankfully small changes like this are quick to recompile, only takes a few seconds. Unlike arduino where the entire project gets rebuilt for every little change this is a real dev environment and only rebuilds those parts that have actually changed.

So right now this is probably technically flyable. I need to actually mount the board and cleanup the wiring a bit...and go through the config one more time to make sure everything is setup correctly. But this is as far as I can tell ready to fly. Just without a baro so no alt hold yet.

I'm going to take a day or two and get the board mounted better before I try to fly though. And I should confirm that the mag sensor is giving correct readings.

It seems that the TauLabs team is taking a very close look at MW/Naze and what people like about it and trying to incorporate it. I noticed this issue filed today:

https://github.com/TauLabs/TauLabs/issues/1341

I'm curious to see how this virtualflybar mode feels in the air...along with their version of Horizon, and their rate mode. But it sounds like they may be looking at adding a MW derived rate as well. I also noted this pull request to incorporate code that implements throttle pid attenuation like MW does: https://github.com/TauLabs/TauLabs/pull/1280

 

[x0054]

I got my build environment setup for TL on my laptop on OSX. Yey! Just finished it. Had to download all the huge files at night due to my unique internet situation. I can explore the code a little now, if only I could remember now those few things I used to know about C Looking foreword to your maiden flight.

- Bogdan

 

[jhitesma]

Felt a little reckless at the end of my lunch today:

I had really planned on doing one more complete run through on setup before trying this...but had a few minutes and couldn't help myself

My controls were completely backwards...not sure why but it sure made it hard to fly. The few seconds it was actually airborne it felt very stable though - especially for stock settings.

Will do a more thorough setup on it tonight and work on getting the board mounted better than with a rubber band. Should be able to do some serious test flying by Friday I'm hoping

 

[makattack]

Nice! Congratulations!

 

[x0054]

It's Alive!!!!!!!!!!!!!!! That's really cool, though you didn't get much flight time. Were the controls just reversed? Maybe the direction on the controller got switched? That huge Discovery board looks right at home on that quad though.

Also, what frequency are you running, that antenna is huge! I remember you mentioning that you are running a custom receiver.