ModalAI Forum

@zaimin78 , It looks like I got this working. I modified the kernel to do the following not use the combo mode for J6L and allow using J6U as independent camera GPIO109 is used as a shared reset for cameras in slot 1 and 3 (because that's how the signal routing works on VOXL2 + M0135), so the kernel knows that this reset pin is shared this setup is not set up for camera sync - all cameras are running independently I have not tested any cameras in J8U, it may not work - but it should be possible to enable it, just need to test it. You will need to update the kernel on your voxl2: https://storage.googleapis.com/modalai_public/temp/quad_ov7251_boson/qti-ubuntu-robotics-image-m0054-boot-quad-ov7251.img this kernel is based off the kernel that ships with SDK 1.6.3 you can test it before overwriting the current kernel: https://docs.modalai.com/voxl2-kernel-build-guide/#test -- you should do to reduce the chance of bricking your VOXL2 (just in case) HW Configuration: VOXL2 four OV7251 plugged in to J6L. J6U, J7L, J7U via two M0135 adapters without any mods boson320 plugged into J8L via M0194 (you can use M0181 also) there are no shared CCI buses between the ov7251 cameras - slots 0-3 use CCI 0-3 respectively, so no CCI slave address conflicts SW configuration appropriate sensormodules placed into /usr/lib/camera/ -- you can get them from /usr/share/modalai/chi-cdk/ov7251 and ../boson folders: com.qti.sensormodule.ov7251_0.bin com.qti.sensormodule.ov7251_1.bin com.qti.sensormodule.ov7251_2.bin com.qti.sensormodule.ov7251_3.bin com.qti.sensormodule.boson_4.bin use provided voxl-camera-server.conf : https://storage.googleapis.com/modalai_public/temp/quad_ov7251_boson/voxl-camera-server-quad-ov7251-boson.conf may need to modify your Boson resolution from 320x256 to 640x512 if you you have Boson640 Testing after you have all the cameras connected, boot using the test kernel test to see if all cameras are detected: voxl-camera-server -l ... DEBUG: Cam idx: 0, Cam slot: 0, Slave Address: 0x00E2, Sensor Id: 0x7750 DEBUG: Cam idx: 1, Cam slot: 1, Slave Address: 0x00E2, Sensor Id: 0x7750 DEBUG: Cam idx: 2, Cam slot: 2, Slave Address: 0x00E2, Sensor Id: 0x7750 DEBUG: Cam idx: 3, Cam slot: 3, Slave Address: 0x00E2, Sensor Id: 0x7750 DEBUG: Cam idx: 4, Cam slot: 4, Slave Address: 0x00D4, Sensor Id: 0x00FF ... start voxl-camera-server inspect sterams: voxl-inspect-cam ov7251_0 ov7251_1 ov7251_2 ov7251_3 boson [image: 1785341477366-ee693f10-dcf2-4b76-8181-a11a78db9546-image.jpeg] Please give it a shot and let me know if it works! Alex

@moderator Any reply will be much appreciated.

That red light is for the M0184 ELRS receiver. A constant slow blink from the light means it is disconnected. It will turn solid with a connection. Other LED states are documented here.

What i meant was that sometimes, depending on the frame design, the orientation of the cameras may change slightly over time. This can happen as the plastics can change shape due to exposure to heat, sunlight, humidity (depends on the plastics), bumps and crashes, etc. Additionally, there has been some research showing that the camera + lens intrinsics change over time / temperature, especially if the lenses are made of plastic (which is the case in our old OV7251-based fisheye modules, which use plastic lenses - although we have not characterized them vs temperature). It is possible to use stiffer and more stable materials (metals, carbon fiber) to ensure that the sensor mounting remains consistent over time. I hope that answers your questions. Alex

@patkirkmartin , let me double check with the team what the process for this will be and the timeline. I will get back to you soon. Since the plan would be to provide the source to the public, it would be posted on gitlab, the feature-related discussion can happen there. We will certainly be able to help review the code and perform some testing. Alex

Starling 2 Max is designed for 4S batteries only (two 2S Li-Ion battery packs, which are connected in series inside the vehicle). The Mini ESC, which also acts as a power source for VOXL2 inside the Starling 2 Max, is rated at least for 4S input (depending on the version of the ESC). There are several versions of the Mini ESC to provide the users some flexibility, in particular the voltage of the VOXL2 regulator (5V for VOXL2 and 3.8V for VOXL2 Mini). Since Starling2 Max uses a VOXL2, the ESC part number will be either M0129-5 or M0129-65. An updated (6S) version of the Mini ESC was released after the release of Starling 2 Max (new ESC part numbers: M0129-63, M0129-65). This ESC update extended the supported voltage for the ESC (not for Starling 2 Max) from 4S to 6S. The 4S version of the ESC has been phased out because the 6S version outperforms the original version even at 4S voltages (due to better Mosfets), so the 6S version is an improvement over the original 4S version of the ESC, while being fully backwards compatible. Using the 6S-rated ESC in the 4S-rated Starling 2 Max is completely safe. If you use the Mini ESC outside of the Starling 2 Max, you need to verify the part number / sticker on the ESC before plugging in 6S battery (M0129-63, M0129-65 only) The ESC variants and part numbers are documented here : https://docs.modalai.com/voxl-mini-esc-datasheet/ Alex

Hi @electroAJ, thanks for the detailed writeup and follow-up SKU info. From a hardware standpoint, the 200mV droop you are observing on VDC_5V_LOCAL and VDC_5V_LOCAL_USB1 during ToF activity is not a concern at the rail level. That kind of transient is most likely localized contact/pin loss at the connector interface rather than a bulk supply issue. On a 5V rail, 200mV is well within normal operating margin. The eFuse on that rail does not assert until approximately 4.4V, so a 200mV droop from 5V puts you nowhere near that threshold. Downstream logic is regulated from a 3.8V VBAT rail that has demonstrated margin well above the minimum needed, and that rail is permitted to droop past 3.3V before any real issue occurs. The ToF-induced droop is not your RC dropout culprit. Additionally, the M0129 VOXL Mini ESC power stage has been proven to the same load capability and test rigor as our standalone M0041 power module, using the same parts, so the supply itself is not a suspect to me. Would hate to see you chase a red herring. The I2C errors and UART dropout sequencing are worth looking at together as they may share a common upstream cause. Beyond that, this one is likely better handled by our software team who can dig into the dmesg and service state in more detail. I will flag this thread for them.

@Ben-Linne I'm likely able to perform those updates. A fix is good, but root cause understanding of the issue is better at this point, so I will try updates once all other debug opportunities are spent if I can't reach a deterministic resolution. receiver antenna [...] understood and checked out. I've confirmed the umcc(u.fl) connection is fully seated and no damage is present anywhere. If the transmitter is showing signal but the drone is not responding it's possible you are bound to another transmitter. this is a state I will confirm. So far though, I believe the failure mode is observable with no other transmitters powered, but i will confirm. Thanks.

@alex-kushleyev @ModalAI-Team . Could you guys help me with this? thank you!

@Alex-Kushleyev Hey Alex. Thanks for this input. I will incorporate your feedback as we continue initial motor testing and let you know if we need further guidance. Much appreciated!

That'a a calibration parameter that is set automatically by the mag calibration procedure. Normally it should properly detect the orientation / rotation and set it. I'm not sure why that wasn't happening for you when you calibrated the mag.

@Vinny we recently experienced wifi disconnection issue with the m0213 board. During flight the wifi just completely disconnected with does not regain connectivity. It seems that the wifi chipset stopped working. We had to do a complete power cycle to regain connectivity. It happened several times during our test. Could you suggest how to resolve this issue? Or is there a way to do soft-reset of the board if we detect wifi connectivity loss?

@emarcphera Thanks for the info! What antennas do you use for your setup if you don't mind me asking?

We are having the same issue on our C28 config.

Same here, mine died after about 40hrs of operation. I suspect is thermal damage

Yes, the beta release is fine. It was beta only for some features that are not used on our development drones. Otherwise it was a stable release.