ArduCopter3.2.1_amp2_quad wont arm

SUMMARY: This thread is probably useless for everyone, the problem was my arming was automated from another board and I was retarded enough not to send all the PPM values between 1000 and 2000, but only 1000 and 2000 exactly, this way the RCx_TRIM value uses the max value (which does not make a lot of sense, but this was designed for a stick based radio so I ham it on myself xd).

Deep diving on a problematic setup (working thread)

I am trying to debug recurrent problems while using Arducopter 3.2.1 with my specific quad project and though about making a thread for if you want to give feedback:

Procedure so far on ArduCopter3.2.1_apm2-quad.hex

  1. Check ESC wiring to the Ardupilot board, should be like this for the typical quad config:
  2. Motors should be WELL fixed with more than two screws because any collision will probably break the threading for one of them if there are only two
  3. The radio calibration button works in mission planner
  4. The ESC calibration method of putting PWM 2000 and conn-discon the electricity (both from USB and battery) works
  5. Using Mission Planner try all the motors in succession and verify they match the ABCD buttons in the order shown above. Check with a piece of paper the sense of rotation is the one in the drawing
  6. ARMING_CHECK = 0 (disabling arming protection, yea I know it sucks, we have a bare drone, will improve it once the procedure works reliably)
  7. NOT WORKING: Arming by moving the YAW value to 2000 (channel 4, PPM[3] in my Arduino code). According to docs and 3.2.1 source code YAW seems to be the way to arm.

Procedure so far on ArduCopter3.1.5_apm.hex

Configuration is the same as 3.1.5 but not able to test the motors in Mission planner.

When trying to lift it goes berserk (but not flipping like when blades are wrong or motors turned in the wrong sense(??)), we moved to 3.2.1 because motor test did not work from Mission Planner due to “Command rejected by MAV” and “Command was denied by autopilot” and was trying something new. One of the motor made a slightly higher noise when testing than the others so tomorrow will change it and retry.

----Further research for testing -----

According to this “CHx_opt is now called RCx_option” and in the current docs I also see “An RC channel can be configured as an ARM/DISARM switch by using the RCx_OPTION for that channel set to 41”.
In the properties file I have a CH7_OPT,0 and CH8_OPT,0 maybe I can send a PWM signal in the PPM to arm it ignoring the YAW mechanism. In the V4.0.7 doc it says:

CH7_OPT: Channel 7 option. Select which function is performed when CH7 is above 1800 pwm

So maybe I can use that value to force arming

Option 2. The PWM generated for yaw and throttle are not as good as they should THEY WERE OK
Maybe trying to fine tume the throlle 1000 and the yaw 2000 would help

Option 3. Possibility of a non deterministic error WAS NOT

This other question talks about a weird non-repeatable error

Option 4. Go back to 3.1.5 and use a new motor *NOT NEEDED

SOLUTION: Aparently it was a parameter issue, the ones on the right did work (because of the TRIM maybe)

Any comment is welcome, can not use any firmware over 3.2.1 AFAIK, using cheap aliexpress clones.

That’s right you can’t with the long obsolete, and unsupported, APM Flight Controller. You should replace it with one that runs current Stable Arducopter.

Any comment is welcome xd

The RCx option is not available to you.

The problem is few people recall how to configure in 3.2.1.I tossed my last one in the bin years ago. Arming is throttle down Yaw right.

W/o an RC system you will have a hard time tuning that craft.

1 Like

I could tune with an R/C but the flight needs to be programmatic from another board, I can do signal processing (for PPM analysis) and read the 3.2.1 Cpp source code, I am thinking that I should devote more time to the logging mechanism which seems annoying to say the least XD.

About the RCx_Option, it is not in my listing but the CHx_opt is and some links show people using 41 there… so I will try tomorrow morning and come back to this post.

If you plan to use a companion computer to programmatically change the flight path in real time, then you NEED to use the guided flight mode of ArduCopter 4.1.x.

Everything else is just painful.

1 Like

But if your objective is to follow an object, of course you should use the follow flight mode instead.