Topics created by jmltt

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!

@jmltt I understand it is personal preference, I just wanted to give more detail on the issue that you were originally seeing incase anyone else ran into the same problem. Shouldn't happen in the future with the recent changes, but some still use older SDK versions.

@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!

@Moderator Thanks for the response. Follow up question, are the voxl-side timesync requests only used for updating gps timestamps?

After reading the code you linked and running mavlink-server in timesync debug mode I think that the only thing not working is the voxl timesync requests. It looks like when I start sending hil_gps or odometry mavlink messages to the autopilot pipe, one of the autopilot's responses to the voxl timesync requests is dropped or comes in after a new value for last_voxl_time_sent is generated. Then the timesync handler can't recover because it's getting responses that are 1 step behind moving forward (see below).

Since it looks like it continues to get reasonable values for now-ts1 for the autopilot requests, I don't think this is an issue depending on what voxl-side timesync is being used for. Not sure why I'm getting the RTT too high warning in my PX4 log though

output from mavlink server timesync debug mode at the point when I started sending odom/gps mavlink messages to the autopilot:

sending our own ts request at 408744677609 ap ms ahead of voxl: -0.2ms timesync: now-ts1 = 0.6ms sending our own ts request at 408845331615 ap ms ahead of voxl: -0.3ms timesync: now-ts1 = 0.9ms sending our own ts request at 408945169337 timesync: now-ts1 = 0.2ms sending our own ts request at 409044439310 timesync: now-ts1 = 0.3ms sending our own ts request at **409145346227** timesync: now-ts1 = 0.5ms sending our own ts request at **409244599326** unknown timesync request ts1 = **409145346227** tc1 = 409263819000 last_voxl_time_sent = 409244599326 timesync: now-ts1 = 0.3ms sending our own ts request at 409345147918 unknown timesync request ts1 = **409244599326** tc1 = 409406867000 last_voxl_time_sent = 409345147918 timesync: now-ts1 = 0.2ms sending our own ts request at 409445248290 unknown timesync request ts1 = 409345147918 tc1 = 409506047000 last_voxl_time_sent = 409445248290 timesync: now-ts1 = 0.2ms sending our own ts request at 409545084726 unknown timesync request ts1 = 409445248290 tc1 = 409608198000 last_voxl_time_sent = 409545084726 timesync: now-ts1 = 0.4ms sending our own ts request at 409645091472 unknown timesync request ts1 = 409545084726 tc1 = 409717154000 last_voxl_time_sent = 409645091472

@Eric-Katzfey

Thanks for clearing that up. I didn't know I could access it from the voxl's file system but I just found the script in usr/bin. I'll vim into it and change what I need. Thanks!