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

Has anybody implemented something similar to voxl_mpa_to_ros2 that provides data flow in the opposite direction, like subscribing to the uorb topics published by px4 and exposed via ros2 topics and re-publishing them for onboard use over of the MPA? If so would you be able to point me to example code?

I'm brand new to ROS/ROS2 so I'm still trying to run through tutorials and figure out how it all works

Thanks!

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)

@Alex-Kushleyev That is the type of cable I'd need but I've actually ordered that one (MCBL-00009-1) before for a separate application and just eyeballing it it's about half the length I'd need. Here's a picture of the set-up

Also, in addition to trying to troubleshoot this adapter/cable I need to retrofit four older Sentinel models (were only shipped with the microhard carrier board, no wifi adapter) with wifi adapters so if it's possible I'd like to just purchase five assemblies (usb to jst and wifi adapter shrink wrapped together). If you guys don't have any of that cabling already made or there's no mechanism for me to order them as a set that's totally fine. We can order the piece parts and make the cabling ourselves, it'd just be easier for us to order them if that's possible.

@jmltt This is still a problem. I reverted the changes for static IP set-up and am just using DHCP so the settings are the same as how the quad was shipped. Still getting cannot enable, usb cable bad? messages after the wifi adapter if recognized on start-up. I'm hoping the the wifi adapter or cabling is just bad and not the port on the carrier board.

[    2.361738] usbcore: registered new interface driver 8188eu
[    2.447119] usbcore: registered new interface driver rtl8821cu
[    2.499469] usbcore: registered new interface driver rtl88XXau
[    2.912052] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[    3.048404] usb 1-1: New USB device found, idVendor=0424, idProduct=2514, bcdDevice= b.b3
[    3.048410] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    4.220352] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[    5.022237] f_cdev_alloc: port_name:at_usb0 (ffffffe44efe8000) portno:(0)
[    5.024793] f_cdev_alloc: port_name:at_usb1 (ffffffe44c25f400) portno:(1)
[    5.068782] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[    5.069166] usb 1-1-port4: attempt power cycle
[    6.208341] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[    6.280130] usb 1-1.4: new high-speed USB device number 6 using xhci-hcd
[    6.280207] usb 1-1.4: Device not responding to setup address.
[    6.484149] usb 1-1.4: Device not responding to setup address.
[    6.688146] usb 1-1.4: device not accepting address 6, error -71
[    6.688417] usb 1-1-port4: unable to enumerate USB device
[    7.673010] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[    8.520477] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[    8.520664] usb 1-1-port4: attempt power cycle
[    9.660805] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[   10.500523] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[   10.500714] usb 1-1-port4: unable to enumerate USB device

When I take the lid off the and reseat the JST connector it starts working again. Maybe the problem is the lid clamping down on the wires and slowly pulling the connector out or maybe it's just bad wires.

Is there any way to order a replacement assembly? Like the way it's shipped, 4-pin JST to to USB to wifi adapter with the shrink wrap and everything? I know Sentinels EOL but I'm assuming you might have the same wifi adapter set-up for another platform

If this is more of a customer support question can someone point me to an email address to direct this to? Thanks

@jmltt

Looks the same bug as here: https://github.com/PX4/PX4-Autopilot/issues/22148

Added the change from this commit and it looks like it works now: https://github.com/PX4/PX4-Autopilot/pull/22194/commits/38f3c711084b349cb9ed82cf44ff181c6a40738a

@Zachary-Lowell-0 said in SITL using VOXL2 PX4 software:

That is correct it would only be able to support one vehicle. You can test SITL multi vehicles on your parent computer running SITL, however the modules and drivers running in that environment would differ from what is running on the voxl2.

I'm trying to do the same thing as the original poster (see https://forum.modalai.com/topic/4930/voxl-px4-vs-mainline-px4-sitl-questions)

Can you explain generally the differences between the code running on the vehicle vs a SITL build? Is the flight control stack (save sensor input) mostly the same if building the sitl from the px4-firmware branch that's on the quads? I'm going to try out HITL using modalai's docker image as well, but I'd like a SITL build that's going to be as close as possible to what's running on the quads so I can test multi-vehicle control via ros2

Background: I'm trying to set up a multi-vehicle sim environment using gazebo and px4 sitl. I've got 4 quads on SDK v1.3.5. I wanted to pull the voxl-px4/modalai px4-firmware version from that release to build px4_sitl on my local machine so I can test in sim against a version that's going to most representative of firmware on the quads.

I'm building inside a ubuntu 22 docker container after running ./px4-firmware/Tools/setup/ubuntu.sh. The px4_sitl build failed because of the bug mentioned here: https://forum.modalai.com/topic/3510/px4-build-broken-for-sitl-targets

