@Zachary-Lowell-0 I said yesterday that echoing the /fmu/out topics only worked if voxl-px4 was disabled on startup and run in a terminal with voxl-px4. This no longer appears to be the case, although I don't know what changed from yesterday to cause this. Now ros2 topic echo can print those topics when px4 is launched at startup. However, the topics still don't print the data I would expect if the drone were correctly reading the data I publish to /fmu/in/visual_odometry, unchanged from yesterday.

The qvio server was on. I disabled it, but that didn't fix the issue of the drone not using the data from /fmu/in/vehicle_visual_odometry. I believe that shutting down this server should disable VIO, correct? This is the output after disabling qvio server and having px4 enabled to launch at startup.

Here is the output of /fmu/out/vehicle odometry when I am not publishing to /fmu/in/vehicle_visual_odometry

And here is the output when I am publishing to it using the command topic pub /fmu/in/vehicle_visual_odometry px4_msgs/msg/VehicleOdometry '{timestamp: 1234567890, timestamp_sample: 1, pose_frame: 1, position: [1.23, 4.56, 7.89], q: [0.707, 0.707, 0.0, 0.0], velocity_frame: 1, velocity: [0.5, 1.0, -2.3], angular_velocity: [0.1, 0.2, -0.3], position_variance: [0.01, 0.02, 0.03], orientation_variance: [0.001, 0.002, 0.003], velocity_variance: [0.005, 0.01, 0.02], reset_counter: 0, quality: 1}' which is supposed to provide it with test mocap data.

This is the value of ekf2_ev_ctrl from QGroundControl.

The flight cage I am using has an Optitrack motion capture camera system installed that communicates my Starling 2 drone's position data on the LAN using NatNet protocol. I have a ROS 2 package on my computer that can receive this data. I plan to transmit this data to the drone after it has been converted to the appropriate format. By referencing this guide, I see that mocap data should be published to the vehicle_visual_odometry topic. When PX4 is running on the drone, I can access the ROS 2 topic /fmu/in/vehicle_visual_odometry. However,when I publish test data to this topic it does not have any obvious effect. By using the ros2 topic echo command I can see that the data is indeed getting published. However, echoing the /fmu/out commands return nothing, including the commands that are supposed to return the drone's position.

Publishing to /fmu/in/vehicle_visual_odometry

Listening to /fmu/in/vehicle_visual_odometry while publishing topic

Attempting to listen to /fmu/out topics

When I disable PX4 with systemctl disable voxl-px4 I am able to view the data from these /fmu/out topics. But still, publishing to vehicle_visual_odometry does not change the /fmu/out readings that display vehicle position.

Images of /fmu/out commands when not publishing to /fmu/in/vehicle_visual_odometry

when publishing to /fmu/in/vehicle_visual_odometry

@Eric-Katzfey Issue is mostly resolved. There were two main errors to fix. The first was that the cable that I was using needed to have its RX and TX wires swapped as Vinny pointed out. The second was that Docker Desktop needed to be uninstalled and replaced with only the core Docker CE Engine. After doing this, the HITL seems to be up and running on the alternate Linux computer I tested with. On the original computer, the "Serial port closed error" is no longer present although there does seem to be a graphics issue when attempting to run the Gazebo image with graphics.

Once this is fixed I think it should be all ready to perform simulations.

@Eric-Katzfey I will look into trying this.

Also, ignore my earlier post that said I had fixed things by performing the tutorial steps in a different order. I was mistaken in thinking I had resolved the original issue. The next message explained why I made that mistake.

@Eric-Katzfey I rewired the cable but the issue hasn't changed at all. It's still reporting "Serial port not found!" and the /dev/ttyUSB0 that you mentioned still isn't available from the Gazebo Docker command line.

@Vinny I swapped pins 2&3 so that the former pin 2 is now pin 3 and vice versa. The swap occurred with no damage to the pins as far as I am aware, but the "Serial port closed" issue is still present. This image shows the correct rewiring, right? The RX and TX wires (white and green) are switched and the USB to JST is in J18 on the VOXL 2. The ESC is unplugged from VOXL 2.

@Eric-Katzfey I have figured out why I thought that the drone wasn't giving me a "Serial port closed!" error a couple of days ago but has been doing so yesterday and today. When the gazebo docker container has not been created, the first attempt to create it will result in a "Serial port closed!" error. However, when the container is already running, future attempts to create it will not display the error, they will simply show the following message rather than creating a new container. At first I thought that this message meant that the connection to the drone had successfully avoided the "serial port closed" message.

The bad news is that this means that there may never have been a successful connection between the laptop and drone at all. A hardware misconfiguration can't be ruled out in this case. As I said, I had to remove a connection to the ESC 4 in 1 in order to connect the cable to the JST port on the VOXL2. If the connection's in the right place, it might be a permissions issue like you mentioned, although docker was run as privileged and I'm already in dialout.

I got Docker to avoid the error by doing the steps in the tutorial in a different order with setup on the drone coming first. This must have been why I didn't receive the "serial port closed" error when I first tried to set up the simulation two days ago. However, I don't think the simulation is in shape to run yet, all I've managed is to get back to where I was originally....

@Eric-Katzfey Here are my results with the same commands.

I ran docker in the dialout group but it didn't seem to make a difference. I was already in root.

As you can see, much of the contents of /dev is missing in docker compared to what's available from the linux command line. It's not only ttyUSB0.