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
- Check ESC wiring to the Ardupilot board, should be like this for the typical quad config:
- 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
- The radio calibration button works in mission planner
- The ESC calibration method of putting PWM 2000 and conn-discon the electricity (both from USB and battery) works
- 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
- ARMING_CHECK = 0 (disabling arming protection, yea I know it sucks, we have a bare drone, will improve it once the procedure works reliably)
- 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 -----
Option 1. RCx as a way to arm? DID NOT WORK, MAYBE BECAUSE OF A PROBLEM WITH PARAMS
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.