V3.4.5 - Motor #4 Anomaly: Fails to spin up when armed

ArduCopter Copter 3.4
1

I have a little conundrum with my Pixhack v2.81… (this is a testbed for learning and experimenting with ArduPilot based systems… Pixhawk 2 will be on it’s way shortly after initial testing for my day to day rig)

When I load the Quad X firmware (I’ve tried 3.4.5 as well as 3.3.1 now) Motor #4 won’t spin up on arm or during motor test. A, B, and C need to be set at a minimum of 6% to spin up, which is what I expected after reading through the “Setting Motor Range” section of the ardupilot.org site.

There was a list of things to test (Courtesy of TheQuestor, srbell, slimething, and Mr.Jagger on RCGroups forums) which I worked through to determine whether my #4 pin header has a hardware issue or if it is a firmware issue. First I tried the older version of the QuadX firmware, no dice, same behavior. I then took the case apart to see if there was a hardware issue, but everything looked perfectly fine to me. I then put everything back together, hooked everything back up and loaded the 3.4.5 OctoX firmware. I left the four motors wired on pins 1, 2, 3, 4 as a quad and tried the motor test (as was suggested in the other forum). All 4 motors run up at adjusted 8% test throttle. disconnected from MP and armed the copter, all was as it should be (expect that I had OctoX firmware loaded on a Quad setup).

After this success, I reloaded the QuadX 3.4.5 firmware and back to square 1 I went. My thought is that since motor D worked in the OctoX firmware that this is not a hardware issue with the Pixhack. (I know it is not a genuine Hawk, but if testing proves out, that will change.)

I have also wiped and formatted the SD (after backing up of course) for a fresh install and received the same results.

QuadX = Motors 1-3 spin up and functions normally… Motor 4, no response
OctoX = All four motor spin up and react function normally

After posting my findings on RCGroups, I was directed here for deeper analysis of the issue, and advised to upload log files of each setup to be analysed (which I have done) none of the parameters seem too far off, as this is my first ArduPilot adventure, I really don’t know how much difference is or isn’t allowed in the PWM settings) If I could get some guidance on where to look and what possible configuration and/or wiring changes may need to be made, I would be greatly appreciative! If pictures of anything in particular will help anyone, I will be happy to upload them if you let me know what you want to see. Sorry for the coffee table book I just wrote, but I like to attempt resolving problems myself based on other’s similar issues before I add to a thread, and to provide as much information the first time around so there isn’t so much back and forth for everyone to read through.

2017-03-13 20-02-31.zip (2.7 MB)2017-03-13 22-39-12.zip (856.8 KB)

2

Hi Joshua.I’ve had a look at your log ( the first one didn’t help but the second one has motor outputs showing ) and find all four outputs are showing a proper value.I’ve posted on RCGroups what I can see and a couple of thoughts but barring connection problems I can’t see a problem in the log.I’m not good enough to check the mapping in the firmware so that’s why I thought it would be an idea to ask if anyone with more in depth knowledge could have a quick look to see that the channels are actually working in the firmware.

Was the second log the one with the octo firmware?

Strange one.

3

The first log had no outputs.
The second log does show outputs.
This was a ground test with no props by the figures.
All outputs are operating as intended following the throttle input.

Screen Shot 2017-03-15 at 5.09.53 am.png2238×829 126 KB

Have you tested the motor and the esc?
Try swapping the connections around.
Motor #4 won’t work so have you tried plugging it into #3?

4

Mike, Thank you very much for your reply. You are correct that this was a bench test with no props. I have swapped the motor/ESC to #2 output in the past and confirmed the setup to functioning. The motor/esc will also work in the current #4 position when loaded with the OctaX firmware without changing anything else…

I was speaking with Jagger earlier today about his post above and will be inspecting the wiring and all connections this evening when I get back to my bench per that discussion.

I will also load the OctaX firmware again tonight and share a log similar to the second one in the previous post for comparison. That is the single most confusing part for me thus far. I wouldn’t think there is that much difference between the mapping for #4 on the Quad vs. the Octa firmware, but I honestly have no basis for comparison, nor the depth of knowledge in programming or coding required to actually know that for sure.

5

I think maybe I found something? I powered the copter and was checking voltage consistency everywhere, PDB, ESC, signal at the esc end and FC end of the connections. When powered but not armed or throttle given, all of the ESC signal to ground were showing 3.3v everywhere else was consistent as well. Once the copter was armed and idling at 10% throttle, those same readings on connections 1-3 read .22v. Connection #4 was reading .10 at the esc and FC pins. Any ideas what that could mean other than not enough signal to trigger the ESC to power up the motor…?

6

Just an off the cuff experiment, why not try 3.2.1 which is the last firmware for the 8bit processors.
It’s just a thought.
If it does work then there may be an issue with the quad firmware and the Pixhack.
Not sure why the Octo would work though.

7

That’s an interesting point Mike.I’ve been running a couple of Pixhacks but only on a hex.Maybe I’ll rip out my Pixraptor and replace it with a Hack to see if I can replicate this.

