@stephengerdts , in majority of cameras, the exposure time of the whole frame is set as a multiple of a specific number, let's call it T0. T0 is the minimum exposure of the whole frame and you can set any other exposure values, which will get rounded to a multiple of T0 ( K*T0 ). This T0 number is actually exactly equal to something called the Line Readout Time, which is the time it takes for the camera hardware to sample, process and send out a single line of pixels. This may be a little confusing, but if you think about how rolling shutter camera works, it "reads out" one line at a time (it cannot store the whole image in memory, so exposure and read out of each line are staggered). Please take a look at this link that shows how exposure time relates to readout time : https://www.researchgate.net/figure/Timing-diagram-of-the-CMOS-sensor-array-shown-in-Fig-2-The-readout-times-of-the_fig2_3328923 I believe that in order to simplify the exposure timing logic, the cameras then use the readout time as a unit of increment for the exposure time. So, the minimum exposure time reported by the voxl-camera-server is the minimum exposure time for the whole frame, which is also equal to the readout time of a single line In case of IMX214, the line readout time is 10.449us which is also the increment for adjusting exposure. The logic inside the camera framework will take the desired exposure time from the user / voxl-camera-server and then set the correct integer number of exposure in terms of "lines" (not microseconds) in order to achieve the correct exposure duration in units of time. Alex

OK all shipped ok. Above looks good with flat on table test results... Here's factory test data which shows OK: [image: 1721926383343-0a21b33e-3335-48ba-b756-2a84a9b9f6f9-image.png] 2024-05-03T22:01:18.648Z -- {"desc": "IMU1 - APPS PROC - OK", "GYRO_X": 1.001, "GYRO_Y": 0.998, "GYRO_Z": 0.994, "ACCL_X": 0.99, "ACCL_Y": 0.987, "ACCL_Z": 0.957, "FAILURES": []} 2024-05-03T22:01:19.361Z -- {"desc": "IMU0 - SLPI ACCEL - OK", "ACCL_X": 0.11492, "ACCL_Y": 0.20016, "ACCL_Z": 9.89428, "FAILURES": ""} 2024-05-03T22:01:19.960Z -- {"desc": "IMU0 - SLPI GYRO - OK", "GYRO_X": 0.02435, "GYRO_Y": 0.03108, "GYRO_Z": 0.00174, "FAILURES": ""} If it passes flat on table I think things are OK and it's a result of expecting certain tests to run in this flat orientation during factory test.

@QuiroJ6427 I'd recommend just downloading the latest SDK from downloads.modalai.com and installing it. The latest for M500 should be SDK 1.2.0. 0.9 is quite old at this point so this will be a nice upgrade regardless

@jonathankampia You could run UART based comms like an external flight controller on that UART: https://docs.modalai.com/voxl2-external-flight-controller/ but no you couldn't connect a USB device there

@modaltb Thanks for the response, Travis. My manager told me in the mean time, he is in contact with you regarding that topic already via mail. I think we'll focus on that, instead of having 2 communication channels

@Vinny That's really helpful information, thank you!

@jameskuesel Support for more framerates was added in voxl-camera-server v1.9.3 Here is the commit it was added: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/commit/9a3f042ad607b968d452303dd108ced3cf2c4328 I recommend you update to the latest SDK

@rogerli vibration and lead to the lenses rotating. I often use a dab of hot-glue to hold the lens in place after focusing. On the new Starling 2 and Starling 2 Max drones we now use a clamping ring around the entire camera and lens assembly to lock them in place.

@Prasanth-Kumar-Duba What hardware are you using? VOXL 1? VOXL 2? I'm guessing VOXL 1 based on the opkg reference. You can install voxl-mapper by doing the following: adb shell opkg install voxl-mapper

@Scott-Lobdell That would be great, thank you.

see https://forum.modalai.com/topic/3640/ardupilot-on-voxl2

@Kris I found and fixed a bug in voxl-camera-server that seems to be the culprit. I flashed my seeker with SDK1.2.0 and sideloaded the following voxl-camera-server with the bugfix to re-enable ingestion of TOF data into voxl-vision-hub http://voxl-packages.modalai.com/dists/apq8096/dev/binary-arm64/voxl-camera-server_1.9.7_202407111658.ipk Note VOA simply does not work in the default PX4 acceleration-based position mode so MPC_POS_MODE needs to be set to 0 (velocity control) as done by the voa_enable px4 param helper file here: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-px4-params/-/blob/dev/params/v1.14/voa_helpers/voa_enable_indoor.params?ref_type=heads

@Memmed-Shamurov we have draw.io based drawings here if you want to try to mock something up for review, we can take a look: https://gitlab.com/voxl-public/support/drawings VOXL2 Mini based drawings here: https://gitlab.com/voxl-public/support/drawings/-/tree/master/M0104

@Memmed-Shamurov it claims USB Video Support so it 'should' work although we've not tried this exact one.

@Gary-Holmgren Check out the AprilTag Relocalization page Basically, every time an AprilTag is viewed, the position is updated to reflect that tag as an anchor. So, it's not precision landing as much as position refinement. You then land at the desired position which should be more accurate due to the position refinement with the fiducial marker We haven't looked at the MAVSDK in a while, is there a specific error you're running into?

Great @jacob-yaacubov. Sorry for the issue overall, but glad we made it right.

@Gary-Holmgren Hi Gary, we have not thought to try that setup as HITL is typically used to develop the lower level flight controller. What are you trying to achieve?