@Rowan-Dempster , Here is where the raw data from the TOF sensor comes into voxl-camera-server : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/dev/src/hal3_camera_mgr.cpp?ref_type=heads#L1242 The data is in the MIPI12 packed format. The TOF library expects RAW16 format, so the data is converted from MIPI12 to RAW16 and fed into the TOF processing library. It is possible that dumping the RAW data is what RRF recording would be doing, so you could add that functionality to camera server to write the raw data to file. I could also help with publishing the RAW12 data as is to a mpa channel, so you can log it outside of the camera server (for example using voxl-record-raw-image utility. You could clarify with PMD if that would work (in other words, you would need to know the log format of the RRF recording) We have not tried enabling the raw data logging. However, if you know what function needs to be called within PMD library (maybe you just enable logging, and it does everything for you), you should be able to add it somewhere in the TOF init code, maybe here : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/dev/src/tof_interface.cpp?ref_type=heads#L982 You can find the API header files for Royale / Spectre in /usr/include/royale either on VOXL2 directly on in /opt/sysroots/qrb5165_1/usr/include/royale the voxl-cross:V4.4 docker. Hopefully that helps! Alex

@Alex-Kushleyev, Yes, what you have described for the client application is what I am trying to design. Ideally, I would have time synchronization so that frames always line up, but if latency isn't too big of an issue, this should work fine. I was planning on working with the RGB image, but I'm open to using YUV if it offers a noticeable reduction in latency. Also, to clarify my current setup, I have 4 AR0144 cameras placed at 90-degree angles to one another, so there is plenty of overlap between adjacent cameras for stitching. A simple example would be extremely useful! Thanks for your help!

@alexvolt , the datasheet for M0107 can be found here : https://docs.modalai.com/M0107/ . This is a Sony IMX412 camera. The connector pin-out provides the power supply voltages. This module is designed to work with VOXL products and it we would not be able to provide much support for connecting this camera module to another platform. The main reason being that inability to test the custom setup ourselves would make any debugging very difficult. Alex

Hi @Manoj-Kashyap As per that thread, we EOL'd M0169, so support should move to M0171. However, if you already have some M0169's, then this cable which will replace your normal MCBL-00001 will do the trick: https://docs.modalai.com/cable-datasheets/#mcbl-00095 Purchase link here: https://www.modalai.com/products/mcbl-00095

