@Chad-Sweet still trying to figure out the best way to update the module. I would appreciate some guidance on the process, I mean do I have to build using voxl-emulator docker and upload the particular module ?

I tried it on Ubuntu 20.04 as well, but it gave the same message as in Ubuntu 22.04. I also tried it with an older commit from the voxl-docker repository, but that also gave the same message. Does it have to do with the files that need to be downloaded and put in `cross_toolchain/downloads? Do I need to install something else?

OK, no problem. Since this is resolved on your end, i did not verify the simple fix of just disabling ADSP using systemd, but the what did work in the past was disabling the ADSP using systemd AND makding the device tree change I mentioned above. Just to clarify what is happening, the GPIO can be accessed from CPU and other sub devices in the SoC and in this case if ADSP is enabled, once ADSP starts up, it configures those pins for some audio clock/data functionality and CPU loses control over them. The behavior is such that during the system boot, the CPU initially (first few seconds) seems to have control over the pins, but then ADSP starts up and takes over, and it even sends some clock/data on these pins (a short burst). Therefore, disabling ADSP allows CPU to maintain control over these GPIO pins.

Hello @MartinP , I believe here is what is happening in your case: Your sensor (Lidar) is sending data continuously without any breaks (360 degree lidar?). Maybe the Lidar processes each measurement and sends it out right away, so perhaps there are small breaks between the data measurements The hardware UART buffer size in VOXL2 is set to 2048 (based on the data chunk size you get) You are using the High Speed uart port (HS in the ttyHS1), which uses DMA to transfer data to cpu (one cpu interrupt per buffer) Typically, the DMA-based UART hardware decides when to send the data to CPU when one of several conditions is met: there is a long enough break in the data stream that can be considered end of "packet" or the current data buffer is full (2048 in this case) Since it looks like the data from Lidar is coming without long breaks, I see several possible solutions: If possible, configure the Lidar to have a break between each scan (but you would need to know the minimum break size for UART hardware to trigger a rx interrupt to CPU) reduce the rx buffer size for UART (probably somewhere in the Device Tree) However, it would be helpful to understand what the data transmission from Lidar looks like. Also, please note that increasing the baud rate of the communication will probably not help. Significantly increasing the baud rate may result in potentially rx interrupt triggering on each measurement, which would not be very good for the CPU.

@m1baldwin With that platform release PX4 crashing causes ADB to crash as well, so that's one possibility. (This is fixed in future releases) If it was a camera issue, that would be low level device tree code causing the crash

Thanks for the info! Just to confirm, I am asking about this post ModalAI made on LinkedIn - https://www.linkedin.com/posts/modal-ai_voxl-tof-pmd-activity-7010997849232474112-VV6a?utm_source=share&utm_medium=member_desktop This update is almost a year out? Thanks.

hi Eric, Is there any update on the issue? Thanks. suvasis

You will need to modify the code to make use of your new model. You will need to code the tflite-server to both read the model, and then post_process the model based on the inputs and outouts of your model https://gitlab.com/voxl-public/voxl-sdk/services/voxl-tflite-server/-/blob/master/src/main.cpp#L196

Ok, thanks! So is there no available vSLAM implementation at the moment?

Thanks for the response. It worked !!

@Chris-Hinkey When we test throughout, we use iPerf. With USB2 only, we see it runs at about 340-380Mbps ( makes sense with overhead losses, etc). If you do the same type of testing, you can quickly tell if despite enumerating at USB3, only the USB2 signals are working. I'm not sure if your issue is HW or SW related, but for certain that cable is not correct. I tried to purge them from our inventory when I saw them but some made it out. With the new cable on the way, you should certainly get much better throughput. We can't guarantee greater than 3-5Gbps though since the new cable is still a prototype and has no shielding required to get full 10Gbps USB3 rates. I have that note on our cable tech docs page. Let me know when you get the replacement then we'll know better if there is some SW issue also occurring. Thanks!

hi @suvasis #test voxl-esc tools cd /home/root/voxl-esc/tools ./voxl-esc-scan.py #perform ESC testing / calibration #... this was just a place holder for any testing you want to do with the voxl-esc tools. #when done, restore original libpx4.so cd /usr/lib/rfsa/adsp rm libpx4.so cp libpx4.so.bak libpx4.so systemctl enable voxl-px4 reboot This part restores the PX4 functionality, because in order to use voxl-esc tools on VOXL2, the instructions told you to disable PX4 while using voxl-esc tools. Soon we will not require disabling PX4 to use voxl-esc tools, but currently you have to do it. Please note that we just made some updated to the voxl-esc tools and directory structure has slightly changed. Also, you no longer have to download the binary tools package and add it to the voxl-esc/tools directory. Please see an example params file here : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/dev/voxl-esc-params/old/esc_params_modalai_4_in_1_revb.xml

@tom It's probably normal afterall since the voxl-vision-hub service's config file contains a parameter "reset PX4 on error". I set it to "false" and now this behaviour disappeared.

Hey, just to give a little update here: I found out how to set the "force mavlink mode" variable in the voxl-vision-hub.conf which was forcing the parameter back in PX4, and simultaneously set it to "Normal" in PX4. So far I don't see any downsides from using MAV_1_MODE=0 (normal). I'm only making use of voxl-mavlink-server and voxl-vision-hub for the time being, basically to use VOXL's connectivity to send MAV commands to the PX4. Do you think using "normal" will have any downsides? The inconsistency between your documentation and the .conf and PX4 firmware files still exists though, so I'd really like to get some more insight on this. Thanks and a great weekend to everyone.

Update: looks as if my level shifter was a little low on the 3.3v side replaced and I’m talking to the FC now.

@afdrus instead of rebooting, you can restart the server with: systemctl restart voxl-camera-server