Hi @bschulzhf ,

voxl-inspect-cam -a command should not be generally used as it puts a lot of stress on the system. just use it to inspect the stream that you need, such as voxl-inspect-cam hires_down_large_color.

Also, in your camera config changes, it is not clear exactly what changes you actually made, since you did not provide a diff (but i can see that you probably disabled all the streams except for the preview stream). In any case, you should revert your changes and just inspect the stream you need to estimate the latency.

If you want to provide more information about your application, we can suggest appropriate camera server parameter changes. I do see that ae_desired_msv": 60 is potentially too dark (the target average pixel value for auto exposure control) - you can try increasing it and see if the image is too dark.

Alex

@ApoorvThapliyal does my ros2 version on my computer could be an issue. I have ros2 jazzy running on my computer where drone has foxy

Hi @mtcbj
That is the flex stiffener. Our older image modules used stainless steel. Some of our newer modules use laminate.
Those holes are likely just flex/FPC air escapes during the backer lamination process. They do not provide any functional purpose after assembly.
I see no issue filling them with epoxy.
Hope that helps!

Hi @Jetson-Nano
Thank you for your request regarding MTTF and reliability data for the listed hardware components.

At this time, we do not publish formal MTTF/MTBF values for these products. The primary reason is that these systems (VOXL2, ESC, Flight Controller V2, Front-End Board, and Camera Modules) are delivered as development platforms intended for user-defined integration, testing, and operation. In the vast majority of use cases, overall system lifetime is dominated by application-specific factors such as mechanical stress, environmental exposure, power integrity, and crash events rather than intrinsic electronic wear-out mechanisms. As a result, standardized MTTF/MTBF metrics are not representative or particularly actionable for these platforms.

That said, the underlying silicon and design heritage for these systems is derived from high-volume mobile and embedded computing applications. These components are built on technologies that are broadly characterized for long operational lifetimes under nominal conditions, consistent with industry expectations for modern semiconductor devices.

Additionally, portions of the broader technology heritage have been evaluated in demanding environments, including public programs associated with NASA JPL (e.g., Mars Helicopter which is our design heritage, and CADRE lunar rover initiatives). However, detailed qualification data and reports from those efforts and other non-public efforts are not available for external distribution.

From a reliability perspective, our hardware is designed and validated using standard industry practices, including:

Functional validation across operating voltage and temperature ranges Environmental and stress testing at the system level (i..e: we and our customers put our drones into very demanding scenarios) Design margining consistent with mobile/embedded electronics standards, oftentimes far exceeding industry norm Production screening and quality control processes and test screening

For applications requiring higher confidence in operational lifetime, we typically recommend system-level validation under the specific mission profile, including environmental testing (thermal cycling, vibration, shock) and power/load characterization representative of the end use case.

Hope this helps.

@shiva-rv Try heating up the IMU by stressing the CPU then shooting it with air to create a large thermal gradient between the silicon of the VOXL2 and the IMU die itself, I predict you'll see the Z bias jump like crazy, but X and Y not so much.

You might also observe that the temperature gradient determines the bias, not the absolute temperature, hence using a temperature model for compensation is useless, and not applied by modal: https://gitlab.com/voxl-public/voxl-sdk/services/qrb5165-imu-server/-/blob/master/server/src/imu_interface.cpp?ref_type=heads#L168

If you're curious about the physics of why MEMs IMUs like ICM42688 act this way I'm sure your favorite AI chatbot could give you a nice explanation about the materials sciences at play here.

Practically, thermally isolate the IMU component as much as possible.

@Moderator Why is it not plug in play? I found the spot to connect to the board but configuring the SKU based on C29 did not work. Also, the connector seems really short so I am curious how the C29 config looks.

@Alex-Kushleyev Also just noticed the vertical artifact again. The artifact is only present in the snapshots and not the raw images saved as jpeg - will definitely need those post processing scripts now.

Here is the raw image:
5b9ca86b-79b0-4ca3-a317-7c0365efd312-image.png

And here is the snapshot:
2a55882f-b782-4044-8d5d-f0bd7cbe4881-image.png

@Alex-Kushleyev this is super helpful. Thank you.

@Alex-Kushleyev said in C29 Configuration:

https://docs.modalai.com/voxl2-coax-camera-bundles/#kit-pictures-and-descriptions

The flex cable is pretty short, where does the tof sensor get mounted exactly after it is plugged in? I assume it is meant to be downward facing.