@erik I saw this discussion (https://forum.modalai.com/topic/4333/compatible-tof-sensor-setup-with-voxl2-mini) now, which answers some of my question. Thank you for getting back on the rest.

@Alex-May , our lenses do not have any IP rating for waterproofing, so we cannot provide any guarantee regarding the performance when exposed to water. Alex

@Jing-Yu This is the tof camera - the ring around it rotates. I'd watch the output on voxl-portal for TOF-IR as you're rotating it to see if it has any impact. [image: 1753801816754-3bf8773e-3633-49e3-b911-ee060a6a5dd4-image.png]

@h3robotics , Yes you should be able to test the Hadron on J8 using the instructions from the docs page (https://docs.modalai.com/voxl2-hadron/) -- just make sure you use Boson sensormodule 4 and ov64b sensormodule 5 (and camera IDs will still be 0 and 1 respectively, if there are no other cameras attached / detected). At this point you do not need to build a custom kernel, just need to use kernel variant 1 because it enables independent camera support on J8 which is needed for Hadron. Please note that you would not be able to use our standard ucoax camera on J8U because the camera reset signal is still not correctly patched through to J8 (which would require a kernel modificaiton). But in Hadron use case, camera reset is not used (both the IR and RGB camera are always on, so it happens to work out ). I agree, it may be more convenient for you to switch to using the M0173 camera front end, so you can use a single kernel variant and also this would be a more future-proof approach. Alex

@wilkinsaf yes unfortunately Gremsy doesn't sell one as of right now and I probably misunderstood your message that said "something is in the works" I though Modal AI working on developing one. Thank you

@mkriesel , the exposure and gain period parameters should be set to 1. They were used a long time ago for Auto Exposure control for ov7251 camera, which would have weird image flicker issues if you updated gain every frame, so we would use ae_gain_period set to 2. The issue with ov7251 was also resolved a while ago and it supports gain period of 1. These parameters specify the update period (in frames) for sending out the new gain and exposure from the AE algo. So these parameters should be set to 1, which is the default for AR0144. There is no practical reason to use any value other than 1. Alex

@smiley , The Boson and Hadron are supported the same way by the VOXL2 camera pipeline (same drivers, camera server settings). You just need to use the correct cables / interposers for connecting the sensor depending on the selection of Boson or Hadron. There is no distinction at all from the VOXL2 SW and it does not know whether a standalone Boson or Boson inside Hadron is connected. Please let me know if you have any other questions. Alex

@Alex-Kushleyev The issue has been resolved. Thank you for your help.

Thanks a million @Alex-Kushleyev that certainly explains the effect - I really appreciate you taking the time

I understand now @Alex-Kushleyev thanks for the explanation

@AidanGallagher , I have updated the IMX412 drivers to support stable 4040x3040 60FPS. Just for full disclosure, the camera in this mode is slightly overclocked from 2.1Gbps / lane to 2.2Gbps MIPI bit rate (voxl2 supports up to 2.5Gbps) in order to allow sufficient time between EOF and SOF. This is within 5% of the camera spec and seems to work fine.. If you do not feel comfortable using this mode, don't :). (only the specific 4040x3040 60fps mode has been changed). We are going to continue testing this mode because it allows doing things like EIS at 4K60 without losing any vertical stabilization margin. If there are any issues with it, I will report back. By the way, for best image quality, even if you don't need 4K output, but lets say 1080p, in the case of unstabilized video (no EIS), you should select 3840x2160 input and 1920x1080 output. The debayering process loses sharpness, so going from 1920x1080 RAW -> 1920x1080 RGB is going to be worse quality than 3840x2160 RAW -> 1920x1080 RGB. For unstabilized video you do not need the full frame because the top and bottom will be cropped out anyway, so reduce the waste and not select the full frame resolution (4040x3040). You can experiment using the different input resolutions to see what output quality (sharpness) you get. There is currently no option to do output sharpening when using MISP, but we will look into in the future. The down side of using higher resolution input is increased GPU usage (should not be an issue) and longer readout time (the rolling shutter artifacts will be more pronounced). https://storage.googleapis.com/modalai_public/temp/imx412_test_bins/20250409/imx412_fps_eis_20250409_drivers.zip - 4056x3040 @ 30 16.5ms readout time - 4040x3040 @ 30, 60 16.5ms readout time - 3840x2160 @ 30, 60, 80 11.8ms readout time - 1996x1520 @ 30, 60, 120 5.5ms readout time - 1936x1080 @ 30, 60, 90, 120, 240 4.0ms readout time - 1996x480 @ 30, 480 1.8ms readout time - 1996x240 @ 30, 800 0.9 - 1.0 ms readout time

Hi @Tamilselvan , you can look at our Starling 2 drone, which comes with either 2 or 3 tracking cameras that can be used for VIO : https://www.modalai.com/products/starling-2 . This drone is designed for indoor navigation but also flies well outdoors. For longer flight times you might want to consider looking at Starling 2 Max. Video using triple camera VIO on startling 2 : https://www.youtube.com/watch?v=12DWDV7XCiE You could build your own drone using components similar to Starling 2, if you wanted. The main camera documentation for Starling Front End board (M0173) is here : https://docs.modalai.com/M0173/ which supports several camera options. M0173 plugs into VOXL2 directly and enables those camera configurations. If you have a custom build drone, you would need to set up PX4 tuning and VIO (Open VINS) to work with your particular camera geometry. For standard drones we have default configuration files that are provided for convenience (so it will be more work to set up the SW after you build a custom drone). Alex

@paul-ammer , sorry for the delay. Initial version of the document that addresses latency in wifi streaming has been published : https://docs.modalai.com/camera-video/low-latency-video-streaming/ There is a lot of information there, please take a look and let me know where you get stuck. I suggest starting to experiment without updating the camera drivers (as discussed in the document), so you reduce number of variables at the beginning. You can also use the Qualcomm ISP pipeline (using hires_front_small_encoded stream) and we can discuss what MISP can be used for at another time. In general, you will find that the majority of the delay is going to be on the receiver side, with some additional delay possible in the server side after the camera pipeline (buffering of the encoded frames before sending them out - I believe gstreamer rtsp server adds some delay. voxl-streamer is based on gstreamer). Regarding the earlier question of unused streams: yes it is true that if streams like large_video, etc, are enabled but not used, they will not consume significant resources, however, if enabled, the stream specifications (dimensions) will play a role when the camera pipeline selects the camera operating mode, which should satisfy requirements of all streams. The most extreme case is when you enable the snapshot at highest possible resolution (but use the snapshot very rarely), and your video streaming resolution is relatively low - the camera pipeline will have to select the camera mode that provides the largest image size (which will be the slowest in terms of latency) and then will downscale to get the video stream of the desired (small) resolution. Please let me know what other questions you may have. I will continue updating the document in order to clarify things and based on feedback. If other users have questions, feel free to follow up in this thread. Alex

@Alex-Kushleyev After updating voxl-portal, it indeed worked. It is peculiar, because I didn't notice the tracking camera freezing before, only the calibration overlay. Thanks for the quick support!

@Alex-Kushleyev , this is fantastic. Thanks so much!