@Chad-Sweet Also, PLEASE stop telling people to download the roskinetic-xenial docker image that you host. There is nothing modalAI-specific about your docker image, and forcing people to use xenial means forcing them to use Python 3.5 or lower. Furthermore, rosnoetic is far superior than roskinetic when it comes to ROSv1. There are important features added and bugs fixed in rosnoetic.

On our modalAI drones, we simply do a docker pull of a rosnoetic image (that runs on Ubuntu focal):

docker pull ros:noetic-robot

You can find out more information about pulling a ROS docker image this way at the ROS docker tutorial here:

http://wiki.ros.org/docker/Tutorials/Docker

Then just run that docker image (using the docker run -it ... described at the link above) and start installing other packages you need. For example, we use apt-get to download important ROS packages we need, like mavros, mavros_msgs, etc. and geographic information required. You can follow the nice ROS with MAVROS installation guide (in the "Binary Installation (Debian/Ubuntu)" section):

https://docs.px4.io/main/en/ros/mavros_installation.html

Of course, you will have to create a MAVROS launcher file within the "launch" folder of a ROS package that is customized to the voxl-mavlink-server/voxl-vision-px4. Here is an example with the correct UDP port:

<launch>
        <!-- vim: set ft=xml noet : -->
        <!-- example launch script for PX4 based FCU's -->

        <!-- <arg name="fcu_url" default="/dev/ttyACM0:57600" /> -->
        <arg name="fcu_url" default="udp://127.0.0.1:14551@:14551" />
        <arg name="gcs_url" default="" />
        <!-- <arg name="tgt_system" default="1" /> -->
        <arg name="tgt_system" default="$(env PX4_SYS_ID)" />
        <arg name="tgt_component" default="1" />
        <arg name="log_output" default="screen" />
        <arg name="fcu_protocol" default="v2.0" />
        <arg name="respawn_mavros" default="true" />
        <!-- <arg name="ns" default="drone_n" /> -->
        <arg name="ns" default="drone$(env PX4_SYS_ID)" />

        <include ns="$(arg ns)" file="$(find mavros)/launch/node.launch">
                <arg name="pluginlists_yaml" value="$(find mavros)/launch/px4_pluginlists.yaml" />
                <arg name="config_yaml" value="$(find mavros)/launch/px4_config.yaml" />
                <arg name="fcu_url" value="$(arg fcu_url)" />
                <arg name="gcs_url" value="$(arg gcs_url)" />
                <arg name="tgt_system" value="$(arg tgt_system)" />
                <arg name="tgt_component" value="$(arg tgt_component)" />
                <arg name="log_output" value="$(arg log_output)" />
                <arg name="fcu_protocol" value="$(arg fcu_protocol)" />
                <arg name="respawn_mavros" default="$(arg respawn_mavros)" />
        </include>
</launch>

Finally, you can also install python packages you might need, including pip3 itself (use apt-get to install pip and then use pip to install other packages). Once you're done, installing, you just need to commit before exiting your shell. So, in another terminal issue:

docker ps

to find the container ID (or at least the first few characters of it) for the currently running rosnoetic container. Then issue:

docker commit CONTAINER_ID DESIRED_IMAGE_NAME:DESIRED_TAG

For example, you might issue:

docker commit 42c731c5 myproject-rosnoetic-focal:v1.0

You can then exit your docker image. You can then remove the original ros-noetic image from your local library (if you wish). You can export your new docker image with:

docker save myproject-rosnoetic-focal:v1.0 | gzip > myproject-rosnoetic-focal-v1.0.tar.gz

Then transfer that resulting tarball (myproject-rosnoetic-focal-v1.0.tar.gz) to your /data partition on the m500 and use

docker load -i myproject-rosnoetic-focal-v1.0.tar.gz

to load the image onto the VOXL. The resulting image will work just as well as the roskinetic image. You can load it on the VOXL with the --net=host and -v outside_folder:inside_folder:rw options (among others) to make sure the docker image has the same network access as the VOXL and allows for a folder (or folders) on the VOXL to be mapped to folders inside the docker image (which makes it easier to develop code for your drone without having to rebuild the docker image each time). I believe that modalAI has documentation on this part.