Good idea with the 3.2.1.

8

Getting ready to load the v3.2.1 firmware and give that a go… a couple questions came to mind out of curiosity though. Would loading the APM 2.5 firmware make a difference versus the PX4 version? Also, would the retracts and/or gimbal tilt connections on pins 7 and 8 cause any interferences that may be leading to this issue with (now3.4.6)? Only signal and ground are connected for those two as the retracts are powered independently as is the gimbal.

I will also upload one of the OctaX logs from last night (v3.4.6 - all motors worked perfectly) shortly as well.

9

v3.2.1 is a no-go. Acted just the same as the v3.4.6 firmware as far as the motors are concerned.

Below are the latest OctaX and QuadX logs from the last couple of nights.

I’m at a complete loss here. I want to rip this thing out and order a PixHawk 2 to replace it, but I couldn’t in good conscience sell it to anyone else to fund the new replacement! :dizzy_face: I’ll start combing through the logs tomorrow to see if I can tell what the difference in the RC out signal is between the two firmwares. I don’t even know where to start asking about whether one motor output is tied to or references another in the coding, or if so, how would it effect the output? Ugh… nuf for tonight.

BTW, Thank you both very much for your help with this! You’ve been extremely helpful and guided in the right directions for troubleshooting and I really do appreciate it. Thank you

2017-03-17 v3-4-6 QuadX.zip (160.5 KB)
2017-03-16 v3-4-6 OctaX.zip (642.5 KB)

10

Both logs show RCOUT on all motor channels following RCIN/Ch3.
When you have Octo loaded have you tried moving the motor connections to pins 5-8 to see if they all operate?

Screen Shot 2017-03-19 at 5.58.56 am.png2424×1332 546 KB

I still think it is a connection problem.
I had an intermittent motor connection once that was hard to find.
It turned out to be the wire in the ESC signal line had broken inside the insulation at the plug.
Push the plug in and it would sometimes work until it was pulled on or moved.

Have you had a look with an eye glass at the pins on the board?
Is there contamination?
You haven’t mentioned whether another motor/ESC connected to #4 works?

11

Mike,
I have swapped motors 4 & 2 at the FC to check that the Motor and ESC were not faulty. Motor/ESC from #2 did not work when connected to output #4. Moto/ESC combo from #4 did function when connected to output #2. This told me that the motor/ESC #4 were indeed good.

I did inspect the pins on the board when I pulled it from the case after the first failed test (to check for two other hardware issues that had been mentioned in the RC Groups forum) and everything was clean as a whistle. No degredation of the pins finish or other foriegn contaminents were present.

I will use the multimeter to check the resistance through each leg of the ESC signal wires and visually inspect the insulation on all of the wires too, as they were brought over from another build (still flying til the day I started this build) and could’ve been nicked or pinched at some point in the build process…

As for pins 5-8 working with Octa firmware, I can say for certain the 7 and 8 do in fact work. I forgot to unplug the retracts and gimbal tilt connections the last time I loaded it and when I armed the motors the retracts did their thing involuntarily and the camera attempted to wrap itself around its axis a time of two before I could get the connections free.

I tested the voltages coming from the FC pins at the board during one of the many spin up tests (very, VERY carefully!) I tested prior to arming and all signals at all pins matched identical. Once armed, I saw an output voltage on the signal pin of .22v on 1-3 but only .10v on #4 at a steady 5-10%, just above idle throttle. Just enough to keep them from disarming, but not a dramatic rpm. I’m sure that has something to do with it, though, I haven’t the foggiest what it might be.

EDIT #1: Thinking out loud - Bad component on the board ahead of the pinouts (if there are any?) since the board says its outputting equal signals across the pins, but the actual output varies? Though, if that were the case, it would show up every time no matter what firmware or motor set was connected wouldn’t it?

Octa signals at the FC pins all matched prior to arming and during the same spinup as above within .01v.

Off to inspect the wires!

12

This has to be a bug in the software.
Reason:
Motor and ESC tested and found to be working.
Quad code loaded and motor #4 does not work
Octo code loaded and motor #4 does work

That removes the possibility of it being a component on the board as motor #4 would always not work.

Have you tried loading the PX4 firmware stack?
QGroundControl is probably the easiest way to do this.
In the firmware upload it has the option of Ardupilot or PX4

If the PX4 works then there is definitely a bug in the firmware so the next step is:
Go to Github and lodge a ticket with reference to this forum post.
But first check that the pixhack board has not had issues posted for it in the open issues area.

13

I don’t think we can conclude it’s a bug in the software at least not a simple one. Considering how long AC3.4.x has been out, there must be many many Quad and OctaQuad users who have successfully used the software.

For example, another possible hardware failure that might fit with the evidence is that the motor output from one of the higher channel (i.e. 5 ~ 8) is somehow appearing on the ch4 pins. I think Joshua has found the motor spins with the OctaX firmware but not that it spins at the correct level.

