We have a PR here that changes how the vehicle is rotated during an ROI (e.g. clicks on MP map and selects, “Point Camera Here”) in cases where the vehicle has a 3-axis camera gimbal but the gimbal’s yaw range is not sufficient to point at the ROI.
Here are some options:
Rotate the vehicle only as much as is required to get the gimbal to point at the ROI plus some margin (10deg? 20deg?). So in the picture shown above the vehicle would rotate perhaps 45deg (?) to the right.
Rotate the vehicle to point directly at the ROI if the camera gimbal’s range is insufficient to point at the ROI.
I guess we need to consider that the vehicle will often be moving meaning that this check need to run continuously while ROI is active. Sudden heading changes could surprise the pilot in some cases.
I’d think you would want this value to be a parameter.
Possibly a value between zero and one? Zero would yaw the quadcopter just enough to bring the ROI into view. Setting the parameter to one would yaw the quadcopter far enough to bring the ROI into the center of the gimbal’s yaw range (centering the gimbal on the ROI).
The default value for this parameter could be 0.5. This would bring the ROI 45 degrees from the center of the gimbal range. (In this example.)
I’m not sure if a value from zero to one is the best range. It might be better for this parameter to use degrees like the other gimbal parameters.
Whichever way it’s done, I do think it would be good to make this value a parameter would could be set by the user.
I would definitely make that a parameter in degrees though I am not sure weather deadband or margin would be more intuitive. Having a time constant for the desired yaw would be nice though it could compromise tracking with narrow margin. Maybe two margins could be used, one with soft adjustment and one with hard one.
In my opinion, Solution 1 is sufficient. It’s enough to rotate the gimbal just enough so that it can turn toward the POI, with a few degrees of “buffer.”
Solution 2 is essentially the same. In my opinion, there is no advantage to letting the copter rotate even further “in advance,” since it is absolutely unknown whether and in which direction further yaw changes will be necessary.
It would be important to be able to disable the function.
I think that right now this can only apply to copters and VTOL in hover as other vehicles don’t support lateral position control* so they can’t maneuver while pointing.
* except for manual modes in Omni rovers and subs.
Can someone help me understand something? I appreciate this feature in Auto or Guided, but how would this work in Loiter? Does this (or is it intended to) work in Loiter? If it does, what happens to control inputs if the drone starts to yaw but the pilot doesn’t want to change the track?
My guess would be that pilot disables this feature to not use it and tracking is probably lost or gimbal just rotates as much as it can and that is it.
I would expect in general, in loiter or other modes, when pilot tracks some position with camera it would have to yaw anyway to keep it in range of gimbal and camera fov.
The do-set-roi (aka “Point Camera Here”) feature does not affect the vehicle’s heading in pilot controlled modes including Loiter, AltHold, PosHold, etc. The gimbal will still move in pitch and yaw so if the ROI is out-of-range of what the gimbal can do, it will just hit its limits and stay there.
In autonomous modes like Auto, Guided, RTL the do-set-roi will affect the vehicle’s heading.
Option 1 with the margin being a paramater. But not sure whether allowing a 0 degree margin is wise so a minimum of something like 5 degrees may be enforced.
Not exactly sure of the utitlity of option 2 because with the margin now being programmable, we can achieve the least yawing of the vehicle since normally if the ROI is within the gimbal’s range, you don’t yaw the vehicle so I guess keeping yaw motions to a minimum as much as possible is desired.
I can’t figure that out in GUIDED mode, at least. I’ve been using ‘fly-to-here’ to move the copter back and forth passing the ROI. ROI’s relative position is not affecting the heading.
Currently if the vehicle has a 3-axis gimbal the vehicle’s heading will never be changed in response to an ROI. This new PR proposes to change that though so we do move the vehicle’s heading if the camera gimbal’s yaw range isn’t sufficient to point at the ROI.
Agreed that it would make sense to expose this as a range, scaled by a parameter.
Some vehicle designs will be better than others at following a course while independently maintaining a heading, and some mission types (especially with other sensor types / peripherals involved) may place higher or lower importance on the vehicle’s orientation relative to the path being followed vs the target being visualised.
If it’s degrees it could be intuitively used to set bounds for the attitude target, so it only sometimes applies, but when it does it’s a hard adjustment.
If it’s a proportion (e.g. 0.0-1.0 / 0-100%) it could be used to proportionally scale the attitude target between the vector to the ROI center vs the course vector. That’s potentially softer, but always has an effect (which likely comes across as more consistent/intuitive behaviour).
Thanks you for constantly adding features and playing around with gimballs.
Personally I haven’t seen any limitations in do set ROI by utilizing the copters Yaw to constantly strafe at a target during auto. To the contrary I’ve seen the issue when I fly in loiter mode were my ROI is always behind a leg or the limit of the cameras yaw as you mention, but usually as a result of poor coordination from my side and the cam operator.
But there is a huge pain with pan limitation to airplanes!! If I Loiter at a point and my camera has +180 -180 limits then I can only observe ROIs within the circle. In order to look outside the loiter circle I need to make a figure 8 mission. As such I would love to have a mode called figure 8 or something and adjust the size (based on my airplane bank angle capability) and the orientation (to keep the 8, 90degrees to the ROI)
I am guessing this auto yaw to keep roi available for gimbal yaw/pan range would make plane doing circles in loiter without any pilot input. It would just adjust yaw constantly in one direction which would result in more or less round circles.
Thanks for the enhancement request. I don’t normally get too involved with Plane but still I would like to understand the request a bit more.
I can imagine that while loitering (in plane) if the ROI is outside the circle the gimbal will reach its imit and need to rapidly rotate the gimbal 360 deg which will make the footage ugly.
I don’t quite understand why flying a figure 8 would be better than a circle though. Is the idea that the center of the figure-of-8 is aligned with the ROI as shown below?