So, please, use a rosnoetic-focal image from ROS directly. It is crazy to be using a roskinetic image (with xenial!) in 2023 or beyond. Of course, ROSv1 will be deprecated in a couple of years anyway (if that's not pushed). Sadly, if you want a ROSv2 image, you will have to implement a ROS bridge between your docker image and the VOXL until the VOXL gets updated to ROSv2, but rosnoetic is very capable (and much better than roskinetic, especially given that you run rosnoetic on focal (not xenial)).

@atilla-bleda At least for VOXL Flight drones (I haven't used VOXL2), the voxl-mpa-to-ros bridge is based on ROS indigo, which means that you're going to have to implement a ROS bridge to go from your ROS2 to their ROS1 if you want to use mpatoros. That said, if you are accessing the MPA named pipes directly (or if you want to update their voxl-mpa-to-ros, which they've provided source code to), you won't need the ROS bridge and can use ROS2 directly.

You can run MAVROS within ROS2 (it communicates over UDP to Mavlink). So really you just need a replacement for mpatoros or design your system to not depend on any of the MPA stuff.

To run ROS2 on the drones themselves, you'll have to do a docker pull ros and setup a docker image that includes ROS2. Then either use a combination of network traffic (MAVROS via UDP) and the -v flag in docker (to import the MPA pipes) to try to get around using any ROS1 infrastructure provided by modalAI. In the worst case scenario, you may have to update the voxl-mpa-to-ros bridge.

We don't use ROS2 because it's still buggy, but we did throw away the roskinetic image that ModalAI suggests using and rolled our own rosnoetic docker image, and life is much sweeter.

If you have not ordered an m500 Drone from ModalAI recently, here is what the most recent drone looks like. Note that it is completely different from the picture on the ModalAI web page.

Essentially, ModalAI has replaced a number of older parts on the M500 drone with new 3D-printed parts. They used to use rubber isolation mounts that helped to damp IMU vibrations due to the motors, but now they use a 3D-printed solid mount that is extremely delicate at the screw hole, as you can see here where the screw hole is broken (be very careful not to over-torque your screws!):

They also have 3D-printed a mount on the bottom of the S500 frame that allows them to put the new landing gear (which used to be mounted underneath each motor). I think that ModalAI was looking for landing gear that would not get in the way of the tracking camera (in both revisions -- with the gear attached to the bottom of the motors as well as here attached to the 3D-printed mounts on the hub of the S500 frame). The problem is that the plastic gear that attaches to the 3D-printed frame is extremely fragile. On our first test flight, it cracked in half on landing:

Even when the drone lands fine, these little legs do not provide much stability to keep the drone upright. The previous iteration, although non-conventional for a drone, was much better.

We've started using more conventional S500 legs on the bottom of our m500 drones (which mount to the bottom of the drone, lifting the drone off the ground by several inches). The downside of these more conventional legs is that you can see the "toes" of them in the tracking camera, which may trick your object detection into thinking there are persistent objects in view. This is not ideal, but it is much more stable than the other options (and provides more places to handle the drone when carrying it).

I believe that ModalAI has provided CAD part files for the VOXL Flight mounts somewhere, which will allow you to replace these mounts when they inevitably break. Has anyone else come up with another option to replace these fragile 3D-printed VOXL Flight mounts? Simply being able to order the old mounts (which were rubber standoffs plus a little extra PCB) would be fine, but I'm sure someone could probably design a better 3D-printed option or even come up with a combination of elements from a local hardware store that would do a better job.

@Anubhav and @DarkKnightCH: Was there any movement on this?

We have 7 drones with FCv2 (all of our other m500 drones have different FC's) that were also sent to us with the wrong radios. We were able to reconfigure the PX4 for the desired radios (and confirm RC connection to QGC), but running voxl-mavlink-server manually shows a UART error on the console. We are RMA'ing the 7 units with the bad mavlink back to ModalAI for a fix, but it would be great to save the shipping if a fix was found here.

@Chad-Sweet Also, PLEASE stop telling people to download the roskinetic-xenial docker image that you host. There is nothing modalAI-specific about your docker image, and forcing people to use xenial means forcing them to use Python 3.5 or lower. Furthermore, rosnoetic is far superior than roskinetic when it comes to ROSv1. There are important features added and bugs fixed in rosnoetic.

On our modalAI drones, we simply do a docker pull of a rosnoetic image (that runs on Ubuntu focal):

docker pull ros:noetic-robot

You can find out more information about pulling a ROS docker image this way at the ROS docker tutorial here:

http://wiki.ros.org/docker/Tutorials/Docker

Then just run that docker image (using the docker run -it ... described at the link above) and start installing other packages you need. For example, we use apt-get to download important ROS packages we need, like mavros, mavros_msgs, etc. and geographic information required. You can follow the nice ROS with MAVROS installation guide (in the "Binary Installation (Debian/Ubuntu)" section):

https://docs.px4.io/main/en/ros/mavros_installation.html

Of course, you will have to create a MAVROS launcher file within the "launch" folder of a ROS package that is customized to the voxl-mavlink-server/voxl-vision-px4. Here is an example with the correct UDP port:

<launch>
        <!-- vim: set ft=xml noet : -->
        <!-- example launch script for PX4 based FCU's -->

        <!-- <arg name="fcu_url" default="/dev/ttyACM0:57600" /> -->
        <arg name="fcu_url" default="udp://127.0.0.1:14551@:14551" />
        <arg name="gcs_url" default="" />
        <!-- <arg name="tgt_system" default="1" /> -->
        <arg name="tgt_system" default="$(env PX4_SYS_ID)" />
        <arg name="tgt_component" default="1" />
        <arg name="log_output" default="screen" />
        <arg name="fcu_protocol" default="v2.0" />
        <arg name="respawn_mavros" default="true" />
        <!-- <arg name="ns" default="drone_n" /> -->
        <arg name="ns" default="drone$(env PX4_SYS_ID)" />

        <include ns="$(arg ns)" file="$(find mavros)/launch/node.launch">
                <arg name="pluginlists_yaml" value="$(find mavros)/launch/px4_pluginlists.yaml" />
                <arg name="config_yaml" value="$(find mavros)/launch/px4_config.yaml" />
                <arg name="fcu_url" value="$(arg fcu_url)" />
                <arg name="gcs_url" value="$(arg gcs_url)" />
                <arg name="tgt_system" value="$(arg tgt_system)" />
                <arg name="tgt_component" value="$(arg tgt_component)" />
                <arg name="log_output" value="$(arg log_output)" />
                <arg name="fcu_protocol" value="$(arg fcu_protocol)" />
                <arg name="respawn_mavros" default="$(arg respawn_mavros)" />
        </include>
</launch>

Finally, you can also install python packages you might need, including pip3 itself (use apt-get to install pip and then use pip to install other packages). Once you're done, installing, you just need to commit before exiting your shell. So, in another terminal issue:

docker ps

to find the container ID (or at least the first few characters of it) for the currently running rosnoetic container. Then issue:

docker commit CONTAINER_ID DESIRED_IMAGE_NAME:DESIRED_TAG

For example, you might issue:

docker commit 42c731c5 myproject-rosnoetic-focal:v1.0

You can then exit your docker image. You can then remove the original ros-noetic image from your local library (if you wish). You can export your new docker image with:

docker save myproject-rosnoetic-focal:v1.0 | gzip > myproject-rosnoetic-focal-v1.0.tar.gz

Then transfer that resulting tarball (myproject-rosnoetic-focal-v1.0.tar.gz) to your /data partition on the m500 and use

docker load -i myproject-rosnoetic-focal-v1.0.tar.gz

to load the image onto the VOXL. The resulting image will work just as well as the roskinetic image. You can load it on the VOXL with the --net=host and -v outside_folder:inside_folder:rw options (among others) to make sure the docker image has the same network access as the VOXL and allows for a folder (or folders) on the VOXL to be mapped to folders inside the docker image (which makes it easier to develop code for your drone without having to rebuild the docker image each time). I believe that modalAI has documentation on this part.

So, please, use a rosnoetic-focal image from ROS directly. It is crazy to be using a roskinetic image (with xenial!) in 2023 or beyond. Of course, ROSv1 will be deprecated in a couple of years anyway (if that's not pushed). Sadly, if you want a ROSv2 image, you will have to implement a ROS bridge between your docker image and the VOXL until the VOXL gets updated to ROSv2, but rosnoetic is very capable (and much better than roskinetic, especially given that you run rosnoetic on focal (not xenial)).

@aashry This looks very helpful! A team member responsible for tuning object detection spent hours trying to abide by the ModalAI comment in their scripts to use TFLite version 2.2.3 or OLDER. The comment that modalAI provides in that script (but not in any documentation) seems so strict. Just getting that version of TFLite installed somewhere was a headache, and then the model he exported with it didn't work.

What worked for him was to use the export script provided by YOLOv5, as you say. That exported model just worked fine for him, and it was very straightforward. It would be nice if modalAI would update their scripts to not make people jump through TFLite 2.2.3 (or earlier) hoops when in the end they'll probably have more success using the native export scripts from YOLO.

@mkwan FYI, when we were switching from Spektrum to Graupner, we discovered this setting in the PX4 (accessible via QGC):

RC_INPUT_PROTO

To go from Spektrum to Graupner HoTT, we had to set that to "SBUS". There is a Spektrum-specific setting.

Once we made that change, then QGC started acknowledging that we had a radio connected.

That said, all of our FCv2 boards (which were the ones mistakenly sent with Spektrum although we ordered Graupner) had some problem in the UART connection between the PX4 and the VOXL, and so voxl-mavlink-server reported that there was no UART connection. We are about to RMA the VOXL Flight's to modalAI for them to investigate this UART problem. However, assuming that your PX4-to-VOXL connection is good, I think that the RC_INPUT_PROTO setting above should fix the problem you're having getting the Spektrum radios connected to QGC.

@Moderator We did more troubleshooting this evening and found that if we manually run voxl-mavlink-server on the FCv2 drones, it tells us that it is unable to make a UART connection with the PX4.

Because we did not have much else we could try, we went into /etc/modalai/voxl-mavlink-server.conf and adjusted the UART bus from its default value (5, if I recall correctly) to different values from 1 through 8 (and also 12, randomly). None of these resolved the issue, although we received a different error message for 12, and we bricked our voxl when we set it to 8 (but we were able to flash again using fastboot after we unplugged the FCv2 connections).

So there seems to be some UART problem between the FCv2 and the VOXL on the seven (I miscounted) drones that were sent to us with FCv2 and Spektrum radios. We were able to convert them to Graupner radios (after finding a SBUS setting in the PX4), but the UART between the FCv2 and the VOXL seems to have always been faulty.

All of our FCv1 drones seem to be working fine. We just received 14 more drones today, and these all seem to have an integrated VOXL Flight that does not have a separate FC. These all seem to work. That said, all of the PX4 settings are different across these (and it seems like there may be as many as 3 different PX4 versions across the 14 drones that we received today, despite them all coming in the same batch).

It seems to us like there may be something fundamentally broken in the FCv2. If this is the case, anyone who is stuck with an FCv2 should be given an option to have it replaced with a working FCv1. Either that or please kindly tell us how to get the UART back up and running between the FCv2 and the VOXL Flight.

@Moderator Please see the thread above for history. When this thread was started, the 4 units that were mistakenly shipped with Spektrum modems were unable to be connected to the RC after switching to Graupner. We discovered that there was a setting (undocumented on ModalAI's site) in QGC that would allow us to switch to SBUS on the PX4, and that restored connectivity to the Graupner. Prior to that, we had connectivity with the Spektrum RC, but we had not tested out mavlink. We initially assumed that all of the problems we were having were related to the inability to switch to Graupner, and that's how the thread started this way.

But then during this thread, we discovered the QGC setting that allowed us to get the Graupner RC connected to the PX4. It was only after then that we discovered there were problems connecting the PX4 to the voxl (even after flashing and reflashing the voxl).

We only have this problem on the 4 units that were shipped to us with Spektrum radios (that were supposed to be Graupners). So, while we agree that it seems strange that this would be a radio issue, we know that there are radio-specific QGC settings (that we discovered in the thread even though they are not documented on ModalAI's Graupner documentation pages), and so we thought that the Spektrum configuration might vary from Graupner in some way that would explain the lack of mavlink.

@Moderator Please see the thread above. There are SEVERAL pictures of our FCv2 wiring. This has been covered in this thread already.

The wiring seems to work (and we've tried alternative configurations that seem to work). The radio powers up and can pair with our RC (green light). Moreover, after we changed the PX4 setting to use SBUS, QGC confirms that commands from the RC are received at the radio. The problem is that the PX4 is not communicating with the voxl (and mavlink is unable to communicate with the px4). We have re-flashed the voxl multiple times.

This is the same problem on all of the drones we received from you that had an FCv2 with a Spektrum radio (even though we ordered Graupner -- you then sent us more Graupner radios to replace the Spektrum, but we gave up on these drones in order to make progress with our other drones when the Graupner wouldn't connect). All of our previous Graupner drones had FCv1 and worked fine.

We just ordered $20k more drones from you that are delivered today to our central receiving (waiting to receive them internally). They are supposed to have Graupner radios and we assume will be FCv2. We are eager to see if they work out of the box.

Just pinging about this post. I also wanted to make a correction -- the four drones we have that modalAI sent us with the Spektrum has Flight Core v2 (not FCv1, as I typed originally). Everything else applies though -- the documentation for the m500 everywhere uses FCv1, and so the pinouts don't match. Any m500 we have with FCv2 has non-functioning MAVLINK. We managed to get the Graupners connected, but we cannot get MAVLINK up and running even after updating MAV_0, MAV_1, and MAV_2 settings in QGC. So, we hope we're just missing some setting. These FCv2 drones don't work with either radio. As far as we know, MAVLINK has never worked on them.

Again, we have re-flashed the VOXL on these drones several times (as many as 3 per drone) with no help. We have no trouble connecting to the VOXL via adb or WiFi. The problem is between the VOXL and the PX4. It is the exact same problem on all 4 drones, which suggests that it is something with the Flight Core v2's (or their connection to the VOXL) that were sent to us.

Again, it would be great if you could let us know what the Flight Core v2 settings are supposed to be for both the Graupner and the Spektrum radios and whether there is anything we can check regarding the physical connection between the Flight Core v2 and the VOXL. For our archives, it would also be nice to have these for the FCv1, but the priority is the FCv2.