I would like to request a feature that allows taking photos and videos using an RC switch on VOXL 2 Mini.

We’ve investigated how to trigger photo/video capture by sending MAV_CMD_IMAGE_START_CAPTURE (or MAV_CMD_VIDEO_START_CAPTURE) from PX4-firmware when an RC switch is toggled. However, it seems that mavlink-camera-manager (voxl-mavcam-manager) currently only processes commands coming from GCS, and does not handle commands that originate from the PX4 autopilot.

Environment:
VOXL 2 Mini (SDK 1.3.5)
px4-firmware side with #define ATL_MANTIS_RC_INPUT_HACKS enabled to use photo_switch and video_switch.
Confirmed that MAV_CMD_IMAGE_START_CAPTURE is indeed being sent by PX4 upon toggling the RC switch.
From our investigation, mavlink-camera-manager/src/qgc.c only handles messages from FROM_GCS_PIPE_NAME ("mavlink_from_gcs"). As a result, any capture commands (MAV_CMD_*_CAPTURE) sent by the PX4 autopilot via an RC switch are not recognized, so photos or videos are never saved.

Having the ability to start/stop captures via a user’s RC switch instead of exclusively through a GCS would be extremely helpful. We would greatly appreciate it if mavlink-camera-manager could also accept and handle MAV_CMD_*_CAPTURE commands from PX4 (or if there is an alternative way to accomplish this, we’d be interested in hearing about it).

Thank you for your time and consideration. We look forward to any updates or guidance you can provide on this topic.

I am trying to access VOXL Portal from my smartphone(iPhone) to display the camera feed.
However, even when I select an individual camera from the menu, it does not display.
Additionally, the snapshot capture feature is not functioning, which is also an issue.

When I select Multi-View, the camera display does work, but since I cannot take snapshots, it does not meet my intended use case.

Could this issue be due to a bug?

One more question: Is there any plan to implement a video recording feature in Portal in the future?

@Eric-Katzfey
Thank you for your quick update.
I was able to confirm that it is functioning properly.
Really appreciate your support. Wishing you a wonderful New Year!

@Eric-Katzfey
I think the messages of OSD_STATUS_ROW appear on both, OSD_STATUS and OSD_FM.
Problem seems the message is appear to OSD_FM_ROW when OSD_STATUS_ROW is enabled.

@Eric-Katzfey

Here is the OSD params

1	1	OSD_BAND	5	6
1	1	OSD_BATT_COL	44	6
1	1	OSD_BATT_ROW	17	6
1	1	OSD_CBATT_COL	44	6
1	1	OSD_CBATT_ROW	16	6
1	1	OSD_CHANNEL	1	6
1	1	OSD_CH_COL	-1	6
1	1	OSD_CH_HEIGHT	0	6
1	1	OSD_CH_ROW	-1	6
1	1	OSD_CURR_COL	-1	6
1	1	OSD_CURR_ROW	-1	6
1	1	OSD_DIS_COL	1	6
1	1	OSD_DIS_ROW	11	6
1	1	OSD_DWELL_TIME	500	6
1	1	OSD_FM_COL	1	6
1	1	OSD_FM_ROW	9	6
1	1	OSD_HDG_COL	21	6
1	1	OSD_HDG_ROW	0	6
1	1	OSD_HOME_COL	-1	6
1	1	OSD_HOME_ROW	-1	6
1	1	OSD_LAT_COL	-1	6
1	1	OSD_LAT_ROW	-1	6
1	1	OSD_LOG_LEVEL	3	6
1	1	OSD_LONG_COL	-1	6
1	1	OSD_LONG_ROW	-1	6
1	1	OSD_REMOTE	0	6
1	1	OSD_RSSI_COL	-1	6
1	1	OSD_RSSI_ROW	-1	6
1	1	OSD_SCROLL_RATE	125	6
1	1	OSD_STATUS_COL	1	6
1	1	OSD_STATUS_ROW	17	6
1	1	OSD_SYMBOLS	16383	6
1	1	OSD_VIO_COL	38	6
1	1	OSD_VIO_ROW	0	6

Thank you for the advice.
Both messages are disappeared when I set OSD_STATUS_ROW to -1

Also it was working as expected when I try it from the J10 port

@Eric-Katzfey Thank you for your support and the updated package.

I have successfully verified that the OSD works using J19 pins for UART communication. The msp_dp_osd program is displaying the OSD as expected.

However, I noticed an issue where a STATUS message or similar text is displayed in two locations. One appears correctly in the lower-left corner, as configured, but another is also visible near the center-left of the screen (please see the attached image).

Could you confirm if this behavior is expected?

Current configurations:
OSD_DIS_COL 1
OSD_DIS_ROW 11
OSD_STATUS_COL 1
OSD_STATUS_ROW 17

I would also be happy to handle long error messages.

@Eric-Katzfey Thank you for providing the updated package.
I will test it within the next three days.
I’ll get back to you with the results shortly.

@Eric-Katzfey Thank you for your response.

Yes, that's correct. I don't use GPS for indoor flight, so it's fine to use that UART port on J19 for OSD.

I appreciate your support and look forward to the update.

I am currently working on configuring the OSD program (msp_dp_osd) on VOXL 2 Mini. I have successfully confirmed that the OSD works using Pins 4/5 on J10 (/dev/ttyHS0).

However, Pins 4/5 on J10 (/dev/ttyHS0) are required for other critical purposes, and as a result, I would like to utilize J19 Pins 2/3 (SSC_QUP6) for OSD UART communication.

As these pins are connected to the DSP (SLPI processor), the current OSD implementation cannot access SSC_QUP6 directly because it requires QURT compatibility.

I kindly request that the OSD program be extended for QURT compatibility so it can function over SSC_QUP6 (J19 Pins 2/3). This modification would free up /dev/ttyHS0 for other critical tasks and allow more efficient use of the VOXL 2 Mini's available UART resources.

Thank you for considering this request. I look forward to your response and any guidance on potential workarounds or a timeline for implementing QURT compatibility for the OSD program.

@Alex-Kushleyev
I try reducing the pulse next.

We use ArduPilot with an external flight controller.
It would be nice to use the ESC UART protocol directly from the FC.
Having ArduPilot work on the VOXL 2 mini would be even better.