In order to access the webserver for the radio you intend to install onboard the voxl2 you should first access the webserver when it's installed on the host pc carrier board and change the firewall settings to enable remote access. The ip address that's set as the static ip in LAN settings is the actual radio ip address. You enter that address in your browser to access the webserver, not the ip address you assigned when running voxl-configure-modem.

I recommend creating a free account on the microhard support website and downloading the product manual here:

https://support.microhardcorp.com/portal/en/kb/articles/pmddl2450-pmddl2350-pmddl2550-user-manual

It's got a pretty good walkthrough on setting up a master/slave radio configuration right up front.

Here's a pic of the general firewall settings as I have them configured. When I first tried to set up the radios I did so on the host pc carrier but when I deployed them to the voxl2 I couldn't access the webserver either. I realized the remote access is disabled by default, you have to check that middle box.

Hope this helps.file:///home/joe/Pictures/Screenshot%20from%202023-07-31%2009-37-33.png

Found the source of the build issues. This line in voxl-mpa-to-ros2

python3 -m pip install colcon-common-extensions lark

is installing an incompatible version of empy. See here:

https://github.com/colcon/colcon-core/issues/602

Another issue with a default sentinel/voxl2 set-up when installing ros2 I've found - need to add a sim link for libtinyxml2. I got this build error

make[2]: *** No rule to make target '/usr/lib/aarch64-linux-gnu/libtinyxml2.so', needed by 'libpx4_msgs__rosidl_typesupport_fastrtps_cpp.so'.  Stop

which I resolved via

ln -s /usr/lib/aarch64-linux-gnu/libtinyxml2.so.6 /usr/lib/aarch64-linux-gnu/libtinyxml2.so

I don't know if these issues are specific to the sentinel platform or not. I added the empy version fix to a fork of voxl-mpa-to-ros2 and will push a merge request. I'm guessing there should be a similar fix within a voxl-ros2-foxy install script or else there'll be build issues whenever trying to build a ros package onboard a vehicle that compiles ros messages (empy version issue was what was preventing me from building px4_msgs package onboard)

Is there a way to expose real-time signal strength data from the microhard radios? Either to use in post for data analysis or for use in real-time as an input for some algorithm

@Eric-Katzfey Awesome, thanks for the feedback!

Will these instructions work for a sentinel dev drone?

https://docs.modalai.com/voxl2-PX4-hitl/

Is the J18 port exposed? Specifically for sentinels with the mircohard carrier board add on

Also, does modalai sell the FTDI cable I would need to run HITL?

Thanks

I'm finding it impossible to run ros2 nodes on multiple vehicles networked together without using the fastdds discovery server to limit traffic to unicast and cut down discovery traffic. Using the default ros2 / fast dds set-up floods the network with traffic once add a third vehicle to the network. Only problem with the discovery server is it isolates the vehicle nodes from the px4 topics exposed by the microdds agent, which I need to publish to.

Is there a way to bridge the microdds agent and nodes that are connected to a dds discovery server? The command line options for running the agent seem pretty limited (can specify discover port but not address) and it's not clear to me how the default agent discovery even works (unicast/multicast/both) and whether or not it's configurable

Has anyone encountered latency issues / stalls in data streams when running ROS2 nodes on multiple vehicles? I'm running ros nodes to publish mocap data as odometry data to sentinel vehicles and am seeing significant performance degradation whenever I have more than 2 vehicles running (see here for more details https://forum.modalai.com/topic/4018/issues-with-multiple-vehicles-on-microhard-network)

I'm reading through the dds documentation to figure out how to tune it to reduce network traffic. Using a discovery server seems like a good option but then it cuts off communication with the microdds-agent and I'm not sure how to get around that. I'm modifying a dds xml profile to try to reduce rtps traffic, but I'm still having issues.

If anyone else has encountered similar issues I'd appreciate any recommendations, thanks!

I have multiple Sentinels (SDK 1.3.5) with Mircohard pmddl2450 radios and wifi dongles that I'm attempting to perform indoor flight testing with. I'm using ROS2 nodes to stream mocap data and joystick commands to vehicles nodes via the microhard network. I've had the network set up as point to multipoint with the groundstation radio in master mode and I've had the network set up as a mesh.

