ROI waypoints don't always work

[mwiatt]

Describe the bug Occasionally (maybe 50% of the time) an ROI waypoint will not be processed. This bug has been present since at least 1.8.2 (when I started using PX4). When I was using 1.8.2, I was using a PWM driven gimbal hooked to the AUX port. Now, I am using 1.10.0-rc1 and experiencing the same bug with a Mavlink connected gimbal. Completely different hardware,

To Reproduce This behavior is intermittent and hard to regularly reproduce.

Steps to reproduce the behavior: 1) Create mission with a "ROI" waypoint and possibly a "Cancel ROI" 2) Upload to flight controller 3) Take off and fly in mission mode.

Expected behavior The gimbal will point at the ROI waypoint. If a "Cancel ROI" waypoint is issued, the gimbal will return to a neutral position.

Log Files and Screenshots https://logs.px4.io/plot_app?log=566767d5-5d67-4d58-add6-fad66e1579d9

Flight plan: ROI.txt

In the flight above an ROI waypoint is added. Sometimes the gimbal will point at the ROI waypoint as it should. On some flights it wont. Attached to the last waypoint is a "Cancel ROI" waypoint which doesn't always cancel the ROI. Several flights were performed as well as several reboots of the AP. The results were an inconsistent mix of everything working to nothing.

Drone (please complete the following information):

• Tarot X6 (with Tarot retracts)
• Pixhawk Cube 2.1
• Here2 GNSS
• PX4 1.10.1rc1
• QGC 3.5.5
• Gremsy S1 Gimbal connected to Telem2 (Mavlink)

Additional context I have verified the gimbal is working correctly. My MNT_MODE_IN is set to "AUTO" and I can always control the gimbal pointing angle via RC. The problem only occurs when a ROI waypoint is used to control the gimbal. I have verified that this behavior also exists when the MNT_MODE_IN is set to "MAVLINK_ROI".

I am eager to do as many test flights as necessary to get this resolved. If additional logging is required, please provide instructions to enable logs. I am also willing and able to build new firmware.

[mwiatt]

Possibly related to https://github.com/PX4/Firmware/issues/12510 and https://github.com/PX4/Firmware/issues/13458

[mwiatt]

I just did quite a few more flights trying to find some sort of pattern and came up with nothing. One thing that I did was to change the mission start waypoint to include setting the pitch of the gimbal to 45 degrees. I also saw that occasionally failing. The interesting thing there is that the ROI waypoint is of type NAV_CMD_DO_SET_ROI_LOCATION and the fixed angle one is of type NAV_CMD_DO_MOUNT_CONTROL which take two pretty different paths in the firmware.

So there is something failing that gets called in the processing of NAV_CMD_DO_SET_ROI_LOCATION and also NAV_CMD_DO_MOUNT_CONTROL for both PWM and Mavlink output types types. Seems like there is something failing on the input side of things around here:

https://github.com/PX4/Firmware/blob/master/src/modules/vmount/vmount.cpp#L243

or somewhere in here:

https://github.com/PX4/Firmware/blob/master/src/modules/vmount/input_mavlink.cpp

Or perhaps the Mavlink message destined for vmount is being dropped entirely?

The RC input always works.

[mwiatt]

@julianoes I have been trying to chase this in the vmount module but I see that you applied a "comms" label to it. It seems like you might have a hunch as to what the problem is. Is there anything I can do to help track this down? I am willing to do test flights, dig into code, etc. Is there any sort of hack or band-aid I can apply to cover up the issue or at least minimize its frequency?

This bug is currently causing me to have to refly over 50% of my missions which is very hard to do given some of the locations I am flying at and people that I need to coordinate with to get flight clearance.

[mwiatt]

More info that might help with debugging.

I create a very simple mission that consists of the following waypoints: 1) Takeoff 2) ROI 3) Standard waypoint 4) Cancel ROI

In this case, there is not a RTL at the end of the mission so the vehicle will just loiter at the last waypoint.

If I start in "Mission Flight Mode" from the ground, the ROI will often not be processed. This is the subject of this issue.

If at the end of the mission while the vehicle is loitering and "Mission Flight Mode" is still active I select the ROI waypoint in QGC and set it as the active waypoint the ROI will occasionally (not always) be processed and the mission will continue.

If at the end of the mission while the vehicle is loitering I put the vehicle into "Hold Flight Mode", then select the ROI waypoint and make it active, then return the vehicle to "Mission Flight Mode" the ROI waypoint will always be processed as it should be.

Hope this helps.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[mwiatt]

Wondering if anyone has any ideas about why this is broken or what it would take to fix it.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[dayjaby]

Do you still face this issue? We tracked this bug down to too many vehicle_commands being sent. vmount publishes 40 commands per second and navigator/mission_block publishes the DO_SET_ROI_LOCATION upon arriving at the mission item. This seems to be too much for the navigator to handle, who is responsible for translating this command to vehicle_roi. After applying this commit, you should have the issue fixed:

https://github.com/dayjaby/Firmware/commit/505ed226418fe8621d862b1ff3eaa1545ef4bf0f

Tested with a Pixhawk 3 Pro and a Gremsy Pixy F gimbal.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.