I implemented the poster's fix (https://github.com/modalai/px4-firmware/pull/61) and was able to build px4-sitl but when I run it I get the following errors:

ERROR [gz_bridge] timed out waiting for clock message
ERROR [gz_bridge] Task start failed (-1)
ERROR [init] gz_bridge failed to start
ERROR [px4] Startup script returned with return value: 256

Are there extra steps I missed that are required to build px4_sitl from modalai's px4-firmware fork vs the mainline px4? Is it just not going to work if I try to build it on my laptop?

If I have to pull a mainline px4 branch to build sitl on my laptop, is there a specific release (e.g. 1.14.0-1.14.4) that would be most analogous to the past/current branches of modalai's px4-firmware? The voxl-px4 version I have installed on the quads is using the 1.14.0-2.0.85 firmware.

I'm doing multi-vehicle offboard control via ros2 w/ ext vision for state estimation, mostly testing code that publishes trajectory setpoints. I'd like to make sure at least the controller and estimator code is as close as possible to what's running on the quads.

@Zachary-Lowell-0

Thank you for the feedback! This was very helpful

Will SDK release testing end (or has it already) for EOL dev drones like the Sentinel?

I noticed on the release page that SDK v1.5.0 was the last release that was tested on the Sentinel platform. Does this mean future releases (1.6+) will no longer be tested for the Sentinels?

If so, are the platforms currently in production similar enough (given they all use VOXL2 but with different sensors/hardware) to the Sentinel platform such that I can continue updating with future SDK releases or should I stop at v1.5.0?

I have several Sentinel drones with ros2 foxy installed via voxl-ros2-foxy and I need to switch to running ros2 humble on the quads. From what I've seen there's no way to get around having to run it via docker, but I have a few questions:

1. Are there instructions on installing docker on target? The modalai guide (https://docs.modalai.com/docker-on-voxl/) references to just use the docker instructions to install via apt, but the docker install instructions linked to require an ubuntu o.s. newer than 20.04 so I wasn't sure if it would work.

2. In switching to ros2 humble onboard the voxl2 do I need to update the dds client module and rebuild voxl-px4 and rebuild the voxl-microdds-agent as well? I'm assuming that if they're built to work with ros2 foxy they're going to be dependent on older versions of fast-dds than what humble would be using and might not be compatible

3. Are there any example docker run commands that are recommended for running containers onboard voxl2 with proper permissions for using the networking interfaces and mounting whatever volumes ros2 would need to run and work with px4?

Basically if you guys are running ros2 humble out of docker on voxl2 what did your set-up look like and did you run into any compatibility issues?

Thanks!

@Aaron-Porter I'm sure the system id fix might have resolved the issue. I just find having separate ports for each vehicle to establish a connection over a cleaner option. This isn't an issue for me anymore, I was just responding to the question on the approach I used to resolve it

I just disconnected/reconnected the USB to 4-pin JST cable from the microhard carrier board and rebooted the vehicle. Now the wlan0 interface has been up the entire time the vehicle's on, but none of the other devices on the vLAN the wifi adapter is connected to can ping the vehicle over wifi.

Output from dmesg looks the same except the following output after the microhard interface is found:

[   26.460342] usb 1-1.2: new high-speed USB device number 4 using xhci-hcd
[   26.550901] usb 1-1.2: New USB device found, idVendor=1f94, idProduct=3002, bcdDevice= 4.14
[   26.550915] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   26.550922] usb 1-1.2: Product: pMDDL2450AES256
[   26.550929] usb 1-1.2: Manufacturer: Microhard
[   26.550935] usb 1-1.2: SerialNumber: 1592348
[   26.639101] rndis_host 1-1.2:1.0 usb0: register 'rndis_host' at usb-xhci-hcd.0.auto-1.2, RNDIS device, 16:4f:08:e4:e1:09
[   26.643401] cdc_acm 1-1.2:1.2: ttyACM0: USB ACM device
[   33.765387] vdd_tof: disabling
[   33.765393] vdd_hap_boost: disabling
[   37.240138] hrtimer: interrupt took 112083 ns
[  101.412343] boot log copy done
[  114.937520] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x41b08
[  233.747906] perf: interrupt took too long (2778 > 2500), lowering kernel.perf_event_max_sample_rate to 72000
[  339.990578] perf: interrupt took too long (3473 > 3472), lowering kernel.perf_event_max_sample_rate to 57500
[  386.060248] perf: interrupt took too long (4425 > 4341), lowering kernel.perf_event_max_sample_rate to 45000