More crazy homebrew FC experiments

[RAM]

This is off topic but I don't know where else to ask this question. Since you guys are doing all the crazy experiments I need to pick your brains for a second. Sorry for the interruption.

Question: Has anyone taken the time to turn a multiwii or kk2 or other flight control board into a diagnostic tool? I would like to use a spare controller as a tool for chasing vibration problems. Thanks

 

[jhitesma]

This is off topic but I don't know where else to ask this question. Since you guys are doing all the crazy experiments I need to pick your brains for a second. Sorry for the interruption.

Question: Has anyone taken the time to turn a multiwii or kk2 or other flight control board into a diagnostic tool? I would like to use a spare controller as a tool for chasing vibration problems. Thanks

I've seen it done with a MW board. But there's not much interest in it anymore since:

1) cell phones - just load a seismograph app on your phone and stick it on there.
2) MW added a way to do this but I haven't used it in so long I can't remember the details
3) BF/CF have the option to spin motors up manually while watching the graphs and most people have gone 32bit.

e_lm_70 did something along those lines you may find interesting:
http://www.rcgroups.com/forums/showthread.php?t=1913379

 

[PHugger]

Th FT crew did some vibration reduction with a small mirror and a laser pointer.
You attach the mirror to your frame or boom and shine the laser on it, projecting the beam onto a wall.
Any vibrations will jiggle the mirror and move the beam around on the wall.
You balance in the normal way until the vibrations are minimized.
Much lower tech, but LASERS!


Best regards,
PCH

 

[RAM]

I've seen it done with a MW board. But there's not much interest in it anymore since:

1) cell phones - just load a seismograph app on your phone and stick it on there.
2) MW added a way to do this but I haven't used it in so long I can't remember the details
3) BF/CF have the option to spin motors up manually while watching the graphs and most people have gone 32bit.

e_lm_70 did something along those lines you may find interesting:
http://www.rcgroups.com/forums/showthread.php?t=1913379

Thanks, that's what I was looking for. Sorry for interrupting.
I knew about the phones but didn't want the weight of the phone to change the damping.

 

[RAM]

Th FT crew did some vibration reduction with a small mirror and a laser pointer.
You attach the mirror to your frame or boom and shine the laser on it, projecting the beam onto a wall.
Any vibrations will jiggle the mirror and move the beam around on the wall.
You balance in the normal way until the vibrations are minimized.
Much lower tech, but LASERS!


Best regards,
PCH

I've used lasers, much easier imo to see problems. I just wanted another option but using a flight controller instead of a phone

 

[makattack]

The other option is to use flight logs to help troubleshoot. With the datalogging features that many of the flight controllers have (unfortunately, not for MultiWii though), you can download them and plot them against different stored values to at least see when you have the worst vibrations.

 

[narcolepticltd]

The other option is to use flight logs to help troubleshoot. With the datalogging features that many of the flight controllers have (unfortunately, not for MultiWii though), you can download them and plot them against different stored values to at least see when you have the worst vibrations.

I'm really digging the potential blackbox is bringing to the table in cleanflight... can't wait for more FCs to show up that have a decent amount of storage on board to take advantage. there are better videos showcasing it out there already, but I like this one as it really shows those oscilations as you hear them:

 

[jhitesma]

So...after flying this guy in combat at Flite Fest back in July it's been mostly gathering dust. And for no good reason. Mainly just because I haven't been motivated to fly it lately.

But there's been a development. Tau recently gained some new developers who were really motivated and making a lot of updates. But they weren't getting the support they expected from the BOD of the group that oversees Tau resulting in frustration and slower progress than they wanted. Toss in some differences in opinion on the way things should go..and..they forked. But then the BOD talked them into coming back and working to change Tau...that went on for a few months but the frustration continued to build and about a week ago they reached a breaking point and re-forked. It was amicable and many of the devs that have split to the new project are still contributing to Tau at some level. But they have some rather interesting ideas on where they want to go and I'm very interested to see what they do. Interested enough I've been helping out as best as I can and offered the hot pink flyingF4 up for testing as well as been helping with getting social media accounts setup for the new group (more on that when they have the first public release ready.)

The forked codebase isn't ready for flight yet, it's got some fairly major fairly scary changes in it that still need testing. But I haven't been flying the knuckle Tau so I figured I'd try building the new code and see if I could get it to crash...er..uh...flash. Yeah, that's it

Figured first I should upgrade BlHeli on the ESC's since there were issues with the oneshot implementation on the older version I was running. Tried to use my new current limiter...only to have the light come on each time I tried to power up the ESC's...what the? Oh wait...yeah...got those LED's on this build...and no easy way to disconnect them. Whoops. Ok, we'll skip the limiter and live dangerously again. Was going to try using an arduino in multi mode to re-flash all 4 at once...but the limiter thing scared me and I got out my 1-wire interface and upgraded them all to 14.2 one at a time. In the process I confirmed my suspicion from back in May that I had disabled damped light and forgot to re-enable it. Explains that! Dang, could have had it flying even better at Flite Fest

