Here’s a strange problem I’ve been having. After several months of inactivity, but previously tens of successful flights with Arducopter 2.9, I recently upgraded my APM 2.6 to Arducopter 3.2, and have been flying it happily in Stable mode.
The very strange thing that I’ve been consistently seeing is a complete loss of roll and pitch responsiveness when I switch to AltHold mode. As I switch, the copter just slowly drifts in a roughly starboard direction, until I panic and retrieve control by switching back to Stable mode. As far as I can tell, I can reproduce this every time I switch to AltHold.
My GPS reception hasn’t been brilliant the few times I’ve tried this - 7-8 sats, HDOP around 2.0, but I don’t think that should have any bearing on AltHold. Vibration levels appear to be good. I’ve followed all the calibration suggested by the wizard. The weather was calm, no noticeable breeze.
Logs (attached) seem to show that the RC inputs are unaffected by the mode switch, and desired roll also seems to follow the RC input. However, it does look as though desired roll plateaus at 0, which seems odd.
So - it looks like there’s no problem on the radio side, it just feels like the APM is simply ignoring the inputs.
There are no reported errors, although the first time I tried, I noticed some EKF/DCM failsafe errors, so disabled EKF/DCM failsafe, and don’t see those errors any more.
Size (kb) 1226.2587890625
No of lines 16786
Duration -1 day, 17:05:02
Vehicletype ArduCopter
Firmware Version V3.2.1
Firmware Hash 36b405fb
Hardware Type
Free Mem 0
Skipped Lines 0
Test: Autotune = UNKNOWN - No ATUN log data
Test: Balance/Twist = GOOD -
Test: Brownout = GOOD -
Test: Compass = GOOD - No MAG data, unable to test mag_field interference
Test: Dupe Log Data = GOOD -
Test: Empty = GOOD -
Test: Event/Failsafe = GOOD -
Test: GPS = GOOD -
Test: IMU Mismatch = NA -
Test: Parameters = GOOD -
Test: PM = GOOD -
Test: Pitch/Roll = GOOD -
Test: Thrust = GOOD -
Test: VCC = WARN - VCC min/max diff 0.527v, should be <0.3v
I’d say you have an issue either with your RC Tx or RC Rx.
Have a look at your RCIN1 (roll) and RCIN2 (pitch) values. You can see they flatline at the time you are seeing the problems. And since the RCIN values are what the APM is actually seeing from the RC Rx, the problem most likely lies in the RC Rx or possibly the RC Tx. This flatline seems to happen independent of switching your Flight Mode so it doesn’t seem related to that. Other than the flatlined areas your actual roll/pitch tracks the desired roll/pitch values fairly well.
Could be something as simple as a loose RC wire, if you are lucky. I don’t think it’s related to your firmware upgrade.
You could check on the problem by hooking the APM up to a PC and watching the real time PWM values for each input channel in Mission Planner. Move the sticks around and if it stops showing a response you’ll know you are seeing the problem…without it being high in the air.
Thanks for the response, although I think you might have misread the logs - maybe confusing RC IN and Desired ATT values?
I don’t see any flatlining in the RC IN values (except for a couple of periods in Stabilize - when the copter was on ground with no input). I forgot to mention - the logs show 2 panic landings. In each case, I armed in Stabilize, flew around for a short time, switched to AltHold, lost command authority, and hastily switched to Stabilize for a panic landing. In between, there’s a period of returning to the launch spot, calming down and trying again.
But as I say - I don’t see any flatlines in RC IN. What does seem a bit odd is some flatline in Desired Roll - but it doesn’t look like much. Note that I haven’t looked much at the pitch logs, since the drift was largely to starboard.
You may be right. Looking at your altitude I see that your log seems to be comprised of two flights, with an interval of your craft sitting on the ground, but still logging. It was the portion between the two flights I interpreted as being flatlined, but in fact you merely hadn’t been operating the controls. The attached plot of the RCIN values for channels 1 and two, plus the altitude, shows the area in between the two active areas I called “flatlined”. If this was indeed two flight, then ignore what I said.
I do see where your desired roll seems to refuse to go positive. It’s like its “clipped” at zero and wants to stay negative. But it does cross over into positive territory twice when you gave it large throws on RCIN1 (roll). You might want to check your radio calibration to make sure the limits are correct. Another thing to try would be to erase your APM and reflash it.Perhaps something in the firmware got corrupted.
Well, I did some rechecks, especially of radio calibration, and nothing seems untoward.
One thing I did tweak, which I don’t think should have been a problem, is variable rates on the TX in different flight modes. Previously due to some dull bit of tuning, I’d configured a tweak of rates via global variables in the Taranis firmware, and I’ve got the Taranis set up to switch to different TX flight modes depending on the flight mode returned from APM telemetry. There was a slightly lower rate configured for AltHold compared to Stabilise. But, considering that the rate was no less than about 80%, and there’s not obviously less RC input in the logs, I don’t think this should have been the root cause.
Anyway, I tried a flight again today, and no problems whatsoever going into and out of AltHold. So whatever it was, seems to now be resolved. Thanks for your time, anyone that read this thread.