Posts made by jmltt

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

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)

Ok so I just pushed version of the px4_msgs package (https://github.com/PX4/px4_msgs/tree/release/1.14) that I had updated with the latest px4-firmware message definitions to one of the vehicles (Sentinel's with latest sdk, voxl-ros2-foxy and voxl-mpa-to-ros2 downloaded via apt repository) and I'm getting a similar error when I try to build it on the voxl2:

voxl2:~/ros2_ws$ colcon build
Starting >>> px4_msgs
--- stderr: px4_msgs                         
CMake Error at /opt/ros/foxy/share/rosidl_adapter/cmake/rosidl_adapt_interfaces.cmake:60 (message):
  execute_process(/usr/bin/python3 -m rosidl_adapter --package-name px4_msgs
  --arguments-file
  /home/root/ros2_ws/build/px4_msgs/rosidl_adapter__arguments__px4_msgs.json
  --output-dir /home/root/ros2_ws/build/px4_msgs/rosidl_adapter/px4_msgs
  --output-file
  /home/root/ros2_ws/build/px4_msgs/rosidl_adapter/px4_msgs.idls) returned
  error code 1:

  AttributeError processing template 'msg.idl.em'

  Traceback (most recent call last):

    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/resource/__init__.py", line 51, in evaluate_template
      em.BUFFERED_OPT: True,

  AttributeError: module 'em' has no attribute 'BUFFERED_OPT'

  

  During handling of the above exception, another exception occurred:

  

  Traceback (most recent call last):

    File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
      "__main__", mod_spec)
    File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
      exec(code, run_globals)
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/__main__.py", line 19, in <module>
      sys.exit(main())
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/main.py", line 55, in main
      pathlib.Path(relative_path), output_dir)
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/__init__.py", line 20, in convert_to_idl
      package_dir, package_name, interface_file, output_dir / 'msg')
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/msg/__init__.py", line 39, in convert_msg_to_idl
      expand_template('msg.idl.em', data, output_file, encoding='iso-8859-1')
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/resource/__init__.py", line 23, in expand_template
      content = evaluate_template(template_name, data)
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/resource/__init__.py", line 69, in evaluate_template
      _interpreter.shutdown()

  AttributeError: 'NoneType' object has no attribute 'shutdown'

Call Stack (most recent call first):
  /opt/ros/foxy/share/rosidl_cmake/cmake/rosidl_generate_interfaces.cmake:130 (rosidl_adapt_interfaces)
  CMakeLists.txt:28 (rosidl_generate_interfaces)


---
Failed   <<< px4_msgs [5.86s, exited with code 1]

Summary: 0 packages finished [6.23s]
  1 package failed: px4_msgs
  1 package had stderr output: px4_msgs

Not sure what's going on here. Any help is appreciated!

tried building voxl-ros2-foxy package. I thought maybe there's an issue with installing it from install_build_dependencies.sh so I was going to build it then clone the voxl-mpa-to-ros2 project from within the docker container to try to build it. Got same error 20 min into build...

Starting >>> rosidl_generator_c                                                                                                                           
Starting >>> rosidl_typesupport_introspection_c                                                                                                           
--- stderr: rosidl_generator_c                                                                                                                                                              
CMake Error at /opt/ros/foxy/share/rosidl_adapter/cmake/rosidl_adapt_interfaces.cmake:60 (message):
  execute_process(/usr/bin/python3 -m rosidl_adapter --package-name
  rosidl_generator_c --arguments-file
  /opt/ros/foxy-src/build/rosidl_generator_c/rosidl_adapter__arguments__rosidl_generator_c_interfaces.json
  --output-dir
  /opt/ros/foxy-src/build/rosidl_generator_c/rosidl_adapter/rosidl_generator_c
  --output-file
  /opt/ros/foxy-src/build/rosidl_generator_c/rosidl_adapter/rosidl_generator_c_interfaces.idls)
  returned error code 1:

  AttributeError processing template 'msg.idl.em'

  Traceback (most recent call last):

    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/resource/__init__.py", line 51, in evaluate_template
      em.BUFFERED_OPT: True,

  AttributeError: module 'em' has no attribute 'BUFFERED_OPT'

  

  During handling of the above exception, another exception occurred:

  

  Traceback (most recent call last):

    File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
      "__main__", mod_spec)
    File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
      exec(code, run_globals)
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/__main__.py", line 19, in <module>
      sys.exit(main())
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/main.py", line 55, in main
      pathlib.Path(relative_path), output_dir)
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/__init__.py", line 20, in convert_to_idl
      package_dir, package_name, interface_file, output_dir / 'msg')
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/msg/__init__.py", line 39, in convert_msg_to_idl
      expand_template('msg.idl.em', data, output_file, encoding='iso-8859-1')
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/resource/__init__.py", line 23, in expand_template
      content = evaluate_template(template_name, data)
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/resource/__init__.py", line 69, in evaluate_template
      _interpreter.shutdown()

  AttributeError: 'NoneType' object has no attribute 'shutdown'

