Ultra budget quad build.

jhitesma

Some guy in the desert
Mentor
Arrrgh. Frustrating evening.

My daughter who was home sick from school today didn't want anything to do with me, just wanted to cuddle with mommy. Well, at least that meant I could spend a bit of time on the quad.

Over lunch I finished re-assembling the frame, remounting the motors and ESC's and basically getting it back together. Once I came home from work I hooked up the RX and powered it up with no props. Everything seems to be working. Then I decided to test the failsafe. Hmmm. Well, that explains the fly away. My failsafe isn't triggering it seems. Throttle is just holding where it was when I turn off my TX. But...it does regain the link very quickly when I turn the TX back on, and at the time of the flyaway I tried turning the TX off and back on a few times while within 100ft of the quad but never regained.

However - I also noticed that if I pull the power to the arduino board while armed and powered up...then the motors stay running. So I'm suspecting that may be what happened and it may not have been the openLRS at fault after all. I've had a few issues with the power wire to the arduino not wanting to stay connected in crashes...but didn't think it could come loose in flight. Now I'm not so sure. Looks like I'm going to modify that connection to make it more secure from here on.

So with that sorted out I was feeling pretty good. Figured I'd upgrade the firmware on my openLRS just to be safe and hook the quad up and see if I couldn't figure out why the failsafe wasn't working - maybe the last time I reflashed the openLRS I goofed and forgot to reset the failsafe.

But before doing that I tried to power up the quad for one more test. Nothing. Not a single light on anything, nor single beep from anything. What? It was working just 10 minutes ago?! Checked a few things with my volt meter and found that the positive battery connection didn't actually connect to anything suddenly....hmmm. Tore the whole thing apart again and sure enough there was the problem, my main battery connection had come loose from the "manifold" (as Mustang calls it) I had made as a power harness. Oddly enough there didn't seem to be ANY solder on the wire...how the heck had it stayed connected for 5 months if I had soldered it that badly? Weird. Tore apart that half of my wiring harness, which gave me an opportunity to clean up my LED wiring and voltage sense wiring which I've been meaning to do anyway. Got it all back together...and found that one wire to my baro had broken right at the board with all the moving around of bits that don't normally get moved around. Grrrrr.

Re-soldered that...put it all back together...powered up...hooked up my telemetry and my app starts beeping instantly with a ton of I2C errors. Hmm, maybe I didn't fix that broken wire as well as I thought I had.