With both set-ups everything performs well for up to two vehicles, but as soon as I add a third vehicle performs starts to degrade significantly and is unusable with a fourth vehicle. Mocap data being streamed to the vehicles at 120 Hz is being received between 15-60 Hz by the vehicles with significant stalls (1-2s) throughout operation. The total amount of data being transmitted to the vehicles is about 2Mbps for mocap data alone (500 kbps per vehicle). The px4 data being streamed over the network to the gcs for qgc is only about 25 kbps. I moved that over to wifi to try to clear up some bandwidth but that didn't help.

I've read that this can be a common issue with default settings for the DDS implementation for ros2 so I've been tuning the dds configs to no avail. I decided to write a simple test program sending the same amount of data to the vehicles over the microhard network via zeromq TCP sockets and I'm still seeing significantly degraded performance (latency > 30ms and intermittent stalls) for more than two vehicles.

Should I expect this network topology to work (single ground station radio connected to 4+ vehicle radios) ? The pmddl2450 is marketed as supporting 25 Mbps and I'm not coming close to that. I'm not sure how to continue troubleshooting this so any help/advice is appreciated

I just realized you could also probably resolve this issue by leaving the gcs ip addresses blank in the config file for voxl-mavlink-server. That would force QGC to make a server side connection because there wouldn't be any heartbeats on the local port (I think QGC link manager checks local udp port first, hence the auto connection issue).

@Eric-Katzfey I'm just trying to connect to and monitor multiple vehicles, yes QGC supports that

I tested a modified voxl-mavlink-server with the configurable gcs udp port and assigned separate ports for each vehicle and it resolved the issue.

I don't think it's a qgc issue unless their link manager is designed to differentiate multiple vehicles publishing to the same udp port on the ground station. I can raise the issue on their forum as well though

I'm assuming 14560 - 14580 is a safe range, but is there any way to verify there are no conflicts short of going through every voxl service to check which publish/receive over udp?

Is there any benefit to making the udp port the mavlink server uses to communicate with QGC/the groundstation configurable? Like by loading in a value from the config file else defaulting to 14550

Besides the udp ports used for the mavlink streams to/from px4 and voxl-mavlink-server (14556-14559) are there any other ports used by voxl services? I was probably going to just use 14560 - 14570 unless they're reserved for something else

Reason:

I'm trying to get a multi-vehicle (sentinels w/ latest sdk and microhard network) set up working and I'm noticing weird behavior when I try to connect to multiple vehicles in QGC. They (the vehicles) all have distinct mavlink sys ids and static ips on the same subnet but I noticed they're all using the same udp port to connect to the groundstation (hard coded in voxl-mavlink-server to 14550). I set up separate comm links in QGC for each vehicle with server address = <voxl-microhard-ip>:14550.

When I start up qgc with 4 vehicles running and I try to connect to one of the vehicles it randomly connects to two additional vehicles. Then when I try to connect the remaining vehicle it switches the first vehicles that connect to a "secondary comm link" and the connection profile name gets mapped to the wrong vehicles. When I restart QGC after that it connects to all vehicles at once regardless of which connection profile I connect to and the comm link profile names don't get shown next to the vehicle.

I'm assuming this is happening because they're all sending messages to the same udp port on the gcs pc. Doesn't seem like a big deal at the moment but I feel like it could lead to unexpected behavior if I try to interact with any of the vehicles through QGC. I'm not sure how QGC establishes the connection if it's actually binding a socket to the server address or just broadcasting locally on the designated port

This is the same build error I ran into (see here https://forum.modalai.com/topic/3908/voxl-px4-and-voxl-mpa-to-ros2-message-compatibility-and-build-issues)

It turned out to be a issue with the version of empy installed when running install_build_dependencies (specifically in python3 -m pip install colcon-common-extensions lark)

I resolved it by downgrading empy after running the install build dependencies script in the docker container

python3 -m pip uninstall -y empy
python3 -m pip install empy==3.3.4