@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

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

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

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

@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

@groupo Exactly

@Eric-Katzfey Sure, Thank you!

@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

@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

@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