RC pass thru in Guided_No_GPS

Is there a good way for using the RC input to control attitude within guided_no_gps mode?

For instance say you have a companion computer which is controlling pitch or roll and you’d like to use the user input from the RC controller for a different axis. I’m thinking a channel override wouldn’t work because it isn’t listening to the channels for attitude anyway.

Would the only way be to read in the channel value, map that in your own loop to some angle and pass that in send_attitude_target?

1 Like


Guided mode doesn’t support pilot input so I’m afraid that if you’d like to do “stick mixing” (mixing of inputs from a pilot and an autonomous controller) you’d have to do as you describe, which is to do that mixing in the companion computer and incorporate it into the attitude-target message.

If you’re comfortable modifying the ardupilot code you could modify the mode_guided.cpp’s angle_control_run() method so that it does the stick mixing in there. That wouldn’t be a verify difficult change because you could steal the “get_pilot_desired_lean_angles()” code from mode_althold.cpp’s “run()” method.

If you’d like this enhancement to become a permanent addition to AP then it would be best to add a new parameter (perhaps called “GUIDED_CONTROL”) that enables whether we support stick mixing in Guided or Guided-NoGPS modes and then create a PullRequest to get it included. Something similar was added recently to circle mode. In either case you could also create an enhancement request in the issues list and it’s possible another volunteer developer might pick it up (no guarantees of course)


Thanks for the guidance I think it’s pretty much doing exactly what was desired. I wasn’t sure wether to set and use the auto_yaw variable so it just compares to the parameter.

One thing I noticed is that I believe the definition for the SET_ATTITUDE_TARGET on https://ardupilot.org/dev/docs/copter-commands-in-guided-mode.html#copter-commands-in-guided-mode-set-attitude-target
may be outdated. It says that body_yaw_rate is not supported and that the bitmask should always be 0x07. In reality I believe yaw_rate is supported and that bit 3 should be set to ignore it and the last two bits aren’t evaluated (0x04) would ignore yaw_rate and (0x00) would use yaw_rate. More properly should probably use (0x07) or (0x03) to keep the roll and pitch rates ignored should they ever be implemented.