@jonathankampia , were you able to first confirm that you can control the gimbal using the actuator test in QGC for the pwm channel 5 (make sure to remove propellers for testing, just in case)? it should work just like any other pwm channel, i am assuming you already have channels 1-4 already set up and working with ESCs? If PWM actuator test is working through QGC, then you have VOXL2 IO board set up correctly and the rest of the logic for actually driving the pwm signal should be the same as for regular PX4 drone (which does not use VOXL). At the end of the day, the VOXL2 IO driver receives 8 channel values from the mixer and just sends the desired pwm values out to the VOXL2 IO board. All the logic above the mixer is standard PX4 and if you have a question about that, you can also try the PX4 forum (since we are not necessarily the best PX4 experts). You can try your python script, make sure propellers are off until you know exactly what you are doing and are ready to fly Alex

@ctitus , I have implemented this change on a branch here : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/commit/591f5683c7e2123c31aaa18af6a87e0c3820bd22 , it seems to be working. I did not add any custom AE mode, since this parameter only applies to the ISP-based auto exposure. Based on your experience, do you see any issues with this approach? It is working fine in initial testing. Perhaps your application is a bit different and you need the custom AE selection. Alex

@Zachary-Lowell-0 Hi, sorry for the late reply. This was the issue (lol)

@groupo yes all the code is open sourced for this exact purpose - if you wish to make updates, you can fork your own instance of the repository - make your edits, compile, flash the deb onto your voxl2 and then provided everythign works as expected you can make an MR on gitlab from your fork to the dev branch and one of us will review and test prior to adding into the next release.

@Moderator [image: 1730146896479-bf357fde-1761-4850-8a9a-4b9ba6c37115-image-resized.png] This is after power cycle (poweroff -f, power source off, turn on again)

@Alex-Kushleyev thanks - I think the voxl-streamer was enabled, but not running. Problem solved, thank you!

@LR Are you able to fly seeker indoor (for which no GPS available) with Position mode? If not, for seeker to use VIO as position estimate you need to use this set of parameter for px4.

@Moderator Alright... What radio would you recommend with the VOXL 2 mini to achieve 3-5km of video communication. [image: 1729875415371-9fe75b9a-4c9c-4273-ab2f-d37f78ab40bd-image.png]

@jonathankampia Edit: managed to fix it by disabling voxl-configure-modem and manually setting the IP of the eth0 interface. I guess 'eth1' is the J11 connector then.

I was able to replicate your issue and also confirmed that the issue goes away if I move the AR0144 camera from the M0084 cable (connected to J7L) to J6L using M0076 interposer. I believe the issue is related to potentially insufficient decoupling capacitance in the IMX214 camera, so running it on the same flex with another camera causes noisy pixels. I hope you can work around the issue by moving the AR0144 camera to another port. Sorry about that! Alex

@Jetson-Nano Thanks for all the help, I really appreciate it.

@itsnav Can I get some help here, team?

@LR Better to get a FrSky transmitter than to try to rework the drone.

@craigphoenix , I think the SDK install is failing somewhere in the middle (but goes unnoticed) and the ESC update and wifi issue is a result of that. We have not see this behavior before, so it is best to send the board back for inspection. Thanks! Alex

@deeplearning361 That is normal, that is how the majority of drone controllers work. You can read through the commando 8 user guide to figure out how to make it self-centering if that is preferred: https://manuals.plus/iflight/commando-8-radio-transmitter-elrs-manual

@itsnav , based on your test, it does appear that the camera itself is not functioning. The camera detection and configuration happens via i2c bus but the image data is being sent via the high speed MIPI bus, so that is why you could have a case where the camera is detected and appears to be running but there is no actual data. It is possible that one of 10 (!) high speed connections is not working (one clock, 4 lanes -- all differential, so x2 number of connections). You should probably RMA this camera unit. I am also curious what dmesg -w will output while you are running the camera server with the non-working camera and trying to inspect the stream. dmesg will output any major issues from the Kernel driver that may relate to the camera not working. Alex

@Alex-Kushleyev Yup, editing kona-perf_defconfig looks to have worked, thanks!

@Rowan-Dempster I think it is safest to just not use data that reads 0,0,0 as the sensor cannot measure that close anyways