Tore it all apart again...double checked the wiring to the baro and the other sensors...all looks good. Power it up with the quad torn apart...and...no I2C errors! Put it all back together, fired it up...and a pile of I2C errors again :(

Tore it apart AGAIN, but now I'm getting I2C errors no matter what. And just to make things even worse at this point I re-connected the power to my sensors...and missed the connection by one pin...connecting the sensor 3.3v line to the aruino's reset pin, the 5v line to 3.3v supply, and the Gnd to 5v. Oh hell. Fixed that...but unsurprisingly I'm still getting a TON of I2C errors...but intermittently. When I first power it up it's nice and clean...then suddenly the errors start.

Not sure at this point if I fried one or more of my sensors or maybe just damaged my 3.3v/5v LLC.

I'm already thinking about ordering a 10DOF IMU to try and make a DIY Naze so now I'm thinking maybe I should just go ahead and get two and upgrade this to an integrated IMU with a better baro while I'm at it.

Oh...then I went to get on my computer...and once again it's only talking to my local network and refusing to route through my internet connection.

Did I mention in there the 20 minutes my wife took to run to the store to get new cough medicine for our daughter...20 minutes of which I was treated to nothing but screaming and crying because mommy was gone.

Oh...and one other fun thing...on my last test I noticed that the ESC I'm powering the arduino from is getting REALLY hot fast. Which is again leading me to question if there's something about the BEC in these F20's that caused the flyaway ... maybe it overheated and the BEC shut down instead of the wire to the arduino coming loose. That would explain exactly what happened.

Just frustration after frustration after frustration the past few weeks. Was really looking forward to flying the next few days and now it's looking like it won't be until after our Yosemite trip that I'll get to fly since if I need to order new sensors and/or a new Blue ESC so I can go back to the Blue's they won't be here until I head on my trip.

Guess tomorrow I"ll try and wrap up the blunt nose versa and cross my fingers I can shake this curse and just enjoy some airtime.
 

e_lm_70

Senior Member
Long post :eek: .. sorry I may miss few points since I did not follow the full history as well.

Anyhow

Few tips that I think are important:
- Last time I check MultiWii fail safe, I did see that the off-shelf fail safe is not something for me ... apparently fail safe get activated when the PPM or PWM signal are under 900uSec ... I simply did not like it. It is very specific to the type of RX used
- What I did, since I want to have fail safe logic on the control board and not on the RX (for most of usage fail safe on RX is good enough), I did program my FrSky PPM RX to just send "NOTHING" in case of signal lost ... Then I had to add a timer on the PPM RX code in the MultiWii, and this trigger my custom fail safe logic (my logic is : If copter is in mission (my MultiWii does mission since 2.2) ... failsave = multiwii stay in mission ... otherwise failsafe = RTH)
- Always bench test fail safe ... so double check what your RX does in fail safe and what your board does in fail safe.

Second tip.
- If I read correct you have all your ESC BEC cable up in parallel ... this is wrong. You should use only 1 BEC in a copter without servos. So remove the red cable from the socket, and stick it with some tape on the servo wire (don't cut the red line, you never know, you may need it again) ... and use only 1 BEC. Having multiple BEC in parallel .. each other will fight with the others ... and I did test that as result in stand by using 4 BEC in parallel my copter did waste 100 or 200mA of current ... this current wasted goes into heat and can wear your ESC-BEC.

Tchuss

e_lm_70

ps: DIY Naze is cool .. still personally I feel more at home on ATmega multiwii ... for compile Naze32 FW (Baseflight) I have to run Lubuntu as virtual machine on my Win8 ... use VI for edit the code changes :black_eyed: ... and SCP for transfer back the HEX on Win8 for then flesh it using STM tool ... on Arduino .. 1 click .. and I'm done :cool: ... people call Arduino also Tarduino or FaArTuino ... because it is Dummy Proof ... but be Dummy Proof is an advantage ... having to handle unnecessarily complicated interfaces or procedure, does just limit the people that can access the technology but does not make it better. In other words ... the CPU power of an ATmega2560 is enough for control a copter, and 4 serial and 256k make it even better then a simple STM32 chip.
Still DIY Naze32 is cool .. since not everybody can do it ;) .. at least for now .. but we can make it dummy proof too ... but never as easy as Arduino MultiWii
 

jhitesma

Some guy in the desert
Mentor
I just don't know when to stop.

After posting that I figured...well...why not try and update the firmware on the openLRS should just take a few minutes. Fired up the soldering iron and reconfigured my serial cable for 3.3v operation...double checked it with my volt meter before hooking it up...and...the openLRSng config program is just crashing chrome today when trying to connect :(

Grrr.

Decided to do another quick test and hooked the quad up over USB to get a good look at what was going on. I've isolated the sensor issues...it's the mag sensor. The I2C errors start when the mag suddenly stops responding. I've never gotten good results from this mag sensor so I'm wondering if maybe I just got a bum chip. Or maybe I fried it tonight with my miswiring. Either way it's a non-critical sensor as I can fly acro/angle/horizon without it...just no GPS and headlock which I don't use very often anyway. So I may be able to fly this weekend after all.

Tomorrow I'll take a closer look at the wiring to the mag sensor to see if there's a simple wiring issue. It's highly possible that one of the wires to it broke as well when I moved my homebrewed IMU around today. That's the first time any of those sensors have been touched since I moved them inside the quad and the wires to them are just IDE ribbon cable which is very delicate - so I could easily have broken a wire and not noticed it.

Too late to mess with tonight though. I'll deal with it tomorrow.

Oh - and the new SimonK flashing program from ctn looks really neat...may have to whip up a USB linker and give that a try to experiment with I see it has a simple way to enable motor braking and beacon which I didn't realize SimonK even had.

On the upside the ESC powering the arduino isn't super hot now...not sure why it got so hot so fast earlier tonight...one more thing to let my brain work on while I sleep tonight I guess.

Time to call it a day...hopefully tomorrow won't be so filled with frustrations.
 

jhitesma

Some guy in the desert
Mentor
Since I left the quad in pieces last night I took a quick look at it before work this morning. And as I suspected there was a broken wire to the mag sensor! Was hard to spot since it was broken right at the board and the wire was in the middle of a bundle so it was staying in position even though it wasn't attached. That's why it worked sometimes but not others - the wire would sometimes make contact but with some vibrations/bumps would loose it. Hooray!

So now the big issue is figuring out what's up with my failsafe.

I did a quick test, I tried pulling the PPM wire from my RX to the FC while it was armed and mid-throttle with no props. I expected that removing the PPM signal would trigger the failsafe...that's what it's supposed to do afterall. But instead nothing happened. All the RX values in the GUI stayed the same! They should have all fallen to zero with no signal. So it appears that the issue is with MW not detecting the loss of PPM signal and going into failsafe like it should. Going to dig through my config later today and see if it's something I have misconfigured or if it's something that's just broken in MW2.3
 

e_lm_70

Senior Member
I did wrote you before ... the fail safe procedure in MultiWii is not good .. in baseflight is not good as well too.

The firmware assume that in absence of signal a PWM under 950uSec is send out.
This will not cover most of the RX
This will not cover a failure of the PPM link from RX to FC

I did end up hacking my own solution on MW2.2 ...

I think it should be visible in the RAR/ZIP file that I did upload on multiwii forum, under MultiWii does UAV
 

jhitesma

Some guy in the desert
Mentor
Yeah, I did some searching today and took a peek at the code and couldn't find anything that would indicate that MW 2.3 failsafe actually works with PPM input. I figured I was just missing something in the code...but a number of other people have had the same issue it seems and you're confirming it as well.

I did uncomment failsafe in my config.h and reflashed - but with failsafe enabled I can't get the quad to arm. It seems to be going into failsafe instantly - probably because I'm using PPM so there's no PWM signal. I tried lengthening the time before it goes into failsafe but it's still going info failsafe even with the RX powered up before the arduino.

I found your code and will take a look at it to see if I can't do something to get failsafe working on the FC in the next few days as I really don't want to fly without it now. I really thought I had it enabled...that must have been before I switched to PPM and I just forgot about it since.

I'll still try to get my openLRS flashed to the latest ng and confirm my failsafe setup in there...but I still want a proper FC failsafe in case the RX was the cause of my flyaway. But for some reason the config program just keeps crashing chrome on my normal computer. I'll have to try it on my nicer computer or my linux notebook tonight.
 

jhitesma

Some guy in the desert
Mentor
Oh boy...now I'm down the rabbit hole.

Looked at e_lm_70's code...but the failsafe stuff I could find looks the same. I haven't really looked at the 2.2 code though and it's a lot different than the 2.3 code which I'm only slightly familiar with and I don't really want to go back to 2.2....so didn't gain too much through that little exercise.

Instead I decided to bite the bullet and finally setup a real dev environment and pull the latest sources straight from the SVN (I'd prefer the git but apparently they still use svn for the main development so I'll start from that.) and setup Eclipse.

I've used Eclipse before, when I wrote myself an Android game (Which I really need to spend an evening or two on so I can finally release it...super close but need to cleanup a few menus and ran into a problem with a custom font) I used Eclipse and started to learn to like it. I've never been a fan of the arduino IDE - it does make things easy with Arduinos...but it's just a lackluster IDE for real development.

So I followed the instructions to setup an Eclipse environment for MultiWii. Oh man...so much better than Arduino...except...I can't get the final step working to actually upload to the board once the code is compiled. Just getting timeouts from AVR dude. I've done some searching and it looks like I should have things setup right...but no luck. Will have to come back to that later.

Instead I went back into Arduino and tried to tweak the failsafe code so it can't trigger unless the board is armed. But I'm still not convinced I understand what's going on with the failsafe code well enough to have done that properly...still I gave it a try. (Basically I found where the failsafeCnt is incremented and add an If around it so it's only incremented when armed) loaded that to my board...and...hey I could finally arm my quad with failsafe enabled!

But...I couldn't disarm. And at full throttle I shut down my TX....and the motor speed didn't drop. So apparently something still wasn't working right yet with failsafe. Went to do another test...and suddenly I can't arm. Then I noticed why...suddenly my RX signals are all over the place and just going crazy. Something isn't right.....

So I undid my change, reflashed the code...tried again...and I'm still getting RC signals all over the place. So something seems to have gone crazy with my TX/RX setup. And I'm not about to go tweaking with that since I still can't get the config program to connect without crashing.

Arrrgh, frustrating end to a frustrating week. Hope I have better luck tomorrow. If I could at least figure out the settings to get AVRdude working from in Eclipse at least I could be done with Arduino and have an easier time getting through tracing the failsafe code.

Or if I could at least get the configurator working for my openLRSng......
 

e_lm_70

Senior Member
Yes .., Oh Boy ...

I know how you feel in the days that all goes wrong ...

It is enough a little dummy forgetting or micro mistake ... for screw up everything.

Spend some qulity time on something else ... and then you can get back on the project wiser.

Hard to suggest from far away what you may do for get better result.

If you have a KK2 board around, with stock FW ... you can use it as RX PPM tester ... it is a nice and simple check for validate your RX

About openLRSng ... mine does connect all time to the crome apps ... as check ... at boot up the serial port does print some debug stuffs ... this for check the serial port ... anyhow .. you must use a 3.3v serial adapter
(Note, only TX get connected to the PC, RX is connected to PC via the TX wireless)

Have a nice weekend ... all is set for me to go to the field and video maiden my K2.0 with GPS and my DIY Naze32 ... still ... if there are too many people there, due to the ongoing event .. I may have to find a different place for the videos
 

jhitesma

Some guy in the desert
Mentor
No spare KK2 board. But I did pull out the oscilloscope and took at look at the PPM output from the RX and it looks good.

But the MW is just reporting garbage with constantly changing values.

Figured maybe I messed something up in RX.cpp and didn't notice it...so unpacked a clean copy of MW2.3, copied over my conf.h without failsafe which was all working fine a few days ago. Compiled, uploaded...and I'm still getting garbage for my RC signals.

Grrrr.

May break down and order an FTDI based serial adapter so I can at least try reflashing my LRS modules...still can't figure out why it keeps crashing chrome with my CP2101 adapter which has always worked fine in the past.

Half tempted to just rip the openLRS off for now and go back to the ugly 9x module with it's giant bundle of wires. Probably will just to help determine if the issue is the openLRS or the controller.

Just frustrating when the thing I rely on to help alleviate my frustrations from life starts becoming frustrating itself. I'd spend some time on the blunt nose versa...but I'm not going to have time to get out to fly it this weekend. The quad I can fly in a smaller area so I don't need as much time. And honestly by the time I finished mounting everything in the Versa I wouldn't have time to fly it even at one of my closer options. Hmmm...it's calm enough maybe I can toss the X1 in the air for a bit to get my fix....
 

jhitesma

Some guy in the desert
Mentor
Well, went ahead and pulled off the openLRS and put my stripped down 9x RX back on. Tweaked my config.h to disable PPM (and for now failsafe just to keep things simple) cleared the EEPROM, reflashed, fired it all up...and nothing. No RX values in the config.

Pulled the throttle channel pin and connected it straight to the signal pin for one of the motors...confirmed that the RX is functioning.

But for some reason my FC is just totally ignoring the inputs.

Starting to think something on this mega board may have failed. It's hard a hard life and been through a lot of crashes and is missing a few bits in the power circuit (they aren't used the way I'm powering it.) But with PPM and PWM giving either no data or garbage data I'm really starting to think the issue is with my board and not with my TX/RX setup.

Don't really want to pony up for yet another big heavy arduino....but don't want to wait for RTFQ to ship a MWPro or pay $35+shipping for one. Don't want to drop down to a pro-mini and give up all my UARTS either. So probably going to cough up the cash for a new mega - I can always justify it since I use them for more than just flight controllers....

Just bummed because I'm dying to fly on these new motors and it looks like my last chance is fading. Winds are predicted to be 20-30 sustained tomorrow and are already starting to pick up so my window of calm air is rapidly dissipating.

At least my daughter is feeling better (though now she's wired and driving me crazy) and we've got a birthday party for one of her friends this afternoon. So hopefully that will keep my mind off this mess for a few hours.
 

jhitesma

Some guy in the desert
Mentor
Well, bit of progress after the party last night.

Figured out why my PWM setup wasn't working. I apparently went braindead and got the analog and digital pins mixed up on the mega. Once I moved the RX over to the correct analog pins my PWM signal was working just fine. Doh!

But I still can't get failsafe to work. I've confirmed that my endpoints are at 1000 so all my RX channels are reading 1000 or higher - but the darn thing is still going into failsafe as soon as the timer runs up after starting up before it's armed (heck before the gyro even finishes calibrating and it's even possible to arm.) And this is with PWM.

So I'm seeing the same issue with PWM and PPM (though I still can't use my PPM as I'm just getting random noise with that hooked up even though the output looks great on my scope.) where failsafe kicks in even though it shouldn't be. Won't have much time to keep digging on it today, and even if I did the crazy winds are back so no test flights.

I did order a replacement Mega board but now it looks like I don't need it so I'll have it as a spare or for another project. Bummer is that means it's going to be another week or two before I can get a STM32 board to try and brew up my own version of a Naze. Though I've been reading up on that and have found that apparently Naze32 doesn't play well with 440mhz LRS systems due to the clock frequency it runs at causing harmonics. So if I do go Naze I'll have to either pick my channels very carefully or go back to my 2.4ghz system. I should have a PPM capable flysky RX for my 9x shortly though as the RF modules I ordered left LA on Friday so I expect them to arrive on Monday, and the avr chips I got to go with them showed up on Thursday. I'll still need to dig up a few discreet components to glue it all together with but that's easy enough and I'm pretty sure I've got the right bits on hand.

But after a few weeks of hacking more than flying I'm really itching to do some flying!

Fingers crossed that tonight I can figure out this failsafe issue and get it going again. I did also get eclipse working for development so that makes tracing the code a lot easier. Turns out that the version of avrdude included in arduino has been hacked to send the required reset to the board to initiate programming while the stock version that comes with winavr (used by Eclipse) doesn't do that. So I have to manually reset the board as I start the upload from Eclipse. Minor hassle, and could be fully corrected by using the arduino version of avrdude...but I'm willing to just do the manual reset for now.
 

jhitesma

Some guy in the desert
Mentor
Huzzah! Failsafe is working. I had to drop the sensitivity from the default 980 some down to 900 and now it doesn't trigger.

I'm guessing something is goofy in the way MW interperts RC values as the GUI was never showing anything under 1000 but it was still triggering the failsafe even with the failsafe value set to 984 or whatever it was. With it dropped to 900 it does't trigger unless I shut off the TX now!

So it's working with my old 9x RX. Still not sure why my PPM on my openLRS is all mucked up. Need to figure out why chrome keeps crashing trying to configure the openLRS next.

But I got to fly half a pack...was too windy to do much more.
 

jhitesma

Some guy in the desert
Mentor
I just wish I could make it a little less text heavy :) Photos of code editors don't really help liven things up on these kinds of issues :)

