Topics created by LucaVertiq

@Alex-Kushleyev said in Voxl 2 mini overheating and rebooting:

@LucaVertiq , did you try disconnecting EVERYTHING from the board and seeing if it boots? Just bare board with power module.

Alex

Yes, the full boot cycles were observed with just the power module and the voxl. We confirmed the voltage at the voxl was 3.8V and not dropping much below that, so no dead short.

@Vinny said in Voxl 2 mini overheating and rebooting:

Hi @LucaVertiq
To me, it seems as if the board went into a power fail condition. Was this in any sort of crash or was it dropped?
LED D2 coming on, then going Off repeatedly is an indication of a continuous reboot cycle (coinciding with your readings of 0.4A, 0A) but there is likely some hardware fault detected by the system preventing it from booting fully.

I had actually just disassembled the vehicle to connect with ADB as we keep the ADB port inaccessible. I had ADB'd in to do some things, then when I reassembled it this began happening. It's quite possible I knocked something loose, or possibly some ESD event.

I've been too busy flying vehicles to get to test the unbricking procedure, but Monday I will.

Hi @LucaVertiq , this is cool stuff. I am curious if you were able to do any direct comparisons of qvio performance using unfiltered vs low pass (rpm-based) vs notch (rpm based)?

In order to replicate the same conditions for each test, this would have to be done using mpa playback after collecting mpa logs of just imu data and images.

since the rpm data is not coming from mpa, it cannot be logged / played back using our logger.

However, one idea is to process the IMU data logs using RPM logs using a separate script and then run the playback + qvio to generate new results. The IMU data processing can have different options like the rpm-based notch filter and it would obviously also need to have a px4 log that contains the ESC status.

This also leads to a question, whether the IMU data should be filtered in the imu server or the application that uses the imu, since the requirements for the IMU data may differ for different applications, so it may be best to leave the IMU server publishing the original data. But also, there could be a separate output pipe from the imu sever with the notch filtered imu data..

Anyway, just wanted to check if you happened to get any quantitative results from your testing that show how the filtering helps with QVIO performance. My understanding from working with QVIO in the past was that the best thing to do was to feed unfiltered imu data into QVIO and let it integrate the noisy data. low pass filtering the IMU data too much would actually remove some of the actual components of motion that are important for motion tracking. So i am curious what exactly has improved in your case when you added notch filtering - is the drift vs distance improved or the number of VIO "blow-ups" has reduced?

Lots of questions, but I am happy to discuss this further and see how we can improve performance of our VIO stack 🙂

Alex

@Alex-Kushleyev Thank you! I'll look through the code a bit harder to make sure I'm not doing anything silly. I'll let you know if I have any more questions.

@LucaVertiq ,

Here is the latest VOXL2 mini nightly SDK : https://storage.cloud.google.com/platform-nightlies/voxl2-mini/voxl2-mini_SDK_nightly_20240415.tar.gz

I just tested by using SDK 1.1.1 as a base and booting using the kernel from the nightly:

adb reboot bootloader fastboot boot qti-ubuntu-robotics-image-m0104-1-boot.img

IMX214 works on all 4 ports. I think you have an option of using this approach or just installing the full nightly. I am not 100% that the latest kernel is fully compatible with everything in SDK 1.1.1, so that is a bit of a risk, so using nightly is a back up option if you wanted to try the SDK 1.1.1 and something did not work as expected with the latest kernel.

If you install the full nightly, use M0054-1 board variant for the voxl2 mini.

Also here are links for the imx214 sensormodule for slot 1 (regular and flip):

https://storage.googleapis.com/modalai_public/temp/voxl2-misc-packages/com.qti.sensormodule.imx214_1.bin
https://storage.googleapis.com/modalai_public/temp/voxl2-misc-packages/com.qti.sensormodule.imx214_flip_1.bin

@Eric-Katzfey Thanks to you we now have our motors running right off the SLPI processor with PX4 as a UART 'bus'. Everything seems to work great. The main issue was figuring out what qshell commands to send to start it up properly.

@LucaVertiq Looking at your voxl-camera-server.conf file, it looks like the configurations are flipped in which tracking should be on camera_id: 0 and hires should be on camera_id: 1. Deleting the camera drivers in /usr/lib/camera and reconfiguring should fix that issue in your voxl-camera-server.conf file

rm com.qti.sensormodule.imx214_3.bin rm com.qti.sensormodule.ov7251_2.bin voxl-configure-cameras 04