Joshua, could you try these things out:

  • do you have a buzzer and safety switch attached to the controller? if not, could you attach them? In particular I’m interested to know if the I/O board’s firmware is being loaded properly as part of the firmware update. The way to know is that after a firmware upload it will play a happy-ish sounding tone. If it fails it plays 3 solid notes after a firmware upload. It’s possible to force the I/O board’s firmware to update by holding down the safety switch and then power the board (by plugging in a USB cable or attaching the battery)
  • disable the landing gear by setting CH7_OPT to zero
  • disable the camera gimbal by setting MNT_TYPE to zero (and reboot the board)
  • load AC3.4.6 OctaQuad firmware onto the board, and use the MP’s Initial Setup >> Optional Hardware >> Motor Test page to check when motor #4 begins spinning. Set the “Throttle %” to 10% and it should spin when “Test motor D” is pressed. If it spins when another button is pressed, please tell me which button it was.
  • load AC3.4.6 Quad firmware onto the board, and use the MP’s Initial Setup >> Optional Hardware >> Motor Test page to check when motor #4 begins spinning. It should be when “Test motor B” is pressed but based on previous tests it probably won’t spin.

By the way, the AHRS_ORIENT parameter is set to “4” meaning the board is facing backwards on the vehicle. This is intentional of course? This shouldn’t have anything to do with this problem.

14

I’ve fried one of my Pixhacks but have another operating the Tarot 680.When I get back from my chaufferrng duties this afternoon I’ll load a quad firmware and see if I can replicate this on a known good board/good motors.

15

I finally got around to trying this out and can report that all four motors spun up with motor test, again pointing to something other than a firmware problem.Tested on a Pixhack and a Tarot 680 hex with quad firmware 3.4.6.This is using a genuine CUAV Pixhack v 2.83 in the metal case and not a clone plastic one.

16

Sorry I’ve been a bit MIA this week guys… getting ready to test the items Randy indicated… will post more once those tests are completed… thank you all again for the help!

Update #1 - No tones whatsoever upon uploading of the firmware (octaquad currently).

Tried the safety switch then power FC and still nothing… waited a minute or so and still nothing from the safety switch/buzzer.

Did motor test - Motor A spins up at 10% no other motors will spin up when individually selected… when “Test All Motors” is selected, all four motors spin up. Side note, when selecting individual motors the first time around I get a click or ping noise from motor D when selecting C, D, and H as if it is getting a momentary signal to spin, but doesn’t. If I select any of the motors again, there is no reaction at all from them, however “A” still spins up as intended and test all motors still spins all 4 motors…

Further observation during motor test… when “Test all in sequence” is selected, the test ends after Motor A. No other motors are signalled by the FC. The multicolored LEDs flash during Motor A and then return to the quickly flashing green LED state.

17

I’ve never got “test all motors in sequence” to work on any copter or firmware release.“Test all motors” always spins them all.

A fresh ESC calibration may help.Four different motors and ESCs would be a help too for diagnosis.

And fresh USB leads for flashing the firmware too.I’ve lost count of how many corrupt installations we’ve had over the years because of that,despite claims to the effect of “my lead works perfectly”.The lack of tones when flashing may be an indicator of that.

I like detective stories,and think of all the new knowledge you’re gathering in your grey matter.Keep at it.

18

I’ve recalibrated the RC and ESCs with every fresh firmware load… I’ve also swapped to a newer USB cord on the off chance that may be my hidden gem of a culprit, but all is the same…

Simple and seemingly dumb question i’m sure, but the “Tones” we are referring to… they come from the FC or the PC i’m using for setup? I’m not getting anything from the FC switch/buzzer upon completion of the upload, but I am getting the “happy ish” tones from the PC when complete. I just assumed the FC would be signalling complete, but maybe its the PC that celebrates?

I will try the physical i/o reset button on the Pixhack case tonight to see if I can get it to in fact reset… so far, nothing has really changed from any other time I loaded any other firmware…

P.S. This is a genuine Pixhack in the aluminum case with the aluminum USB/LED housing bought NIB from “Motcogs” on the RC Groups forums… if that makes any difference in our approach

19

It makes a difference of sorts.It means you start with a well made FC with good quality components and not cut price ones.That doesn’t mean it can’t go bad but it improves the chances of it not happening.

Flashing tones are pretty unmistakeable.Three slow triple tones a second or so apart followed a couple of seconds later by a twin tone for newly installed 3.4ish and above.The blue LED on the Pixhack flashes really fast during firmware writing and slows down when complete)I have a few different safety switches and never pay attention to the LEDs on them.I’ll do a video in a while.

If you’re not getting the tones with the buzzer fitted there’s a clue to something.

These are normal start up tones.

20

Yeah, I definitely don’t get any sort of happy sounds like that! I’m using the buzzer/safety switch that came with the board so one would think they were speaking the same language but perhaps they aren’t. I do get most of the same LED action you are seeing though, with the exception of the LED on the board… the external LED goes to the yellow flashing state in about the same time yours did in the video, however… the LED on the actual hack case remains blinking blue for as long as I let it…