mavlink / qgroundcontrol

Cross-platform ground control station for drones (Android, iOS, Mac OS, Linux, Windows)
http://qgroundcontrol.io
3.31k stars 3.63k forks source link

Camera display for Mission Waypoints issues and specifications clarification #8433

Open stefandunca opened 4 years ago

stefandunca commented 4 years ago

We have reports from pilots of Waypoints Camera Yaw not matching the final executed commands Looking throughout the code I see some unexpected behavior. With this issue, I would also like to clarify the specification.

Expected Behavior

Current Behavior

Steps to Reproduce:

  1. Create a mission containing four waypoints
  2. Enable camera gimbal for the second waypoint
  3. Enable Vehicle Heading (vehicle yaw in the code) for the last one, the fourth one. At this point, the third waypoint changes the camera direction
  4. Enable vehicle heading for the third and set it to 45. The second changes as well.
  5. Set vehicle heading for the second to 45, nothing happens. Set the gimbal yaw to 45, now the third and fourth changes as well.

System Information

Latest master.

DonLakeFlyer commented 4 years ago
  • Enabling one waypoint will show camera waypoints to all the following waypoints. If Vehicle heading is set for one waypoint it will propagate the vehicle yaw for the next waypoints as well

This is intended. The assumption is that if you set a gimbal angle and/or vehicle heading those settings will persist through the rest of the waypoints until you change them to something else. It also assume that the NaN setting for yaw on the subsequent waypoints will leave the heading alone as opposed to going back to say pointing at the next waypoint. If that is incorrect let me know.

Your repro steps indicate a separate bug in the gimbal calc code.

DonLakeFlyer commented 4 years ago

So at least with PX4 a NaN in yaw causes the vehicle to go back to pointing towards next waypoint. In looking at the mavlink spec, it somewhat clear that this is what it should do. So QGC code is incorrect here.

Also the value is labeled as Heading when it should be labeled as Yaw.

hamishwillee commented 4 years ago

My understanding of the spec is that an explicit yaw (heading) in a waypoint lasts until the next waypoint. If a NaN is sent then the behaviour is unspecified by MAVLink - ie the theory is that it devolves to flight-stack specific behaviour. On PX4 the default behaviour is to point to next waypoint, but this can be changed to home or away from home in parameters. I have a PR in place to make this something that can be set using an explicit message: https://github.com/mavlink/mavlink/pull/1297

So at least with PX4 a NaN in yaw causes the vehicle to go back to pointing towards next waypoint. In looking at the mavlink spec, it somewhat clear that this is what it should do. So QGC code is incorrect here.

So to be pedantic, it will point towards whatever the system setting says. I think perhaps we need a message to publish this (rather than forcing you to get a parameter?)

Also the value is labeled as Heading when it should be labeled as Yaw.

Yes.

I don't know what the gimbal setting should do. QGC exports a plan that says this is done with MAV_CMD_DO_MOUNT_CONTROL but there is nothing to say whether the setting should propagate across waypoints, and the way it points depends a bit on mount mode.

Is the general assumption that commands apply to specific waypoint, or that they apply until cancelled? I don't think we have such an assumption, which means we really need to say for every message.

DonLakeFlyer commented 4 years ago

lasts until the next waypoint

I think mentioning that in the spec would be helpful.

Is the general assumption that commands apply to specific waypoint, or that they apply until cancelled

Apply until cancelled.