ModalAI Forum

@austin-c , The GPS driver is built for SLPI as well as APPS PROC, so you could connect it to a apps-proc UART and start the driver on the apps proc side of PX4. This was done on RB5 : https://docs.modalai.com/Qualcomm-Flight-RB5-linux-user-guide/ https://docs.modalai.com/voxl2-linux-user-guide/ Regarding magnetometer, just like with the GPS driver, you should be able to enable the mag driver to build for apps proc. Since the apps proc i2c uses standard posix interface, it should just work. However, i don't think we have ever tried it. Alex

@restore There are a few examples of code that listens for Mavlink messages in our SDK. For example, in voxl-mpa-tools, take a look at the source code for voxl-inspect-mavlink.c. https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/tools/voxl-inspect-mavlink.c?ref_type=heads Probably would be a good idea to run voxl-inspect-mavlink on the mavlink_onboard and mavlink_to_gcs pipes to see which one has the desired Mavlink message in it. Then create your own application that listens for the Mavlink message on that pipe.

We are having the same issue on our C28 config.

@Moderator Thanks for the clarification on the ~50 ms glass-to-glass number. Trying to get a better understanding the performance envelope: 1. Does the 50 ms include RF transport over Doodle, decode, and HDMI output latency, or is that measured only within the VOXL + VRX software stack? 2. Was this measured in point-to-point mode or mesh routing mode? 3. Can you expand on bitrate, resolution, and encoder settings were used (GOP structure, B-frames disabled, UDP vs RTSP)? 4. Is MAVLink or other traffic running on the same link during that measurement? 5. Do you have a latency breakdown per stage (encode / RF / decode / display)? Appreciate any information you can provide. I just want to make sure I can test and validate this effectively.

@magnetocircuit Yes, this is supported. In the config file for px4 /etc/modalai/voxl-px4.conf set ESC=VOXL2_IO_PWM_ESC.

@Aaron-Porter Hello there, voxl-evaluate-vins is currently not used by the Autonomy team @ ModalAI, we opted for our new benchmark solution, a bit more consistent in terms of statistical rigor and better integration with voxl-portal. Still, when replaying logs for VINS, it is imperative that one replays them using the ION pipes, as our VINS solution is optimized for cl_mem ptrs. Note that when replaying ION pipes, it is recommend to stop camera-server before replaying -- as clean killing ION pipes via the voxl-replay args is currently being optimized. This should resolve the common segfaults experienced during the replay/benchmark operation itself. https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-benchmark-vio Finally, I would recommend updating your VINS to the latest available tag on Gitlab

@sja123 No, unfortunately, we do not currently support boot from SD card.

Hey @yunwool Just to be clear, consider only your first drone, if you run export ROS_DOMAIN_ID=1, then run ros2 topic list, you aren't seeing any topics right? After you set the ROS_DOMAIN_ID of a drone to 1, to get the PX4 topics to show up, on QGC > Analyze Tools > MAVLink Console, run the following commands: param set XRCE_DDS_DOM_ID 1 param save Then power cycle the drone, give it like 15s after boot up, then the topics should come up directly when running ros2 topic list on that drone.

Update: I bought an Alfa Networks AWUS036ACS and it worked out of the box with the M0151 board

@JoonaR Hi Joona, the DP should work to drive an HDMI projector with the appropriate adapter. This adapter has been tested to work: https://www.amazon.com/Cable-Matters-48Gbps-Adapter-Supporting/dp/B08MSWMXT4?th=1

@qubotics-admin Hi, we sell all of those components for companies to integrate into their products. The Flir Hadron adapter (MDK-M0202-1-00) can be requested by reaching out to sales at https://modalai.com/contact The rest of the components should be available to purchase at modalai.com

I did some additional testing and was able to narrow things down a bit. After reconfiguring the WiFi as a SoftAP using voxl-wifi and then rebooting the VOXL, the network now shows up consistently again. So the broadcast issue seems to be resolved for the moment. However, the core problem remains: I still can’t actually connect to the AP — the connection attempt starts, prompts for the password, and then fails just like before. If anyone has ideas on what else I could check or has seen similar behavior with this setup, I’d really appreciate the help.

Hey @svempati I trained a model in the docker command as provided by you. I am able to run an inference on potholes following exactly the steps provided by @Zachary-Lowell-0 earlier. Could I ask you what your voxl-tflite-version is? And if you havent yet, could you try to run this version: http://voxl-packages.modalai.com/dists/qrb5165/sdk-1.6/binary-arm64/voxl-tflite-server_0.5.1_arm64.deb Make sure to change the .tflite model and labels as shown in the loom video after the install, then run voxl-configure-tflite Thanks

@Alex-Kushleyev Can you please look into this or tag someone who can help me solving this type of networking related issue?

@Seungjae-Baek , the resolution of the camera should depend on the use case. However, it is also important to keep in mind what exactly you are doing with the images coming from the hires cameras. For example, if you set the resolution to 4K and you try to view those uncompressed images using voxl-portal, this process will be very taxing on the CPU for the following reason: when you view uncompressed images in voxl-portal, these images are encoded with a software JPG encoder and then sent from voxl2 to your browser. This process is very cpu-heavy. On the contrary, if you use h264 / h265 stream, it should be perfectly fine to encode 4K30 video to disk or even stream, since H264 / H265 encoding is done by a hardware encoder. voxl-portal, actually does support showing h264 (but not h265) 30FPS streams, so that would be a lot more efficient for the CPU, since there would be no jpg encoding. Otherwise, if you are using raw frames (not _encoded) in voxl-portal , please keep in mind that you will always have a lot of cpu overhead. voxl-portal is designed for debugging / development purposes, so it's not necessarily the most efficient solution for video streaming. For real video streaming use cases, you would use h264 or h265 encoding and save to disk on voxl2 + stream the encoded video for remote viewing. You could encode the same camera source with two different resolutions / codecs / bitrates. If you need help setting up a specific use case, please provide some details and I can help you further. Alex

Actually, I see from the log that your FPV camera is IMX214 (please confirm). So then my next questions are: which Voxl2 SDK are you using? does the crash happen if you only view the Hadron EO stream (this is OV64B camera) can you please check the cpu temps when you view many cameras (using voxl-inspect-cpu) The dmesg error suggests some sort of low level error during MIPI transmission, but it could be tied to the SoC overheating. When voxl-portal is used to view images (especially in multi-view), the images on VOXL2 are converted from YUV to Jpeg using a software Jpeg encoder (which is very taxing on the cpu for large images). This can cause the cpu to overheat and start throttling operating frequencies to reduce the temperature). We are aware of this issue and it is on the list to fix the multi view to be more efficient and not overheat the CPU. Alex

@alan123 Hi, sorry for the late reply. Unfortunatly, we have not finished it yet. We're switching from ntrip to ros2

@N-Chen I tried the webUI and the command line and as near as I can tell the webUI uses lsusb (or something along those lines) to detect the presence of the board. The install.sh uses adb or fastboot to detect the board and will sit waiting until the board is detected or CTL C is sent. My guess is the usb controller interface is alive and reporting but everything beyond it is dead.