Call Stack (most recent call first):
  /opt/ros/foxy/share/rosidl_cmake/cmake/rosidl_generate_interfaces.cmake:130 (rosidl_adapt_interfaces)
  CMakeLists.txt:46 (rosidl_generate_interfaces)


---
Failed   <<< rosidl_generator_c [29.5s, exited with code 1]

^ this was using dev branches and dependencies. Built inside qrb5165-emulator docker image v1.5
Again, I did all this months ago with sdk-1.1 version of everything and had no issues.

I was building voxl-ros2-foxy tag sdk-1.3.0 in a separate container as well. It looks like the build finished without errors, but when I run ./make_package.sh deb I get the following output"

qrb5165-emulator:~((sdk-1.2.0))(0.0.1)$ ./make_package.sh deb 
Package Name:  voxl-ros2-foxy
version Number:  0.0.1
Unknown host QEMU_IFLA type: 54
Unknown host QEMU_IFLA type: 32820
Unknown host QEMU_IFLA type: 56
Unknown host QEMU_IFLA type: 57
Unknown host QEMU_IFLA type: 54
Unknown host QEMU_IFLA type: 32820
Unknown host QEMU_IFLA type: 56
Unknown host QEMU_IFLA type: 57
run build before make_package

I don't know where I'm supposed to run build from after already running the ./build.sh script
^also thought it was weird that the tag is being displayed as (sdk-1.2.0). I cloned the gitlab repo with option "-b sdk-1.3.0"

Is there are an easy way to find out which versions of voxl-px4 are compatible with which versions voxl-mpa-to-ros2? Idk if you guys are tracking this internally or not. I think it might be good to have a a tag for voxl-mpa-to-ros2 to match each sdk tag of voxl-px4 where the firmware/message definitions change. I noticed that the latest tags for for both packages have at least one message definition conflict (that happens to be the message I need to work with)

Am I right to assume I could just drop the voxl-px4/px4-firmaware/msg directory in place of voxl-mpa-to-ros2/colcon_ws/src/px4_msgs/msg directory to match up message defintions when building voxl-mpa-to-ros2? If I take the CMakeLists.txt file out of the uorb message definition repo in the px4 firmware both message def repos look otherwise identical in terms of format

On a side note, I'm having an issue building the voxl-mpa-to-ros2 package. I'm getting the following errors for each version I've tried (tag sdk-1.1 and sdk-1.3., master branch). This is from my last attempt.

