@Zachary-Lowell-0 Additionally, when I push the left stick on the controller up or down, it stays in that position after I release it, instead of returning to the center. Is this by design? It behaves differently from the right stick, which returns to the center automatically.

@Sarah-McMahon said in Unable to Generate the Mavsdk Docker on a M500: @Zachary-Lowell-0 I encountered an issue with the threading during the download process, which caused it to take about 9 hours. The main problem arose when running deploy-to-voxl.sh—the drone ran out of storage after pushing the tar file, preventing the image from being loaded into Docker. While attempting to free up space, I mistakenly ran the wrong opkg command and deleted all opkg packages, making it impossible to SSH or ADB into the drone. Do you have any suggestions for a potential fix? I noticed the USB Expander and Debug Add-On Board might be helpful, but I couldn't find it available for purchase on the website. Reply Hi Sarah - I am unsure if I am following - the docker tarball is only a few gig's so I am unsure how you ran out of space. For now I would just reflash your voxl from the downloads page here https://developer.modalai.com/categories (download the most recent voxl1 sdk unzip it and run the install script from the parent computer) - this will reinstall the entire sys image and newest SDK onto the voxl and allow you to adb shell and ssh in again. From there you will need to configure the SKU and mpa and then you can try the docker installation again from the parent computer. Can you let me know how big your image is for the mavsdk docker tarball? And if you run df -h on your voxl can you paste the output I want to see where all your disk space is being utilized. Zach

@Moderator I am aware. I've been using this drone for research purposes and I always make sure to follow safety guidelines. Thanks, I'll follow these instructions.

@Alex-Kushleyev I never uploaded any parameters, just used both escs out of the box. maybe that caused the issue?

Hi @Jeremy-Frederick Can you please provide some pictures? It almost sounds as if you have a faulty RJ45 jack, but these are tested in factory before shipping. If you can get some close ups of the non-working RJ45 and the LAN7500 chip, that may help. And, can you clarify that you have Qty-2 M0062's and one works, yet one doesn't? Did the faulty one ever work for you? Was the faulty one in any type of handling mishap (like an accidental drop/fall)? The RJ45 has integrated magnetics to save space (which is why it is so tall), but that makes them more vulnerable to shock failure than typical RJ45's. One thing I do know that may also occur is the jack can be installed slightly tilted, making it hard to seat the RJ45 cable in firmly. There is an odd feature on the connector that sometimes allows it to seat at an off-angle, slightly pointing down making the cable slightly interfere with the PCB (but still ok to insert, since as I mentioned, we tested at the factory). Also, the metal along the sides of the RJ5 may also be stiff, preventing a smooth insertion, so sometimes just inserting the RJ45 cable a few times making sure you get that nice tactile "click" may be what is needed to ensure the contacts are engaged and kinda "breaking in" the stiff connector.

@wetherbeej , VOXL2 does not have ability to un-invert the SBUS signal, so you cannot plug in a standard SBUS receiver directly into VOXL2. However, we offer VOXL2_IO board, which supports standard SBUS input and will send the SBUS data to PX4 using standard UART. https://docs.modalai.com/voxl2-io-user-guide/ If you don't want to add another board and if you find a receiver that is capable of outputting "inverted SBUS", which is actually using standard UART levels, you may be able to use the PX4 standard sbus driver. However the PX4 sbus driver is not currently built for VOXL2 because it is requires some support of UART port, which VOXL2 does not support (specifically inverted signal level and maybe some other options). Long story short, if you want a solution that will just work, it is better to use our VOXL2 IO board, but if you absolutely do not want to add another board to the drone, then you will need a rx with inverted SBUS + modify PX4 sbus rc driver to work on VOXL2. Alex

@jonathankampia Yes, it would require modifying the "tones" in whichever esc param file you're using. For example for starling 2 it is defined here: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-params/D0014_starling_1504_3000kv_ms_props/D0014_starling_1504_3000kv_ms_props.xml?ref_type=heads#L90

Please verify the PC data in rviz2. What you see in rviz2 should look exactly alike to what is shown in voxal portal for tof_pc. Note that the point step size is 12. See this guide for more info on pointcloud data message data Point cloud data will look very different from image data, since the data field is constructed very different from BGR image formats. I have replicated these results in a starling2 as well, with voxl-mpa-to-ros2 dev branch:[image: 1727726700892-rospc_.png] Note that you may need to spin up a static transform to see the pointcloud data in ROS: ros2 run tf2_ros static_transform_publisher 0 0 0 0 0 0 map world

Hi @wouter the reason this is happening is recently docker depricated their api v1 version and are only using v2 api calls now. Meaning the original voxl is not able to pull down pre made docker images. The solution around this is to build the docker image on a parent computer, tar it up via docker save, then push that to the voxl and run a docker load -i on the tar file. You can follow similar to what we do in voxl-docker-mavsdk: https://gitlab.com/voxl-public/voxl-docker-images/voxl-docker-mavsdk/-/blob/main/Dockerfile?ref_type=heads

@groupo Yes, we have used px4-listener <topic name> for external monitoring of PX4 topic data in other applications.

Thank you @ben-grocholsky! I should be more clear, when I ran px4-listener sensor_gps I received something along the lines of "GPS never published". I just went to go get the verbatim output but everything seems to be working. I do indeed see the uorb now. Puzzling

Hi @Matthew-Wellner Yes, we sell some modem products as "stand-alone" which can be connected to any USB host. We have not offered our popular M0090 5G modem in that mode, but we have offered it for the older Microhard and Sierra 4G modules, but right now we only offer it on Microhard: https://www.modalai.com/collections/modems/products/mdk-m0048-2

@jcai It should then be rtsp://192.168.1.222:9976/live. Ah, but you don't want that live part on the end?

@groupo I responded to your new post.

We removed the RC and are able to fly with a wired gamepad. Could the control loss be due to a voltage drop on the J19 12-PIN JST to the Rx? I will check later today.