@mark ,

Thank you for running the tests!

Regarding installing resistors without knowing what the function is - not recommended . I will look into what this resistor is. Are you saying that after installing this resistor, the issue is not reproducible?

I was going to ask you to do one more test, if you can reproduce the issue. If the issue is indeed at the very low level (the same image is returned for both cameras into voxl-camera-server), then both instances of Auto Exposure algorithm would react to one camera's image changing. So the test would be..

• reproduce the issue to get the same image appear in both camera streams, it seems like tracking_front is the one that is being duplicated
• note the exposure and gain values, reported in the stats below the images
• quickly cover up the front camera (without affecting down-facing camera) and see if the expsure / gain of tracking_down also changes at all.
  • please note that if the image is indeed duplicated at a very low level, the Auto Exposure algorithm's output for the tracking_down will not actually affect the image (since the stream is from tracking_front), but you should still see some changes while AE is converging after a sudden change. If there is no duplication of the image at the camera server, the AE behavior will not change for tracking_down camera when you cover up tracking_front. I hope that makes sense.

Basically i am trying to figure out if this is a camera server issue or somewhere downstream.

Alex

@mark, thank you for the details. It should not matter whether M0054 or M0154 voxl is used.

Can you please do a test and disable both hires cameras and see if the issue is still reproducible? If the issue is gone, then enable one hires camera and test again.

Also, does setting cpu to perf mode help with this? (Voxl-set-cpu-mode perf)

I have never seen this happen with out stable camera configs, such as C28, so this is very odd!

Alex

Hello @Teon,

This is more of a general question, not specifically related to VOXL2. However, here is some information that you might find helpful.

Base station

• Raspberry Pi
• ZED-F9P receiver with dual band helical antenna, connected to RPI via USB
• configure ZED-F9P to be a in base station mode (will require data collection for localizing the base station precisely). Check Ublox docs
• configure ZED-F9P to output RTCM3 corrections over usb to RPI
• run NTRIP caster software (you will need to find one..) which will connect to USB port and serve the RTCM3 data to the clients via NTRIP protocol
  -- this would require an NTRIP client on the client side
• (alternatively) publish the RTCM data via Mavlink directly to the drone (MAVSDK).
• would need a client that would connect to Ublox via USB and send out mavlink messages to your drone
  -- https://mavsdk.mavlink.io/main/en/cpp/api_reference/classmavsdk_1_1_rtk.html
  -- https://github.com/mavlink/MAVSDK/issues/2352

Rover (VOXL2)