qrb5165-emulator:~((sdk-1.1.0))(0.0.1)$ ./build.sh qrb5165 
Starting >>> camera_calibration_parsers
Starting >>> image_transport
Starting >>> px4_msgs                                                                         
Starting >>> voxl_msgs
Starting >>> voxl_offboard_figure8
Finished <<< voxl_offboard_figure8 [4.82s]                                                                                                                                                
--- stderr: px4_msgs                                                                                                                                            
CMake Error at /opt/ros/foxy/share/rosidl_adapter/cmake/rosidl_adapt_interfaces.cmake:60 (message):
  execute_process(/usr/bin/python3 -m rosidl_adapter --package-name px4_msgs
  --arguments-file
  /home/root/colcon_ws/build/px4_msgs/rosidl_adapter__arguments__px4_msgs.json
  --output-dir /home/root/colcon_ws/build/px4_msgs/rosidl_adapter/px4_msgs
  --output-file
  /home/root/colcon_ws/build/px4_msgs/rosidl_adapter/px4_msgs.idls) returned
  error code 1:

  AttributeError processing template 'msg.idl.em'

  Traceback (most recent call last):

    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/resource/__init__.py", line 51, in evaluate_template
      em.BUFFERED_OPT: True,

  AttributeError: module 'em' has no attribute 'BUFFERED_OPT'

  

  During handling of the above exception, another exception occurred:

  

  Traceback (most recent call last):

    File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
      "__main__", mod_spec)
    File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
      exec(code, run_globals)
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/__main__.py", line 19, in <module>
      sys.exit(main())
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/main.py", line 55, in main
      pathlib.Path(relative_path), output_dir)
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/__init__.py", line 20, in convert_to_idl
      package_dir, package_name, interface_file, output_dir / 'msg')
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/msg/__init__.py", line 39, in convert_msg_to_idl
      expand_template('msg.idl.em', data, output_file, encoding='iso-8859-1')
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/resource/__init__.py", line 23, in expand_template
      content = evaluate_template(template_name, data)
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/resource/__init__.py", line 69, in evaluate_template
      _interpreter.shutdown()

  AttributeError: 'NoneType' object has no attribute 'shutdown'

Call Stack (most recent call first):
  /opt/ros/foxy/share/rosidl_cmake/cmake/rosidl_generate_interfaces.cmake:130 (rosidl_adapt_interfaces)
  CMakeLists.txt:28 (rosidl_generate_interfaces)


---
Failed   <<< px4_msgs [13.9s, exited with code 1]
--- stderr: voxl_msgs                                                                                                                             
CMake Error at /opt/ros/foxy/share/rosidl_adapter/cmake/rosidl_adapt_interfaces.cmake:60 (message):
  execute_process(/usr/bin/python3 -m rosidl_adapter --package-name voxl_msgs
  --arguments-file
  /home/root/colcon_ws/build/voxl_msgs/rosidl_adapter__arguments__voxl_msgs.json
  --output-dir /home/root/colcon_ws/build/voxl_msgs/rosidl_adapter/voxl_msgs
  --output-file
  /home/root/colcon_ws/build/voxl_msgs/rosidl_adapter/voxl_msgs.idls)
  returned error code 1:

  AttributeError processing template 'msg.idl.em'

  Traceback (most recent call last):

    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/resource/__init__.py", line 51, in evaluate_template
      em.BUFFERED_OPT: True,

  AttributeError: module 'em' has no attribute 'BUFFERED_OPT'

  

  During handling of the above exception, another exception occurred:

  

  Traceback (most recent call last):

    File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
      "__main__", mod_spec)
    File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
      exec(code, run_globals)
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/__main__.py", line 19, in <module>
      sys.exit(main())
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/main.py", line 55, in main
      pathlib.Path(relative_path), output_dir)
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/__init__.py", line 20, in convert_to_idl
      package_dir, package_name, interface_file, output_dir / 'msg')
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/msg/__init__.py", line 39, in convert_msg_to_idl
      expand_template('msg.idl.em', data, output_file, encoding='iso-8859-1')
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/resource/__init__.py", line 23, in expand_template
      content = evaluate_template(template_name, data)
    File "/opt/ros/foxy/lib/python3.6/site-packages/rosidl_adapter/resource/__init__.py", line 69, in evaluate_template
      _interpreter.shutdown()

  AttributeError: 'NoneType' object has no attribute 'shutdown'

Call Stack (most recent call first):
  /opt/ros/foxy/share/rosidl_cmake/cmake/rosidl_generate_interfaces.cmake:130 (rosidl_adapt_interfaces)
  CMakeLists.txt:22 (rosidl_generate_interfaces)


---
Failed   <<< voxl_msgs [13.9s, exited with code 1]
Aborted  <<< camera_calibration_parsers [21.0s]                                                                         
Aborted  <<< image_transport [22.6s]                             

