SITL SET_POSITION_TARGET always tracks North

When using SET_POSITION_TARGET_LOCAL_NED with MAV_FRAME_BODY_OFFSET_NED the copter always tracks North irrespective of the vehicle heading.

Directly using the MAVProxy command to fly forward at 1m/s listed here: Copter Commands in Guided Mode — Dev documentation has the same effect. By also ignoring yaw I can maintain the heading but despite a BODY frame an x velocity never tracks the vehicles’ current heading and always tracks North.

Is the body frame reference supported in Ardupilot or am I missing something here?

1 Like

Hi @nstansbury,

I just tested this in SITL and the vehicle seemed to move correctly.

This is what I did:

  • cd ArduCopter
  • ../Tools/autotest/sim_vehicle.py --map --console
  • guided
  • arm throttle
  • takeoff 20
  • module load message
  • message SET_POSITION_TARGET_LOCAL_NED 0 0 0 9 3527 0 0 0 1 0 0 0 0 0 0 0

This last command I had to send many times because otherwise it times out (a safety measure)

Thanks for checking this, at least I know it should work

I couble checked this again, same commands as you, Starting at a heading of 205, I definitely change my heading to North and track North.

I’ve reached the maximum image size limits of this thread so can’t post more images, but I definitely see the same behaviour as I posted above.

Is there param that I could have set that could cause this behaviour? I did wonder if this was a bug in QGC, but the sim clearly shows me yawing nearly 180.

Thanks again

Hi @nstansbury,

Ah yes, I suspect if WP_YAW_BEHAVIOR = 3 (Face along GPS course) you could see some odd behaviour. If you set it back to the default of 2 (Face next waypoint except RTL) or 0 (Never change yaw) it will probably act normally.

Thanks for looking at this, I appreciate your time, I seem to be going around in circles here.

Sadly that setting was at the default. I even reset the SIM ePROM and just couldn’t get the expected behaviour, so I switched frames to use LOCAL_NED rather than body and computed a global rather than relative bearing.

This works in the SIM and the real quad, but the vz velocity now behaves differently in the SIM vs the quad.

Given the docs say the vz velocity up is -ve and down is +ve in the SIM a vz of 0 holds altitude, but in the actual quad it slowly descends unless I give it an arbitary vz of -2m/s.

I’m feeling I’m misunderstanding this method call and missing something here. LOCAL_NED is in earth frame coordinates and BODY_OFFSET relative to the vehicle? So why would a vz of 0 not hold altitude in the real world yet it does in the SIM?

(The quad is fully tuned and flies well.)

Hi @nstansbury,

Could you include a log from SITL testing? There’s no reason that our SITLs should behave differently so there must be an explanation.

Delete the eeprom.bin file and follow the exact commands I posted above.