ModalAI Forum

@tom Hi Tom, thank you for the prompt response. It is much appreciated.

Hi @alex-kushleyev , Thank you, the software slave-address change sounds great. If it works, we would prefer that approach, since all five cameras could then be standard M0166 units (easier spares and no warranty issue). A few follow-ups: Does the changed address persist across a camera server restart or a sensor reset, or only until reboot? (We noticed the OV7251 runtime address swap skips sensor resets for this reason.) Will the kernel change be included in an upcoming SDK / system image release, and does it work together with the fsin (sync) sensormodules? We will keep the pre-modified M0166 as a fallback. Please let us know the result of your test. Regarding AR0144 vs IMX412, the reasons we chose AR0144 for all five visual cameras: Same-instant 360° capture: Our goal is to capture like a 360° camera, where every direction is captured at exactly the same moment. Global shutter plus hardware sync on all five cameras is the key requirement. With rolling shutter, each row is exposed at a different time, so motion causes skew and the frames from different cameras would not truly match. Stability over resolution: Reliably getting synchronized frames from all directions, quickly and without drops, matters more to us than image resolution. The 162° fisheye also gives five cameras enough overlap to cover 360°. Portable device: The system is meant to be portable (handheld), so weight matters, and hand motion makes rolling shutter artifacts more likely. So our target configuration remains 5x AR0144 for 360° capture plus one thermal camera, as in our test request (Test A: Lepton 3.5, Test B: Boson+ 640). We will choose the thermal camera based on your test results, so it would be great if both variants could be covered in the test. One more question: we may need color images. Is the color AR0144 variant (M0166-2) available, and would 5x color AR0144 with sync and CPU debayering at 1280x800 @ 30 fps be feasible on VOXL 2? Thanks!

Hi @김다연 On that same page is this link [image: 1794541383152-a2f37d2d-c828-4f32-84f2-63440b85c7d7-image.jpeg] It should have all the info you need.

Going to close this ticket out since it seems to have resolved the issue for the user

@juancho248 Sorry for the delay, please see the answers below: @juancho248 said: Which Starling 2 Max configuration provides the most suitable high-resolution RGB cameras for our application? All versions of Starling 2 Max come with dual IMX412 cameras (one front-facing, one down-facing). @juancho248 said: Is the C29 configuration currently supported, and what are its camera and depth-sensing capabilities? yes, c29 is supported. Note that TOF (depth sensor) does not work outdoors due to sunlight @juancho248 said: Can the RGB cameras be configured for downward-facing image acquisition? The rear IMX412 is already down-facing. The front camera is forward-facing, so you would need to make modification to make it down-facing @juancho248 said: Can the platform capture full-resolution still images programmatically, rather than only video frames? Yes, you can capture full resolution images, including RAW10 , which can be processed offline for best results. Processed YUV also supported. @juancho248 said: What camera controls are available through the SDK, including exposure, gain, image format, resolution, and capture timing? exposure, gain can be changed in real time. resolution can only be changed before camera server is started, but we support multiple streams with multiple resolutions (so you could have one full resolution stream for sparse captures and lower resolution for video feed). SW zoom is also available for processed images (YUV and video). @juancho248 said: Can captured images be associated with timestamps and available vehicle pose or localization metadata? yes, each image has metadata, including timestamp, exposure, gain. The timestamp is using linux monotonic time, which can be correlated with other data sources that are logged with same time source. @juancho248 said: What onboard storage options and image-transfer interfaces are supported? built-in storage (EMMC 120GB split into two partitions, typically at least 80-90GB free on a fresh system install - dont remember the exact number). you could support USB-based storage as well. Transfer images can be done using the USB / ADB interfrace. The adb itself is slow (<5MB/s) but a usb-ethernet can be enabled on the same USB connection, that is typically ~35MB/s transfers. If you use wifi on the drone, that is also an option. wifi speed depends on typical factors. @juancho248 said: Can images be stored locally during a mission and transferred after landing without requiring continuous Internet connectivity? Yes, as long as you don't run out of local storage. Note that RAW10 images from IMX412 at full resolution (4040x3040) are about 15MB each. YUV of the same resolution are 18MB each. You can also compress them to JPG on voxl2. Please let us know if you have any other questions of if I missed anything. Alex

Hello @elvis-bicharri , Please take a look at the updated Starling 2 Max C29 V4 model : https://storage.googleapis.com/modalai_public/modal_drawings/MRB/D0012-Starling-2-Max-C29-V4-20261112.STEP You should be able to see all the sub assemblies and parts labeled now. Also, the model size (MB) is reduced. Please let us know if you need anything else. [image: 1794462369745-68e2b39c-c885-4c17-aa24-ed28cb1c7da5-image-resized.jpeg]

Hi @kdeshmu2, the PX4 uORB message reference has a page per message with field descriptions and units where PX4 defines them: https://docs.px4.io/v1.18/en/msg_docs/ For the motor topics on Starling 2 (VOXL ESC), we added a table here: https://docs.modalai.com/voxl-px4-files/#logged-topic-contents In short: actuator_motors: motor commands from the control allocator, normalized 0 to 1 actuator_outputs: the same commands scaled by the voxl_esc driver to RPM, between VOXL_ESC_RPM_MIN and VOXL_ESC_RPM_MAX esc_status: ESC feedback per motor (measured RPM, voltage, current, temperature, power) The voxl_esc driver source is here if you want to see exactly how the outputs are produced: https://github.com/modalai/px4-firmware/tree/voxl-dev/src/drivers/actuators/voxl_esc