With some help from Fujin I was able to get my modifications to the flyingF4 code applied to the new codebase and it built successfully!

Hooked it up...flashed it...and all looked good But when I hooked up a battery to power the ESC's the old USB gremlins I was experiencing came back

Hooking up the battery would crash GCS. And hooking it up with the battery already connected USB wouldn't enumerate.

This has been a major on-going frustration for me with this setup. And the hack of using two USB cables - one to power it through the ST-Link and one for data through the main port always bothered me. But as goofy as the two cable solution I was using seems in the quick start section of the manual STM even suggests the two cable approach:

2. Connect the STM32F4DISCOVERY board to a PC with a USB cable ‘type A to mini-B’
through USB connector CN1 to power the board. Red LED LD2 (PWR) then lights up.
3. Four LEDs between B1 and B2 buttons are blinking.
4. Press user button B1 to enable the ST MEMS sensor, move the board and observe the
four LEDs blinking according to the motion direction and speed. (If you connect a
second USB cable ‘type A to micro-B’ between PC and CN5 connector then the board
is recognized as standard mouse and its motion will also control the PC cursor).

I vented about it on the IRC channel for the new project and a few of the guys there got interested and determined to figure out what was going on. After a slight diversion due to one of them looking at schematics for the F3 discovery instead by mistake the issues became clear...and the news was not good.

My flyingF4 is no longer going to be a flyingF4

What was found is that the second port on the DiscoveryF4 board, the one used for data, can't actually power the board. The VCC line on it is being fed 5v from the discovery board because STM assumed you'd want to use that port as a USB-OTG and the F4 acting as a USB host. Which explains why the ports on my notebooks would shut down when I'd connect this board up while it was already powered. They were just trying to protect themselves.

And the way it's wired there's no good way to disable that. Bleah.

Even worse...it turns out that the way I was powering the board was sending 5v to the 3.3v net! :black_eyed:

You see....I saw this on STM's website about the DiscoveryF4 board:

Board power supply: through USB bus or from an external 5 V supply voltage
External application power supply: 3 V and 5 V

And the same in the manual:

• Board power supply: through USB bus or from an external 5V supply voltage
• External application power supply: 3V and 5V

The power instructions in the manual just say:

