Thank you for the quick reply.
I will try doing as you instructed and post the results.

Thank you.
Kim

@RyanH ,

Sometimes there is small pieces of random magnetic debris that gets stuck in the motor.

First, you could try using compressed air to clear out the motor.

Additionally, It could help to spin the motor up and down using voxl-esc command line tools a few times to clear it out (without prop is best, just for safety). Spinning the motor without prop a bunch of times could get the debris dislodged and actually broken up by the moving motor parts, so that the debris is no longer large enough to cause a problem. Reversing motor spin using voxl-esc test tools can help dislodge the debris (you can commend negative power/rpm).

You can find useful info regarding motor testing here : https://docs.modalai.com/voxl-escs/faq/

Alex

@restore , the change to enable the maximum resolution raw output for OV64B was made at the end of October 2025, so you would need at least SDK 1.6.0, I believe. There was a change in the camera pipeline (not the camera driver) to allow such a large image size. Are you able to test on a newer SDK (just test the latest if you can)?

Additionally, the resolution 9248x6944 cannot be directly used in MISP debayering (which uses OpenCL). There are some special requirements on the image stride, which width of 9248 does not match. So what will happen is the cpu will realign the image before feeding it to the gpu, but it is a lot of data to copy for a 64Mpix sensor. So I made a small change in width from 9248 to 9216 (just cut off 32 pixels) and it can be fed into the gpu directly. That change is not published yet, but i can share it.

Lets first confirm that you can use the 1.6.x SDK to start the camera server at 9248x6944 and you should be able to save raw bayer and view the misp output.

you can always double check the list of available raw resolutions using voxl-camera-server -l

by "start the misp output stream", i mean that you need to have a client that subscribes to the misp output stream, so that the frames start going and AE can work, sending exposure and gain updates to the camera, so that the image is properly exposed. For example, viewing the stream in voxl-portal or just using voxl-inspect-cam hires_misp_color to get the data flowing, then you can save the raw bayer, which will have the proper exposure and gain applied.

Alex

@syamala-kotireddy ,

If the ESC is not showing any signs of life (no blue led blink), it probably means the ESC power regulator is not working properly. However, you mentioned that VOXL2 is actually booting fine? Can you measure the voltage on the connector / pads that provide 5V power from M0129 ESC to VOXL2?

Please see the following post, where a capacitor on the ESC next to the main voltage regulator was knocked off, resulting in ESC not starting up. https://forum.modalai.com/topic/4151/voxl-mini-4-in-1-esc-missing-capacitor/ . However, in that post, i think VOXL2 was not booting either. In your case the issue may be something different.

It is worth carefully inspecting the ESC.

Also, if you have a power supply that can measure current, you can set it to 8V and measure the current draw of the ESC alone, it should be very small (maybe 20-30mA) but not zero.

Alex

@tom Thank you!

@cbay , yes this should work.

Whenever you add cameras of the same type, you should always check for possible I2C (CCI) conflicts. If you look here https://docs.modalai.com/M0188/#image-sensor-interfaces , the sensor IDs 0,2,3,6 (which is what you use) use unique CCI buses 0-3, so that is all good.

If you used ID 1, it would conflict with with another AR0144 on ID6 (both use CCI1)

One last thing to check is the sensor sync.

if you see fsin in the configuration of the sensor (and name of the sensormodule in /usr/lib/camera/), it means it is set up as a sync slave currently you have the IDs 0 and 6 set up as sync slaves, but ID 2 and 3 as free-running

There are two issues enabling sync'ed drivers for AR0144 in ID 2 and 3:

the driver is provided only for ID2 in : /usr/share/modalai/chi-cdk/ar0144-fsin/ - this is easy to fix ID1 and ID3 on M0188 do not have the sync line connected to the camera connector this is easy to fix by installing a 0-ohm resistor, which is DNI by default.

Depending on your requirements for VIO (which VIO are you using?), you may or may not need the cameras synchronized.

Please let me know your requirements and we can go from there..

Alex

@Daehan-Won The mb12xx px4 driver is not in our build so you would need to add it to the voxl2-slpi build. Which pins are you attaching it to on J19?

Hi @irw ,

This seems like a hardware issue, potentially related to PMIC. Are you able to share full dmesg output from boot, when this issue is happening?

One thing to try would be to disconnect M0173 board from VOXL2 and see if you can reproduce the same messages related to cam_sensor*power_up -- these are definitely not normal. Perhaps there is a short on one of the camera power rails, which is preventing PMIC from working properly.

Alex

@Noah-Heinen , unfortunately it is not possible to add a TOF sensor to your current Voxl2 Mini configuration. M0188 adapter does not support TOF.

The only way this would be possible is:

remove M0188 add M0172 and connect TOF and either M0186 or M0166 camera add another M0172 or M0194 and plug in a single camera. Unfortunately right now we don't have a small adapter like M0172 or M0194 that supports two standard cameras like M0166 or M0186.

So you would probably be losing one of the tracking cameras if you want to add a TOF sensor.

Alex

@Michael-Soul , it is EAR99

Hello @adam , please see the following post regarding GPS signal quality on Starling 2 and Starling 2 Max : https://forum.modalai.com/topic/5116/gnss-emi-mitigation-guidelines

There is no voxl-gps service - voxl-px4 handles the GPS functionality, so as long as that is running, the GPS module should be active. Please go through the documentation linked above, there are some mitigation steps that are relatively easy to implement.

We apologize for the inconvenience, but enabling usable GPS on Starling 2 will require some tweaks.

Alex

@wilkinsaf

I did the following and was able to get it

installed arducopter 4.7 disabled serial2_option for mavlink forward configured compass configured acceleromter turned off GPS_AUTO_CONFIG set SERIAL3_BAUD to 115200

https://www.loom.com/share/b96c3edd2286477ea294ddbd262dc31e

@fhaltmayer , it looks like there maybe something missing from /usr/lib/camera/, as the camera is detected by the i2c probe but not accepted by the system.

Can you please let me know how exactly the camera is connected (to camera slot/id 2, it seems) and also list all the contents of /usr/lib/camera/.

Alex

@ktrieu , you can find the STEP file for the M0166 camera module here : https://docs.modalai.com/pcb-catalog/

@Nikos-Mavr I have an extra ac1300 to use that lsusb recognizes but I don't think the driver is implemented. Ac600 Antenna might be malfunctioning after all because even if it lights up on other pcs and identifies WiFis it cannot connect. Is there a way to implement a driver for ac1300?

@austin-c , The GPS driver is built for SLPI as well as APPS PROC, so you could connect it to a apps-proc UART and start the driver on the apps proc side of PX4.

This was done on RB5 : https://docs.modalai.com/Qualcomm-Flight-RB5-linux-user-guide/

https://docs.modalai.com/voxl2-linux-user-guide/

Regarding magnetometer, just like with the GPS driver, you should be able to enable the mag driver to build for apps proc. Since the apps proc i2c uses standard posix interface, it should just work. However, i don't think we have ever tried it.

Alex