Hi @K.Stute, IMX377 never became a supported sensor on VOXL 2, and the M0026 IMX377 module is end of life. What is on the board today: The system image ships a sensor module driver for IMX377, but only for camera slot 3 (J7 upper, which is M0084 JU): /usr/share/modalai/chi-cdk/imx377/com.qti.sensormodule.imx377_3.bin voxl-camera-server has no imx377 sensor type, and none of the standard camera configs use it, so voxl-configure-cameras can't set it up. The sensor types the server accepts are listed in common_defs.h. If you want to experiment anyway: copy that bin into /usr/lib/camera, plug the camera into J7 upper, check dmesg for imx377 probe succeeded, then start from an IMX214 hires config on slot 3 and change the resolutions to match the IMX377. That is untested on VOXL 2 and we can't support it. For a 4K hires camera on VOXL 2 we recommend the IMX412 (M0107 or M0161). It has drivers for several slots and is used in the standard camera configs. See VOXL 2 Image Sensors and VOXL 2 Camera Configs.

Hi @chris-pagnotta , yes it will work using M0181 adapter (provided in the kit) connected to VOXL2 J8. Please let me know if you need more details. Alex

Hi @mrawding , sorry for the delay. Unfortunately, we do not offer narrower FOV lenses for AR0144. You could try to find M7 thread lenses from 3rd party sources. It is probably easier to find a new lens than to make an adapter for a 3rd party camera module.. would be impossible for us to support it. Alex

Currently, none of the Thermal cameras (Boson) we support use hardware synchronization. The same is true for the EO cameras (IMX412, IMX664, etc). Only AR0144 cameras are currently enabled with sync input and correct sensormodule for the camera needs to be selected (either _combo or _fsin). Sorry this is a bit vague, not sure how detailed we need to discuss here. Also, please note that you cannot connect a thermal camera (Boson) via M0155 - this adapter is only for EO cameras. there is a difference in pinout and voltages provided. Please see https://www.modalai.com/products/m0155, it lists supported cameras. If you let us know what functionality you are trying to achieve, we can provide more guidance. Please describe all the cameras that you want to connect and which should by sync'ed. Is it only one EO or one IR (which)? Alex

Hello @ישראל-בן-שלמה , Sorry for the delay in the response. Please see below: @ישראל-בן-שלמה said: Can two M0166 no-IR cameras facing different directions be used by the supported VIO software, alongside simultaneous M0161 EO capture? Does VIO use both tracking cameras, or only one? Yes, our voxl-open-vins-server used multiple tracking cameras, if available. this is default in several of our setups. Besides that, M0161 can be used for video streaming and capture. We are also working on integrating rolling shutter cameras for VIO. @ישראל-בן-שלמה said: What carrier, ports and cable part numbers support this combination? Please point us to the applicable SDK version and camera/VIO configuration. Your configuration (2x AR0144, 1x IMX664) is C33 (see https://docs.modalai.com/M0195/). So you will need: VOXL2 Mini M0195 (M0188 would work too for this configuration). Main difference between them is that M0195 has support for a thermal sensor (e.g. Boson) 2x M0166 + ucoax cable 1x M0161 + ucoax cable If you are starting fresh, you should use latest released SDK. I will double check.. @ישראל-בן-שלמה said: We’re also considering upward/downward ranging and one or two forward multizone ToF sensors. Which ModalAI modules and simultaneous connections are supported with the above camera configuration? Will check @ישראל-בן-שלמה said: Are board/cable weights and mechanical drawings available for the required parts? yes, you can find the weight and 3D files: https://docs.modalai.com/M0166/ https://docs.modalai.com/M0186/ https://docs.modalai.com/M0188/ (any thing else? let us know we can fill in the missing info)

VOXL 2 Image adapters handle all needed connections to our Image sensors. We cannot give guidance on designs used to replace a VOXL.

We measure RPM using the ESC, it's very accurate and part of our testing qualification on each board, it's very accurate. We do not use any other form of tach.

@zachary-lowell-0 That worked perfectly, thanks!

Assuming your Stinger SKU contains an ExpressLRS modem (ModalAI M0184 Gemini RX), you will want to follow the ExpressLRS Binding procedures. Firstly, to put the receiver into "binding" mode, you'll want to either press the bind button for at least 1.5 seconds, and you must do this at least a few seconds after the battery has been inserted (or anytime later). You can also put the receiver into binding mode by powering on and off the Stinger 3 times quickly, though this can be unreliable. You will also need to make sure your transmitter is compatible with the receiver, and in a compatible mode. The M0184 by default comes with firmware based on ELRS 3, so you will need to verify that your GX12's internal ExpressLRS firmware is also on major version 3, otherwise you will need to downgrade to V3. Furthermore, the GX12 comes with a dual-band transmitter which supports 2.4GHz and 915MHz operation. To work with the M0184 you must make sure the selected "RF Band" parameter is "915 MHz", and the packet rate is 50 Hz 100 Hz, or 200 Hz. Other packet rates are not supported on the older modem in the M0184.

Hi @김다연 Both are enabled by default. If a QUP appears in the table with a device node, it is enabled in the shipped image. No device tree changes or additional hardware configuration required. UART7, J3 pins 3 and 5, /dev/ttyHS1, sys image 1.3+ UART13, J5 pins 97 and 98, /dev/ttyHS3, sys image 1.5+ Full table: https://docs.modalai.com/voxl2-qups/ Note UART13 requires system image 1.5 or newer. Check voxl-version on your unit before wiring it up.

Hi @alex-z-1 Here is the STEP for the front tracking mount: https://storage.googleapis.com/modalai_public/modal_drawings/D0013_Front Tracking Mount.step Note this is the V1 plastic. The V1 Stinger has been EOL for some time, so this came out of archived CAD rather than a current release. One observation from your photos: the film is still on the battery pad. That likely contributed to the battery stop breaking, though it would not have saved the camera housing. Let us know if this helps!