• wifi connection to the base station server
• based, on the following docs (https://docs.px4.io/main/en/advanced/rtk_gps) the PX4 gps driver will automatically forward RTCM packets to the attached GPS receiver. The Px4 GPS driver will need to receive the Mavlink GPS_RTCM_DATA packet.
• if you use the NTRIP caster in the step above, you could use a NTRIP client and have the client publish the mavlink GPS_RTCM_DATA message locally on VOXL2 .

I will ask around to see if we have a better documentation for this..

Alex

@mark , we have seen this issue when using 10- or 12-bit drivers for the AR0144 tracking cameras. These drivers are shipped with the SDK but are not stable (for this exact reason).

Can you please confirm which ar0144 sensormodules you are using - you can check in /usr/lib/camera.

Alex

Hi @Rowan-Dempster,

We have been looking at some optimizations to help reduce the overall cpu usage of the camera server (not yet in the SDK). Let me test your exact use case and see what can be done.

Just FYI, we recently added support for sharing ION buffers directly from camera server, which means the camera clients get the images using zero-copy approach. this allows to save the cpu cycles wasted on sending the image bytes over the pipe, especially when there are multiple clients.

If you would like to learn more how to use the ION buffers, I can post some examples soon. One the client side, the API for receiving and ION buffer vs regular buffer is almost the same. One thing that will be different is that the shared ION buffer has to be released by all clients before it can be re-used by the camera server (which makes sense).

Even without the ION buffer sharing there is room to reduce the cpu usage, so I will follow up after testing this a bit. Regarding your question whether sending the image to multiple clients should not cause significant extra cpu usage -- yes you are correct, ideally it should not. However, the reason why it is happening here is related to how we set up ION buffer cache policy and currently when the CPU accesses the buffers for the misp_norm images (coming from the gpu), the cpu reads are not cached and the read access is expensive. Reading the same buffer multiple times results in repeated CPU-RAM access (for the data that would normally be already fully cached after the first send to the client pipe). However, in some other cases (when the buffer is not used by the cpu, but is shared as ION buffer and client sends the buffer directly to GPU), this approach results in even lower CPU usage. So i think we need to resolve the buffer cache policy based on the use case.. More details will come soon..

Alex

@Seungjae-Baek , the resolution of the camera should depend on the use case. However, it is also important to keep in mind what exactly you are doing with the images coming from the hires cameras. For example, if you set the resolution to 4K and you try to view those uncompressed images using voxl-portal, this process will be very taxing on the CPU for the following reason: when you view uncompressed images in voxl-portal, these images are encoded with a software JPG encoder and then sent from voxl2 to your browser. This process is very cpu-heavy. On the contrary, if you use h264 / h265 stream, it should be perfectly fine to encode 4K30 video to disk or even stream, since H264 / H265 encoding is done by a hardware encoder.

voxl-portal, actually does support showing h264 (but not h265) 30FPS streams, so that would be a lot more efficient for the CPU, since there would be no jpg encoding. Otherwise, if you are using raw frames (not _encoded) in voxl-portal , please keep in mind that you will always have a lot of cpu overhead. voxl-portal is designed for debugging / development purposes, so it's not necessarily the most efficient solution for video streaming. For real video streaming use cases, you would use h264 or h265 encoding and save to disk on voxl2 + stream the encoded video for remote viewing. You could encode the same camera source with two different resolutions / codecs / bitrates.

If you need help setting up a specific use case, please provide some details and I can help you further.

Alex

@Ashish-Kumar Are you using the same USB-C cable and port on your host machine that worked before? Also are you running linux natively on your machine or in a VM?

@cbay ,

We support any camera that is compatible with UVC (plugged into a usb port). Please look into voxl-uvc-server. https://docs.modalai.com/voxl-uvc-server/

Regarding NIR, have you considered using a regular camera (most cameras are sensitive to NIR) and install a lens with a NIR pass filter (if you dont want to see visible light)? Then you could use one of our hi-res cameras like IMX412 or IMX664. I can get you spectral response plot of those sensors if you need.

Alex

@Ashish-Kumar Can you run the following and then plug in the board to your host machine after powering it on?

dmesg -wH

and then copy any relevant enumeration info here

Confirmed - can run the dds with humble running in the docker container:

voxl2 (M0054):~$ apt-get install voxl-microdds-agent
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  voxl-microdds-agent
0 upgraded, 1 newly installed, 0 to remove and 40 not upgraded.
Need to get 0 B/4874 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 file:/data/voxl-suite-offline-packages ./ voxl-microdds-agent 3.0.0-0 [4874 kB]
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package voxl-microdds-agent.
(Reading database ... 104493 files and directories currently installed.)
Preparing to unpack .../voxl-microdds-agent_3.0.0-0_arm64.deb ...
Unpacking voxl-microdds-agent (3.0.0-0) ...
Setting up voxl-microdds-agent (3.0.0-0) ...
voxl2 (M0054):~$ systemctl start voxl-microdds-agent
voxl2 (M0054):~$ systemctl status voxl-microdds-agent
● voxl-microdds-agent.service - voxl-microdds-agent
   Loaded: loaded (/usr/bin/MicroXRCEAgent; disabled; vendor preset: enabled)
   Active: active (running) since Tue 2025-11-25 15:13:37 UTC; 14s ago
 Main PID: 3370 (MicroXRCEAgent)
    Tasks: 28 (limit: 4915)
   CGroup: /system.slice/voxl-microdds-agent.service
           └─3370 /usr/bin/MicroXRCEAgent udp4 -p 8888

Nov 25 15:13:38 m0054 MicroXRCEAgent[3370]: [1764083618.308177] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x00000001, datawriter_id: 0x0DF(5), publisher_id: 0x0DF(3)
Nov 25 15:13:38 m0054 MicroXRCEAgent[3370]: [1764083618.308829] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x00000001, topic_id: 0x0E6(2), participant_id: 0x001(1)
Nov 25 15:13:38 m0054 MicroXRCEAgent[3370]: [1764083618.308994] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x00000001, publisher_id: 0x0E6(3), participant_id: 0x001(1)
Nov 25 15:13:38 m0054 MicroXRCEAgent[3370]: [1764083618.309525] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x00000001, datawriter_id: 0x0E6(5), publisher_id: 0x0E6(3)
Nov 25 15:13:38 m0054 MicroXRCEAgent[3370]: [1764083618.310013] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x00000001, topic_id: 0x0EB(2), participant_id: 0x001(1)
Nov 25 15:13:38 m0054 MicroXRCEAgent[3370]: [1764083618.310133] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x00000001, publisher_id: 0x0EB(3), participant_id: 0x001(1)
Nov 25 15:13:38 m0054 MicroXRCEAgent[3370]: [1764083618.310468] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x00000001, datawriter_id: 0x0EB(5), publisher_id: 0x0EB(3)
Nov 25 15:13:38 m0054 MicroXRCEAgent[3370]: [1764083618.310981] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x00000001, topic_id: 0x0F0(2), participant_id: 0x001(1)
Nov 25 15:13:38 m0054 MicroXRCEAgent[3370]: [1764083618.311145] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x00000001, publisher_id: 0x0F0(3), participant_id: 0x001(1)
Nov 25 15:13:38 m0054 MicroXRCEAgent[3370]: [1764083618.311488] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x00000001, datawriter_id: 0x0F0(5), publisher_id: 0x0F0(3)
voxl2 (M0054):~$ docker images
REPOSITORY                               TAG        IMAGE ID       CREATED       SIZE
ros2-image   ed11b766   1040efe3dc33   2 weeks ago   2.33GB
voxl2 (M0054):~$ docker run -it --rm --net=host --ipc=host ros2-image /bin/bash
root@m0054:/# cd
root@m0054:~# ls
root@m0054:~# source /opt/ros/humble/setup.bash
root@m0054:~# ros2 topic list
/fmu/in/obstacle_distance
/fmu/in/offboard_control_mode
/fmu/in/onboard_computer_status
/fmu/in/sensor_optical_flow
/fmu/in/telemetry_status
/fmu/in/trajectory_setpoint
/fmu/in/vehicle_attitude_setpoint
/fmu/in/vehicle_command
/fmu/in/vehicle_mocap_odometry
/fmu/in/vehicle_rates_setpoint
/fmu/in/vehicle_trajectory_bezier
/fmu/in/vehicle_trajectory_waypoint
/fmu/in/vehicle_visual_odometry
/fmu/out/battery_status
/fmu/out/failsafe_flags
/fmu/out/position_setpoint_triplet
/fmu/out/sensor_combined
/fmu/out/timesync_status
/fmu/out/vehicle_attitude
/fmu/out/vehicle_control_mode
/fmu/out/vehicle_local_position
/fmu/out/vehicle_odometry
/fmu/out/vehicle_status
/parameter_events
/rosout