4.3 Power supply and power selection
The power supply is provided either by the host PC through the USB cable, or by an
external 5V power supply.
The D1 and D2 diodes protect the 5V and 3V pins from external power supplies:
• 5V and 3V can be used as output power supplies when another application board is
connected to pins P1 and P2.
In this case, the 5V and 3V pins deliver a 5V or 3V power supply and power
consumption must be lower than 100 mA.
• 5V can also be used as input power supplies e.g. when the USB connector is not
connected to the PC.
In this case, the STM32F4DISCOVERY board must be powered by a power supply unit
or by auxiliary equipment complying with standard EN-60950-1: 2006+A11/2009, and
must be Safety Extra Low Voltage (SELV) with limited power capability.[

And that was where I made my mistake. I saw that they said the 3v and 5v pins can be used as outputs...so I did. That's how I powered my GPS and RX. No problem there.

The problem was they never specified where to attach the 5v power supply when not powering it through the st-link connector.

Silly me I assumed that would be the VDD pins and that there would be regulators between there and the 5v/3.3v busses.

Um...no. Last nights studying of the schematics revealed that VDD is tied to the 3.3v buss.

For the past year I've been flying this with the 3.3v F4 chip wired to 5v. I even hooked up my multimeter and confirmed, with 5v on the VDD pins I was seeing 5v on the 3.3v pins


I'm still not sure how they expected to have external 5v applied to the board. I'm guessing either with a USB adapter or through the SWD port based on their mention of D2/D3 protecting things since those are part of the ST-Link portion of the board. I haven't bothered to look at the schematics and figure it out.

Because at this point after running a 3.3v processor at 5v for the past year (miraculously with no magic smoke!) I just can't trust it. Add in the mess with the second USB port and the lack of internal sensors...really this thing is a horrible choice for a flight controller.

The new project is dropping flyingF4 support based on what we learned last night and I supported the decision.

So the flyingF4 knuckle tau is grounded with no brain

But that doesn't mean it's dead for good. It will be back One of the devs has offered to send me a spare sparky board so I can continue testing It's not a 2.0 but it will still be good for testing stuff and I'll finally have a real fully supported target on my test quad (I have the Brain on my hex but I'm not willing to test anything that isn't at least release candidate level of proven on there.)

The guy leading the new group is also convinced he can get Tau's autotune working on F1 targets...so my nighthawk 250 will also be subjected to testing There's no plan to get nav functions working on F1 - just not realistic given the limits of the F1. But he's really convinced he can get autotune working on there and I'm looking forward to testing it and seeing if he can actually pull it off.

So this thread is ending But a new one will be starting when I get that new Sparky board

And more details about the new project once they've made a bit more progress

 

[airhawk]

just found this thread im looking forward to that sparky board

 

[cranialrectosis]

This thread and it's precursor are epic.

I liked my KK2s. Then CyberD recommended the Naze. Then you showed up and started building your own flight controller with an Arduino Mega board. I tried out an MW Pro (horrid board) and then a Naze and now a Sparky2.

But wait, I now have a Brain or two in the mail and have modded my Turnigy 9X and even 'flashed an ESC'.

No, I am no where near building my own flight controller with microwave oven parts. Nor have I successfully built a Theramin out of my old dishwasher.

But I have pushed WAY past my comfort zone and these threads are why.

I just wish Chaos were still here to see it.

 

[jhitesma]

Well, to be fair me building "my own" MW from an arduino was basically just repeating what the MW developers originally did - nothing ground breaking. Same with this, lilvinz was the one who originally build a flyingF4 and shared the instructions - I just followed along.

The one thing I did different was post here about it to share with everyone

Still need to build a theramin one of these days...been on my list WAY too long.

Speaking of modding a Turnigy 9x...just filmed myself doing that last night - rendering as I type. Couldn't pass up picking one up for $22 in the HK sale. It was Mode1, but that was easy to fix and just took a few minutes. I also moved the antenna to the module so the module is removeable which was a bit more time consuming. Tonight I'll probably be flashing open9x on it and installing the backlight. Nothing groundbreaking there for sure...but it's more fun to talk to the camera than myself while working at night

Comfort zones are boring, I hate them If you're not failing big you're not really trying

This new "soldering iron" I'm working on should be interesting....hope to have a post about it later this week. I'm excited about it...has major potential for spectacular failure - but also potential to be depressingly easy

Oh, and in the definitely not failure category...major progress last night from the guys who forked Tau. They got autotune working on a F1 based board Going to dust off the emax 250 and give it a go soon, really hyped about the probability of real autotune coming to F1 boards!

 

[Craftydan]

Oh, and in the definitely not failure category...major progress last night from the guys who forked Tau. They got autotune working on a F1 based board Going to dust off the emax 250 and give it a go soon, really hyped about the probability of real autotune coming to F1 boards!

Odd . . . Autotune has been available on the Tau CC3D image for a while now, and by my impression longer than the fork of the fork -- I'd have expected it would have been in their initial trunk. Is this not the "Real" autotune?

 

[jhitesma]

Odd . . . Autotune has been available on the Tau CC3D image for a while now, and by my impression longer than the fork of the fork -- I'd have expected it would have been in their initial trunk. Is this not the "Real" autotune?

It's been available...but unreliable and keeps getting broken, works one build but not the next. And only worked on CC3D not Naze32 which was added as an official target this past summer.

icee is working on getting it reliable on all F1 targets and increasing the rate it runs at on other targets (where more resources are available) so it will be able to do an even better job.

His test last night was on a small brushed quad running one of those little naze based micro boards with build in DSM and FET's for brushed motors.

There are still some issues, it's still dropping some points. But the queuing he added is helping it keep up enough to actually complete a tune on F1. It's also helping it deal with setups with lower Tau than what the autotune was capable of dealing with in the past.

Still a few days away from beta binaries being released...

 

[jipp]

this is good news. to much negative as of late.. auto tune once perfected or even good enough to get you in a real ball park will be nice i think for everyone.

chris.

 

[Axel Just]

i think you mid like the navio auto pilot

 

[jhitesma]

i think you mid like the navio auto pilot

I'm not a huge fan of the Pi or APM really. If I was going to go for something like that I'd be building a FlyingPi: https://forum.dronin.org/forum/d/20...ght-controller-for-robotics-machine-vision/18

My big issue with Pi is that it's not usually a good fit for the things I see it used for. Either they'd be better done with a more substantial computer and doing them with a pi is frustrating. Or they'd be better done with a less substantial and much cheaper microprocessor and are just done with the pi because someone has one on hand.

Pi's aren't great as a flight computer since Linux isn't a real time OS. NAVIO seems to address this by running the flight firmware on an external processor on the board...though I can't find any details about exactly what processor they're even running. The FlyingPi on the other hand addresses this by using one of the Pi's cores to run the dRonin flight stack on ChibiOS much like dRonin works on simpler flight controllers. Upside of the FlyingPi approach is the shield is much simpler and lower cost, downside is you give up one core on the Pi that can't be used for other things.

The Navio also doesn't appear to be an open design which is important to me for a number of reasons, it runs APM which is open, but the actual board design isn't as far as I can tell. FlyingPi is fully open - in fact the designer doesn't even plan on selling boards himself just releasing the design and letting anyone who wants to make or produce them.

But I'm just overall not a big fan of APM. The structure of the code and the community around it just rub me the wrong way for a long list of reasons.