Hi, newbie (but learning) here. I am trying to set up Arm/Disarm to a transmitter switch, but Mission Planner doesn’t respond when I engage. Doesn’t respond to Rudder Arm/Disarm either. Parameters and equipment are:
Current MP firmware, ArduPlane 4.3.1 (Quadplane Enabled), running on a Matek 743 Wing
Radiomaster TX16S, AETR, with CH 7 set in Mixes to Arm/Disarm
RC7_Option = 153
What am I missing?
In the MissionPlanner RC Calibration screen, does your CH7 respond to switch movements in there?
https://ardupilot.org/copter/docs/common-auxiliary-functions.html#check-the-channel-range
If you think everything should be working based on that RC Calibration screen, then set LOG_DISARMED and give it another test (trying to actually arm) and supply the .bin log file.
Set LOG_DISARMED back to 0 after that test.
Yes, CH 7 does respond in the RC Calibration Screen. Can you send me instructions/link on how to download the .bin log?
and you will have to upload the log to a filesharing service like dropbox or similar, and then provide that link here
OK, will try to figure this out. If it means anything, when I view the Messages tab under the Data viewer, ever time I try to arm with the transmitter radio I get this message:
Arm: AHRS: AHRS not using configured AHRS type
What might this mean? Have I not configured the AP correctly?
Also, when I move the rudder stick to the lower right, it give the same message in the Messages tab. The Messages tab also keeps repeating PreArm: AHRS: AHRS : not using configured AHRS type.
Everything else seems to work, airspeed, gps lock, compass is calibrated.
That’s fine, wherever I can get the most help.
Hopefully this link works:
No help on the horizon, so I persevered trying random things, and finally got ARM/DISARM to work with the radio switch. Seems one has to turn off Pre-flight arming completely in MP for the radio switch to work (probably a newbie oversight). Also finding that I need at least 12 satellites locked before I get rid of all the warnings in the HUD, and the plane stops jumping around in the HUD…is this normal?
It’s normal for the GPS unit to take a long time to acquire a 3D fix from cold boot, close to the ground is hard work! Even up on a table or stand is a bit better. Subsequent power-ups (battery changes) on the same day should be quicker and easier. Trees attenuate the GPS signals and houses can cause reflections, all contributing to longer times to 3D Fix. In that log your number of Sats is low and HDOP is poor. Try setting
GPS_GNSS_MODE,1 or 3
and this at least might help with consistency, not trying to use so many constellations when or if they are visible.
HDOP below 1.0 is what you are looking for mostly, rather than number of sats.
I would definitely turn on Arming checks again
ARMING_CHECK,1
and sort out whatever comes up.
In that log, you had “All” selected which means the other selections are all selected anyway. Selecting or unselecting individual checks doesn’t have any effect unless you also unselect “All”
PreArm: AHRS: AHRS: not using configured AHRS type
I think this just means EKF3 (the selected AHRS type) is not working yet, like no GPS 3D fix or something else is wrong. I would expect more specific messages if there was anything more serious, otherwise EKF3 is just waiting for everything to come good.
In your case I think this message will go away once there’s a GPS 3D fix.
Arm: Logging failed
You have LOG_BACKEND_TYPE,3 which means Arduplane will be expecting a groundstation or other mavlink device to receive logging. Probably just set it to
LOG_BACKEND_TYPE,1
for SDCARD only.\
Then the Arm switch should work without disabling all checks 
Thanks, Shawn,
Several observations and questions:
I have all my hardware (AP, GPS, ASpeed, Rx) laid out on a piece of cardboard so that I could do the setup and testing, and it’s inside my house, where I only get 5-6 satellites max, so I get lots of AHRS and GPS warnings. When I take the whole works outside sat count goes up to 12 or 13, and these messages go away. Indoors, the HUD jumps around a lot as well, but outside is very stable…is this because of better satellite reception? Any reason to change GPS_GNSS_MODE if my outdoor reception is good? Also, where do I find HDOP?
I’ll try the ARMING_CHECK again, with your suggestions. But, is MP arming check necessary if I can see the status of the readiness in the “Pre-Flight” window, before I ARM with my radio switch?
Newbie oversight, it took multiple work-throughs to realize that I needed to put my SD card in the AP to faithfully record logging. So yeah, I put the card in, and changed the LOG_BACKEND_TYPE to 1.
Yes exactly, much better more stable GPS reception outside.
Limiting the number of constellations with GPS_GNSS_MODE can improve time to 3D fix, and also keep a stable update rate from the GPS unit. Too many constellations and sats mean the update rate can suffer and Ardupilot will flag that if it’s too bad. The default 0 uses all constellations the GPS unit can see, usually overwhelming - best to pick what suits your area.
In MissionPlanner you can right-click on the HUD and add user items: GPSHDOP
Or double-click in the Quick panel and select different items in there (similar to useritems in HUD)
If you have a transmitter and receiver that’s capable of using the Yaapu telemetry script, everything we are talking about (and more) is right there onscreen.
Warning! if you ever get to try yaapu telemetry you will NOT be able to live without it. You’ll end up setting it up on the kids, the cars, the bicycles, the neighbors dog…
The Arming Check works two ways I think
a) forces us to address issues for new builds
b) flags any new or unexpected issues if they ever arise
Shawn, thanks for all the help, especially on TG Day! I’m really psyched that my build is coming together. This is my first using Arduplane, and to be honest, I’m actually putting this build into a VTOL, so I’m learning all the Q_ parameters as well. A good winter project!!!
Keep in mind the VTOL quick tune script.
A lot of the Initial Parameters for Copters calculated in Mission Planner also apply to the Q_ params you’ll be using.
Here’s the spreadsheet it’s based on, but for your build do what the plane experts say (not me )
Many thanks for the parameter spreadsheet. For VTOL quick tune, do you mean Q_Autotune flight mode?
No, prior to running Q_Autotune there is this LUA script just to gain some initial stability
There’s a youtube video there too
Wow, that is very cool. I’ll be using this for sure!
Just a bit confused though, the parameters listed on the GitHub site for Quicktune, does one set those prior to activating the LUA script, or are those the parameters that the Quicktune is adjusting?
Sorry if I’m being a pain, but I’m new to this. How does one download the lua script from Github? I found the lua code and tried to copy/paste it into a text file, but that did not work.
