@daniel-p-nikolov said in Issue recognizing camera MSU-0107 using M0135 dual camera board: Tried various setups, however, it does not see any camera connected to the VOXL2. Reply @daniel-p-nikolov I would recommend doing a custom camera config setup. What you can do here is run voxl-configure-cameras C and then vim into /data/modalai/custom_camera_config.txt and then proceed to edit the file for this port and position - so in this case it would be J7 lower info is hires, imx412, and false. Then proceed to rerun voxl-configure-cameras C again and then rerun voxl-camera-server and see if cameras are detected. There could be a mismatch occuring of the port and such when using the non custom script. Zach

@perfx I'd recommend reaching out to Ascend Engineering, they're ModalAI product experts and they'll be able to help you out: https://www.ascendengineer.com/

Hi @Alex-Kushleyev , Thank you for your suggestion. Now I understood. how to use my existing stereo, and tracking cameras on voxel-2.

@arcj can you share your working tflite configuration with M0014 and the configuration that is not working with M0025?

@Jetson-Nano Please take a look at the following links: https://docs.modalai.com/M0169/ https://docs.modalai.com/M0178/#requirements https://docs.modalai.com/voxl2-coax-camera-bundles/#mdk-m0173-1-01 [image: M0173_C26_Config.png] M0169 was built to support the new TOF sensor using the existing (at that time) flex cables and interposers, but those were not designed to carry 5V from VOXL2, therefore M0169 requires additional connector to supply 5V (which can be taken from the same APM that is supplying 5V to VOXL2). TOF V2 sensor can output much higher IR power compared to TOF V1, and the existing interposers / power rails were not designed for that, so an additional 5V input to M0169 is required. Now, with M0173 (aka Starling 2 Front End), the front end plugs into VOXL2 and makes use of the available 5V on VOXL2 (which was not possible using older interposers and extension cables). M0171 / M0178 is able to pull 5V directly from VOXL via the Starling 2 Front End. M0178 is basically an M0171 with a tab for mounting. In order to use M0178 / M0171, you have to use M0177 flex that is connected to M0173 camera front end (which plugs into VOXL2). So there is basically two options for connecting TOF V2 to VOXL2: VOXL2 -> (M0135 or M0076) -> (M0074 or M0036 extender) - > (M0169 + 5V power) -> TOF V2 VOXL2 -> M0173 -> M0177 - > (M0171 or M0178) -> TOF V2 I know that is a lot of board numbers, but hopefully that makes sense.. Alex

@Zachary-Lowell-0 Am I using the wrong serial port? Currently set up with TTYHS0 on J10 [image: 1730823460396-f1e6e745-20ab-415b-bb6e-e5a1074ab810-image.png] In the guide its showing the QUPs on J19 being connected [image: 1730823513076-9f406335-3fc6-45cc-a78e-43062a6c2d7b-image.png]

@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.

@John-Nomikos , 1.4 GB/s is certainly impossible for SD card write speed, so there is definitely some trickery going on here. Because VOXL2 has a lot of RAM, the cache can be substantial, but I thought that sync command would solve that issue, but apparently not. In case of writing on top of an existing file, i believe this is a bad test case because as you are changing contents of an existing file (overwriting on top of existing data), the file system needs to be updated to remove references to old data and i think it can be a bit tricky in case of these unstructured overwriting with various block sizes, etc - so this is probably why that process is slower. If you find a reliable way of testing the SD card write speed in the SD card slot, please let us know! I will play around with it as well. Alex

@John-Nomikos Edit: I swapped SD card readers (the original was UHS-I, this one is now UHS-II) and now am seeing 150-200 MB/s for both hats. Speed difference was likely caused by the card reader and not the voxl2. Still weird that there was a speed difference, but oh well

@Alex-Kushleyev, no need for super low-latency FPV, just using a higher megapixel sensor to stabilize down to what we can consistently stream down the radio link. Some form of digital gimbal would be great too, where we can steer the field of view to a specific region

@Eric-Katzfey Sure, Thank you!

@groupo Exactly

@Aaky voxl-tflite-server is a wrapper for TensorFlow Lite. So, anything you can get to work in standard TensorFlow Lite you should be able to get working in voxl-tflite-server https://ai.google.dev/edge/litert

@restore you'll need to use PX4 logs for that

@Inhan-Kang Did you ever resolve this issue? We may have a similar one. Ruled out power issues already by running straight off a powerful 5V supply. It does not reboot though, just goes dark and stops responding over ADB or over the network (we are using Doodle).

@Aaky great to hear, from my experience when the board is booting directly to fastboot it is often a power issue

@Morten-Nissov , About the IMU dt, sorry, i got it backwards, the dt is 0.976ms, so that would be slightly above 1khz. So we are on the same page. Yes, reducing the FIFO size results in more SPI read transactions, which means that the CPU / Kernel has to do more work. There is a per transaction overhead that is much more significant than just getting more data per single transaction. Let's not bother with the PR because it is a 2-character change . I will get to it and test it soon. Alex

@milanerd The added capacitance helps VOXL 2 Mini's USB port achieve USB 3 speeds. We don't have that adapter to confirm a fix for your issue, but with the cable the link should transfer much faster

About 95C is when the temperature control loop will kick in and start reducing the maximum core frequencies (gradually). You can monitor the cpu usage and current core frequencies using voxl-inspect-cpu. Here are the maximum core frequencies for all cores: cpu0 1804.8 cpu1 1804.8 cpu2 1804.8 cpu3 1804.8 cpu4 2419.2 cpu5 2419.2 cpu6 2419.2 cpu7 2841.6 If you set the cpu governor mode to perf (voxl-set-cpu-mode perf), it will pin all the cores to max frequency and they will stay there unless they are being throttled due to temperature, which you can check using voxl-inspect-cpu.