Topics created by jmltt

@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

@jmltt SDK testing for Sentinel ended at SDK 1.4.0

That doesn't mean that newer releases won't work, it just means we don't put it through the SW QA testing cycles that we do with our newer platforms.

You likely won't see any major performance improvements on Sentinel with newer SDK releases but there may be some nice quality of life additions such as helper scripts, voxl-portal updates and others.

If you have any questions about any specific packages feel free to ask.

@Zachary-Lowell-0

Thank you for the feedback! This was very helpful

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

@jmltt Each microhard modem hosts a web server that can be accessed via it's IP address. You can see what data is available and can likely script a query for signal strength. (They may have an API but it's not something we've investigated)

@Eric-Katzfey Awesome, thanks for the feedback!

@brandon The latest voxl-mavlink-server is available here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-mavlink-server_1.4.12-202511040816_arm64.deb. This has added configuration for the GCS ports and also fixes the above issue so that it now responds to the correct port.

@jmltt good find - I will test on my voxl2 once your fork has had a MR made.

Zach

@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

@Jetson-Nano If you want v1.15 then you just build from mainline, not from our fork.

Yes new sentinels ship with M0154s. Let me check with the production team about retroffiting

@brahim
@tom

Hi and sorry for the delayed response.

Main result : no response from the rb5
Comments: the offboard code example in cpp is running in Gazebo but I cannot get the drone to arm via ROS2 run px4_ros_com offboard_control.

This is the output from my terminal
~/ros2_ws$ ros2 run px4_ros_com offboard_control
Starting offboard control node...
[INFO] [1729601421.989530505] [offboard_control]: Arm command send

Notes: The offboard setting is "off" not "false" on the voxl-vision-hub.conf.

Do you have a recent tutorial on how to use ROS2 with the rb5?

Best wishes,

@Alex-Kushleyev

Please could you provide a simple example like arm() and disarm() or something similar to the offboard_control.cpp?

Best wishes,

@jmltt You do not need RC for offboard mode. However, you will have to look and see how your failsafes are set for lost RC to see what it will do. But definitely make sure that you are doing things in a safe manner!

@Eric-Katzfey that did it, thanks!