former quad, converting to hex with a custom frame.

Basically after building a custom frame and porting everything over, i now am having some odd problems that arent making sense to me. Im using APM 2.0, a stock pdb, motors, escs (flashed to tgy.hex) 12x3.8

In short,

1. motor rotation is correct ( CW/CCW) also conforms to DIY diagram for heX

2. Controller authority appears incorrect when attempting lift-off ( edit- 5-6 were reversed in loom - have not tested liftoff)

3. Not all of the motors spin when testing from CLI, but all spin when i throttle up in a test. 5 and 3 fail in CLI test.

4. some motors do not spin at same speed when spinning up. Say for instance throttle is at 5%, then two fo the six do not appear to rotate at same speed.  300rpm vs 100rpm One or more occasionally lag on the startup as well.

Ive connected all motors according to their numeric order but something is a little screwy here. Also to whoever does set editing, the harness has different colors than the docs... Plus itd be nice to have a whole loom with all different colors for knuckleheads like me.

 Any thoughts? In particular about the failures in CLI vs the flight mode? ( FWIW- CLI frame and mode match GUI)



P.S. Pic of custom hex frame w/out cover, note FPV cam mount and lower gimbal mount

Views: 444


Reply to This

Replies to This Discussion

Has anyone seen this behavior before? could it be due to brownout or is this an APM or ESC issue?

Have the ESC been calibrated? The spinning up at various rates sounds like ESC calibration to me.

Good thought, but ive flashed all of the ESCs with the tgy.hex custom esc code. This ROM is preferable, among many reasons, due to the redaction of the low voltage cutoff functions built into the original ROM. Further, it also reduces motor noise, coffee grinder-ing, and makes your throws absolute thus eliminating that irksome ESC calibration process. It also lifts, separates and turns you into a nine-year old Hindu boy.

Not to say its not possible that the ESCs are screwy, but the fact that the CLI test doesnt work on all motors seems more significant to me.

I'm not familiar with that ESC firmware but according to the project the throttle response can still be calibrated.

Not sure what to say about the CLI test, maybe a developer or someone more familiar with the ArduCopter firmware will have some insight on that one.

Interesting,and thank you.  I wasnt hip to that before- never was needed on my quad so i didnt research further.

Hmm- Ill have to try that and see what i get other than screwy stuff, whiich is about all i have now.

Ive been hoping for some dev input, maybe someone will have a thought or two this weekend.

Luke - this may be of interest to you w regards to the ESC flashing- 

Part of the objective of flashing the esc was to set all throttle controls to hard limits, thereby never needing to calibrate every single time as i was having to do

Depending on the design of the ESC they can be inherently inconsistent and require calibration to perform in unison. I'm not sure if that's the cause of the issues you're experiencing but I wouldn't rule it out until you've tried calibrating all of the ESC. Either way it doesn't affect my flying so do whatever pleases you, just trying to help. Good luck with it.

The default range is set at the top of tgy.asm (stop at 1060us, full throttle at 1860us) and is not changed if no new value is saved to the EEPROM. However, boards without external oscillators (typically those which use tgy.hex) must use the internal RC oscillator on the Atmega8, which may be off by 5% - 10% between each board, and will also drift by 10% or more over a 40 degree Celsius temperature range. This can cause throttle differences between boards if not calibrated, and issues arming the ESC, particularly in cold environments.

Bart, I'm using 24 ESCs with rewritten (SimonK) firmware on 5 different machines - 3 quads and two hexas - and after reprogramming, the first step was calibrating each one.

TBH, I've never tried to lift a multi with uncalibrated ESCs, but otherwise they all work superb.

Hi guys, thanks for the input- It was my understanding that calibration didnt need to be done after the flash, which was obviously incorrect and may indeed account for all of my issues ( poor socialization and piloting skills notwithstanding. Crashing is where Im a real viking..)

I will calibrate their little mosfets off and report back, but a few questions in the interim:

1. I still find it odd that the CLI setup/motors test fails on some channels though. Is it conceivable that those two ESCs are in a state of partial failure, perhaps not returning a handshake to the APM? I would think it was simply a work/fail situation even in the case of incorrectly set fuses or the like and almost certainly in the case of component failure. Dont know enough about the programming to hazard a guess, though two simultaneous instances of a rarity seem unlikely.

2. Para: How often do your birds require ESC calibration? Id managed 40+ flights with my quad after flashing, sans calibration. That being said, throttle  was always pretty tempermental and never appeared to have the glossy smooth flights that id seen from so many others. I also have the simonK firmware and cant tell if thats the same as the open source project Luke cited, or a separate one.

3. Also, having lost a few escs in this process, what conditions would kill or brick an ESC? Im obviously doing something to kill them but cant really explain it to my satisfaction.


Thanks for help and interest


No doubt it may have helped, but as of now, calibration no worky for this problem. I am gonna swap out the ESCs with new ones and see more. It did sync some discrepancies in the other motors responsiveness, however. THe two motors that respond slowly ARE the onew which fail in the CLI motors test as well. More soon



two totally new ESCs, same issue. MUltiple calibrations.

No worky

no se puede

Im gonna check the continuity in the signal wires AGAIN and test the ESCs direct wired to the APM for confirmation.

and again- no joy.

It appears 2 channels are dead on the APM. Spontaneously.

Now lets see how responsive management is to providing an RMA.

Of course i can see problems with that in the case of crashes etc, but no crashes here. Any DEVs or MODs want to weigh in on this?

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service