I did do a quick video of the issue though and will be uploading it later today.

Really itching to figure out what's up with my LRS setup...but we just had a nice mothers day brunch and mommy has to work this afternoon so won't have time until after the little ones bedtime. And by then I'll probably be too tired to dig into it.

Still, was great to have a little flight...even if it was frustratingly short and white knuckle due to just being a matter of fighting the wind with the quad at 45 degrees just to stay in one spot :D (And it's even windier now!)
 

Tritium

Amateur Extra Class K5TWM
There is a fix I saw somewhere (in the last day or 3) for the Naze LRS harmonic issues. Unfortunately I do not know where I saw it.

Thurmond
 

jhitesma

Some guy in the desert
Mentor
I can think of a couple of possible fixes. Filters can do a lot. And running the board at a different frequency will shift the harmonics as well (but is non trivial since a good bit of the code is timing related and would have to be changed.)

I only heard of the issues because there was talk in the openLRSng thread on RCGroups about a stm32 based openLRS module - and their plan is to run it at 80mhz instead of 72mhz like the Naze (on 72mhz the 6th harmonic lands on 432MHz while at 80mhz you get harmonics on 400 and 480 leaving a nice gap where LRS systems operate.)
 

jhitesma

Some guy in the desert
Mentor
Alright, let's make up for the lack of photos on these latest frustrations with a few videos!

Sadly not videos of flying action :(

First up...documenting my utter and complete frustration at getting failsafe working:


Sorry for the shaky camera work, trying to demo/narrate/shoot all by myself is tricky.

What you can't see in this video is what finally let me to realize what the problem was. And that is that when I lifted the throttle up from 1000 to 1500 while it was unarmed and locked in angle mode due to failsafe kicking in...angle would suddenly shut off leading me to believe that failsafe had turned off. Which was what let me to try dropping the failsafe threshold down to 900 which finally solved the issue!

So trying to document my frustration brought me a solution to it! Woo Hoo!

Two more videos (both equally unedited but at least shot from a tripod) to follow when they finish uploading. You even get to hear motors turn and see props spin in them - but they're tests with the quad tied down to a concrete bench trying to get some readings off the angel motors with my wattmeter.
 

jhitesma

Some guy in the desert
Mentor
Video #2. A taste of the kind of frustration my week has seen in never ending spades.

The wind had died down, but I didn't have time to get to the park and didn't really trust the quad for a flight in the front yard yet (trying to get my confidence in it back after that flyaway is proving difficult.) So I figured I'd strap it down and do a few power tests with my watt meter to see how many amps the new motors are actually pulling. Things did NOT go as I had hoped:


What I eventually determined was going on was just out of the frame. The quad was tied to a concrete bench in my backyard with a length of rope and a bungie cord. It was pretty snug but could shift a little in it's ties. And it turned out that was the problem. When I'd throttle up it would shift and the bungie would knock the power wires to the arduino loose, causing it to shift back and letting the wires make contact again.

Finally on the last test in this video I noticed that the board appeared to be resetting itself, and when I went to unstrap it I realized that the bungie was hitting the power wires.

So I ditched the bungie and tied it down with just the bit of rope and gave it another go.....
 

jhitesma

Some guy in the desert
Mentor
And finally my big "success" of the weekend:


With the quad tied down in a way that couldn't bump any of the wires I was able to do some power tests.

Looks like the brand new 25-50c nanotech is able to deliver more power than my 6 month old 40c zippy's. But my 25c 1500 Zippy's are no longer usable with these motors. (which a bit of math before that test would have told me once I saw the amp draw I was getting on the bigger zippy's and the nanotech.)

The highest I was able to pull was just under 50a at full throttle which works out to 12.5a per motor/ESC well within the 20a rating of the ESC's and motors. In fact it has me wondering if I may be able to pull off 9" props with these motors...it may be pushing it but I do have one 9" prop laying around so next time I knock a motor off I may hook it to a test stand and give it a go with the 9" just to see what kind of numbers I get. I suspect it will be too close to the limits for my tastes but probably worth the time to test.

The bummer about this test it that I now have 2 bats that aren't usable in this quad anymore, and it looks like I'm going to have to carve out some of my budget for a few newer packs. Wondering if I can step up to a 3000mah and get a bit more flight time out of it. Been thinking about picking up a compact 3000 or two for the versa so I might be able to justify it....

Oh - and I did do another quick test flight (but no video as it was getting too dark) as once I was done testing the wind had finally abated and it was dead calm out. But really it was just a tease. I'm still dying to get out to the park and really open it up with the new motors! It's just so much quieter, smoother and more stable with these angels! Flew like a dream in the backyard but I was really itching to try some acro and my yard is just a bit too small for that. I've done flips and rolls in the backyard...but I'm not about to attempt them on new motors until I've got a pack or two under my belt at the park to get used to them :D

Looks like my wife has Tuesday off so I may be able to hit the park after work then and finally get to try these out.

In the meantime....gotta dig in on my openLRS and why I can't update it and why the PPM signal isn't being read correctly anymore!
 

Tritium

Amateur Extra Class K5TWM
I can think of a couple of possible fixes. Filters can do a lot. And running the board at a different frequency will shift the harmonics as well (but is non trivial since a good bit of the code is timing related and would have to be changed.)

I only heard of the issues because there was talk in the openLRSng thread on RCGroups about a stm32 based openLRS module - and their plan is to run it at 80mhz instead of 72mhz like the Naze (on 72mhz the 6th harmonic lands on 432MHz while at 80mhz you get harmonics on 400 and 480 leaving a nice gap where LRS systems operate.)

I do now remember since you said clock speed that it was a patch that would allow the Naze to run at a higher clock speed. I will post a link if I can ever find it again.

Thurmond