Summary: 1 package finished [23.8s]
  2 packages failed: px4_msgs voxl_msgs
  2 packages aborted: camera_calibration_parsers image_transport
  2 packages had stderr output: px4_msgs voxl_msgs
  4 packages not processed

The error has been the same for each version I've tried to build. This is without making changes to the msg directory.
Any idea why this is happening? I've built these packages in the past successfully, not sure what changed

@tom I found the voxl-modem script in usr/bin, thanks! Swapping out the logic in the microhard_configure function with the v1.1.0 sdk revision worked for me.

My only suggested change would literally be reverting to the exact same logic for that function as was used in the previous version. I'm assuming it was changed for a reason,but idk what that reason is. I guess my question was more "why did this change and can we just change it back?". Is that more something I should raise as an issue on the gitlab repo or should I just submit a merge request like you said and let you guys figure it out?

Sorry not sure what best practices are when raising these kinds of things

@jmltt

Update - I found the issue. I didn't realize how the voxl-modem service worked so I went back and looked at the sdk-1.1 version (that worked fine for me) and the sdk-1.3.2 version that shipped out with the new vehicles and noticed there's a change in logic that doesn't make sense to me

relevant portion of v1.1.0 voxl-modem

voxl-sdk/utilities/voxl-modem/-/blob/sdk-1.1.0/scripts/voxl-modem
starting at line 587

    else:
        print '[INFO] Using usb0 for Microhard'
        while "usb0" not in dmesg_output:
            time.sleep(1)
            try:       
                dmesg_output = subprocess.check_output(["dmesg"], shell=True)
            except:
                print("waiting for usb0...")

        print '[INFO] usb0 detected, pulling up'
        if "qrb5165" in uname or "qrb5165-rb5" in uname or "m0104" in uname or "m0054" in uname or "m0052" in uname:
            print("[INFO] Opening config file...")
            config_file = open("/etc/modalai/voxl-modem.conf")

            print("[INFO] Converting to json...")
            config_dict = json.load(config_file)

            print("[INFO] Reading Microhard IP...")
            microhard_ip = config_dict["microhard_ip"]

            print("[INFO] Waiting for usb0 interface to be available")
            while "usb0" not in subprocess.check_output(["ifconfig"], shell=True):
                time.sleep(1)

            print("[INFO] Setting IP to:", microhard_ip) 
            subprocess.call(["ifconfig", "usb0", microhard_ip])
        else:                                                            
            subprocess.call(["ifup", "usb0"])

^ this just checks for "usb0" to show up as an available interface in the "ifconfig" call then assigns the appropriate ip address (microhard_ip) to that interface with the call to subprocess.call(["ifconfig", "usb0", microhard_ip])

relevant portion of v1.3.2 voxl-modem
voxl-sdk/utilities/voxl-modem/-/blob/sdk-1.3.2/scripts/voxl-modem
starting at line 610

    else:
        print '[INFO] Using usb0 for Microhard'
        while "usb0" not in dmesg_output:
            time.sleep(1)
            try:       
                dmesg_output = subprocess.check_output(["dmesg"], shell=True)
            except:
                print("waiting for usb0...")

        print '[INFO] usb0 detected, pulling up'
        if "qrb5165" in uname or "qrb5165-rb5" in uname or "m0104" in uname or "m0054" in uname or "m0052" in uname:
            print("[INFO] Opening config file...")
            config_file = open("/etc/modalai/voxl-modem.conf")

            print("[INFO] Converting to json...")
            config_dict = json.load(config_file)

            print("[INFO] Reading Microhard IP...")
            microhard_ip = config_dict["microhard_ip"]
            while(True):
                print("Waiting for 'usb0' to have the correct IP address...")
                try:
                    Execute the command to get network interface information
                    result = subprocess.check_output(["ifconfig usb0"], shell=True)
                    print(result)
                    # Check if the command executed successfully
                    if "inet 192.168.168." in result:
                        break

                except Exception as e:
                    print("IP not yet set")  
                time.sleep(1)

            print("[INFO] Setting IP to:", microhard_ip) 
            subprocess.call(["ifconfig", "usb0", microhard_ip])
        else:                                                            
            subprocess.call(["ifup", "usb0"])

