Topics created by jmltt

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

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).

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

@jmltt no, if you use the standard battery all should work as expected

@Alex-Kushleyev Thanks for getting back to me

I can't fly again until tomorrow but I will upload the log after we attempt a hover test. We were actually able to fly on Monday and we could achieve stable flight in acro mode off a fresh battery but only for about 30 seconds. We're getting new batteries to see if that's contributing. Don't know why it would cause the system (or at-least PX4) to continuously crash/reboot though.

Here are the results of the esc checks:

voxl2:/usr/share/modalai/voxl-esc-tools$ ./voxl-esc-scan.py
Detected Python version : 3.6.9 (default, Mar 10 2023, 16:46:00)
[GCC 8.4.0]
Found voxl-esc tools bin version: 1.4
VOXL Platform: M0054
Detected RB5 Flight, VOXL2 M0054 or M0104!
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 2000000
Sending library name request: libslpi_qrb5165_io.so
Received standard error event 2
Sending initialization request
INFO: ESC(s) detected on port: /dev/slpi-uart-2, baud rate: 2000000, protocol: firmware
INFO: Verifying ESC Params..

INFO: ESC Information:
INFO: ---------------------
ID : 0
Board : version 31: ModalAi 4-in-1 ESC V2 RevB (M0049)
UID : 0x2033393953435708003A0048
Firmware : version 39, hash d4fe8e3d
Bootloader : version 183, hash 0a80a32a
Params : ../voxl-esc-params/Sentinel_V1/Sentinel_V1.xml

ID : 1 Board : version 31: ModalAi 4-in-1 ESC V2 RevB (M0049) UID : 0x203339395343570800340041 Firmware : version 39, hash d4fe8e3d Bootloader : version 183, hash 0a80a32a Params : ../voxl-esc-params/Sentinel_V1/Sentinel_V1.xml ID : 2 Board : version 31: ModalAi 4-in-1 ESC V2 RevB (M0049) UID : 0x2033393953435708003A004F Firmware : version 39, hash d4fe8e3d Bootloader : version 183, hash 0a80a32a Params : ../voxl-esc-params/Sentinel_V1/Sentinel_V1.xml ID : 3 Board : version 31: ModalAi 4-in-1 ESC V2 RevB (M0049) UID : 0x2033393953435708003A0056 Firmware : version 39, hash d4fe8e3d Bootloader : version 183, hash 0a80a32a Params : ../voxl-esc-params/Sentinel_V1/Sentinel_V1.xml

voxl2:/usr/share/modalai/voxl-esc-tools$ ./voxl-esc-verify-params.py
Detected Python version : 3.6.9 (default, Mar 10 2023, 16:46:00)
[GCC 8.4.0]
Found voxl-esc tools bin version: 1.4
VOXL Platform: M0054
Detected RB5 Flight, VOXL2 M0054 or M0104!
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 2000000
Sending library name request: libslpi_qrb5165_io.so
Received standard error event 2
Sending initialization request
INFO: ESC(s) detected on port: /dev/slpi-uart-2, baud rate: 2000000
INFO: Params from ID 0 match ../voxl-esc-params/Sentinel_V1/Sentinel_V1.xml
INFO: Params from ID 1 match ../voxl-esc-params/Sentinel_V1/Sentinel_V1.xml
INFO: Params from ID 2 match ../voxl-esc-params/Sentinel_V1/Sentinel_V1.xml
INFO: Params from ID 3 match ../voxl-esc-params/Sentinel_V1/Sentinel_V1.xml
INFO: Success! Params in all ESCs are valid and identical.

Let me know if you'd like me to look at anything specifically in the flight logs from our previous attempts. Otherwise I'll follow up tomorrow after our next attempt. Thanks!