^ since this is blocking on a check for ifconfig usb0 to already show up with an ip address assigned to the 192.168.168. subnet (and it's not because some network service is assigning an address on a different subnet via assumingly dhcp first) it never gets to the call to set the correct ip address for the microhard modem for the usb0 interface

I'm not sure why it's necessary to check for the existence of a usb0 interface that already has an ip address on the 192.168.168 subnet, I'm assuming it never will by default. Even if I could set it up to (maybe change the etc/networks file to use the correct subnet) I'm not sure I'd want to since I could have ip conflicts with other devices on the network on boot

Follow up questions:

• can the logic in this script in the voxl-modem package be reverted so it doesn't hang when it encounters the wrong ip here and just check for the interface and sets the correct one as done previously?
• where is this shell script located in the file system so I can change it in the interim without rebuilding the package? (or do I have to rebuild the package to realize changes regardless?)

also if anyone has experience turning off mac address randomization as per the second part of my original post I'd appreciate any tips

Thanks

We just got a few of the new sentinels with microhard carrier add-on boards. I set up the radios, but with these (as opposed to some older vehicles we got about two years ago) something is assigning an ip address on boot such that the voxl-modem service never runs successfully.

The journalctl logs show that voxl-modem is constantly "waiting for usb0 to have correct ip address" (e.g. the one I assigned while running voxl-configure-modem). The ip address that gets assigned is random every boot and on the same subnet as referenced in the file /etc/networks in the line

link-local 169.254.0.0

So I'm assuming some service is calling this on boot and assigning a random ip. Does anyone know how I can disable this? I found the voxl-static-ip script and updated it with the correct address and it works, but I don't want to have have to run it every time I boot a vehicle. Enabling the voxl-static-ip service doesn't work, I have to run the script from the terminal.

Since these new vehicles also come with a usb wifi dongle plugged into the carrier board (which is awesome) I also need to know how to turn off mac address randomization for that adapter. I need to have the adapter's mac address fixed in order to be able to access our network and I noticed it changes every time I run ifconfig. Does anyone know how to accomplish that as well?

Thanks

Can someone give me a high-level explanation of the main differences between modalai's branch of the PX4 firmware and whatever the release it was forked from?

The next release of PX4 (v1.15) has some features I'd like to test on the Sentinel and I'm wondering if when it's released I could rebuild voxl-px4 linking to that branch or if there's voxl specific stuff I'd be missing in terms of drivers or board specific set-up stuff

@modaltb We are ordering more Sentinels and we need NDAA compliance so we went with the ghost atto receiver. We wanted to order each vehicle with a controller, but I was confused about what we'd get because I didn't see and ghost atto compatible controllers available for standalone purchase on your site. I found this in the docs though so I'm assuming this is what it ships with, is that right?:

https://docs.modalai.com/orqa-ghost/

Do all Sentinels now ship out with the M0154?

Would it be possible to retrofit our older sentinels with ghost atto receivers?

I was looking at the product listing for the Sentinel and noticed the only RC receiver options listed are ELRS and Ghost Atto. The Sentinels I'm using have Spektrum receivers. Is that no longer an option? Are the ghost atto receivers compatible with a spektrum transmitter and if so is there any additional set-up required to bind them?

@Alex-Kushleyev the only immediate need I have for this is to subscribe to the vehicle_local_position topic and republish it for use in an offboard controller i'm testing that requires a state estimate for feedback that includes filtered acceleration (PX4 only streams the truncated local position ned data over mavlink). I want to transition from mavlink to ROS-based offboard communications in general though in case there are some random uorb topics I end up needing data from that aren't supported over mavlink.

I don't think there's a wide general need for this, but I need to learn how to do it and since I've never used ROS before I was hoping there was some example code I could look at. I'm sure I can figure it out though looking at the existing voxl-mpa-to-ros2 code

@Zachary-Lowell-0 Awesome, thanks for fixing this I really appreciate it!

@Zachary-Lowell-0 Sounds good, thank you!