feat(bluetooth_monitor): add functionality to monitor Bluetooth connection

[ito-san]

Description

Add a feature to monitor a Bluetooth connection to a wireless controller.

Related links

#859

Tests performed

0. Assign capability to l2ping_service.

   sudo setcap 'cap_net_raw+eip' ./build/bluetooth_monitor/l2ping_service
   

1. Connect a Bluetooth device.

2. Run l2ping_service and bluetooth_monitor.

   ./build/bluetooth_monitor/l2ping_service
   ros2 launch bluetooth_monitor bluetooth_monitor.launch.xml
   

3. Run RQt Runtime Monitor.

   ros2 run rqt_runtime_monitor rqt_runtime_monitor 
   

4. Confirm the diag status is OK.
   

5. Keep a Bluetooth device away, then confirm the diag status is ERROR.
   

6. Bring the device closer, then confirm the diag status returns to OK.
   

Notes for reviewers

n/a

Pre-review checklist for the PR author

The PR author must check the checkboxes below when creating the PR.

• I've confirmed the contribution guidelines.
• The PR follows the pull request guidelines.

In-review checklist for the PR reviewers

The PR reviewers must check the checkboxes below before approval.

• The PR follows the pull request guidelines.
• The PR has been properly tested.
• The PR has been reviewed by the code owners.

Post-review checklist for the PR author

The PR author must check the checkboxes below before merging.

• There are no open discussions or they are tracked via tickets.
• The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

[codecov]

Codecov Report

Merging #862 (62df70a) into main (a0ef0e9) will decrease coverage by 0.18%.
The diff coverage is 0.00%.

❗ Current head 62df70a differs from pull request most recent head 6ed2530. Consider uploading reports for the commit 6ed2530 to get more accurate results

@@           Coverage Diff            @@
##            main    #862      +/-   ##
========================================
- Coverage   9.71%   9.52%   -0.19%     
========================================
  Files        953     945       -8     
  Lines      64012   58493    -5519     
  Branches   11181   10638     -543     
========================================
- Hits        6217    5570     -647     
+ Misses     52632   48206    -4426     
+ Partials    5163    4717     -446     

Flag	Coverage Δ		*Carryforward flag
differential	0.00% <0.00%> (?)
total	9.57% <ø> (-0.12%)	⬇️	Carriedforward from adce7ae

*This pull request uses carry forward flags. Click here to find out more.

Impacted Files	Coverage Δ
...nitor/include/bluetooth_monitor/service/l2ping.hpp	0.00% <0.00%> (ø)
...ude/bluetooth_monitor/service/l2ping_interface.hpp	0.00% <0.00%> (ø)
system/bluetooth_monitor/service/l2ping.cpp	0.00% <0.00%> (ø)
...ystem/bluetooth_monitor/service/l2ping_service.cpp	0.00% <0.00%> (ø)
system/bluetooth_monitor/service/main.cpp	0.00% <0.00%> (ø)
system/bluetooth_monitor/src/bluetooth_monitor.cpp	0.00% <0.00%> (ø)
system/default_ad_api/src/interface.cpp	0.00% <0.00%> (-71.43%)	⬇️
...ng_simulator/vehicle_model/sim_model_interface.hpp	0.00% <0.00%> (-66.67%)	⬇️
...d_api_msgs/srv/interface_version__type_support.cpp	0.00% <0.00%> (-54.55%)	⬇️
.../_autoware_ad_api_msgs_s.ep.rosidl_typesupport_c.c	0.00% <0.00%> (-51.81%)	⬇️
... and 650 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a0ef0e9...6ed2530. Read the comment docs.

[xmfcx]

@ito-san thank you for this contribution!

I looked into the code briefly and have some questions.

I saw the joystick figure in the system/bluetooth_monitor/docs/block_diagram.drawio.svg and is there any advantage of using this node over https://github.com/ros-drivers/joystick_drivers/tree/main/joy for such a case? (I know this node is meant for any generic bluetooth device.)

I've looked into BlueZ and found this answer: https://stackoverflow.com/a/56959888/4520129

It says people don't use BlueZ code directly anymore, they either use DBUS(low level) or GattLib(preferred). Example: https://github.com/labapart/gattlib/blob/master/examples/read_write/read_write.c

This way bluetooth communication part would be offloaded to that library, what do you think?

Edit:

You could even make this a node outside autoware to let people use it in their projects, I couldn't find a decent ros-bluetooth package.

[ito-san]

@xmfcx The joy_driver itself does not have functionality for alive monitoring of Bluetooth device and publishing error.
As far as taking a look at joy_driver, maybe it can be possible to resolve this issue by monitoring event rate but I'm not sure.
https://github.com/ros-drivers/joystick_drivers/blob/2bc2f6a32688e9a9f235e6e46dda443cd09574c2/joy/src/joy_node.cpp#L106

Do you think it would be better to add functionality to joy_driver?

DBus in BlueZ is another option to communicate with Bluetooth device, however I need more time to investigate if DBus API supports L2ping which is in L2CAP, low layer in Bluetooth software stack.

The command line execution of L2ping in another process does not violate LGPL liscence and it doesn't take long.
How about this way?

[xmfcx]

Do you think it would be better to add functionality to joy_driver?

@ito-san it might be a good idea to do that. Since the node itself is communicating with the device, I am guessing it would know if it lost connection. And this information could be published by it.

The command line execution of L2ping in another process does not violate LGPL license and it doesn't take long.

If you are talking about using l2ping with system() function, it would work but it is not a pretty way of solving it. @kenji-miyake thought on this?

[ito-san]

@xmfcx

If you are talking about using l2ping with system() function, it would work but it is not a pretty way of solving it.

I was thinking about to use boost::process but I am facing very difficult problem which seems specific to l2ping itself. So I am considering to use joy_driver for now.

[ito-san]

I found the issue When the connection with the wireless receiver is lost, the last received command is sent infinitely in joystick_drivers.
Need to consider another option.

[ito-san]

@xmfcx @kenji-miyake
I resolved a issue related to boost::process.
And I think joy_driver is not better solution because this feature may be used for other bluetooth devices such as a mouse, keyboard, speaker, etc.
For now, I would like to use boost::process and I will try to use D-Bus or GattLib in the future because it would take much time to investigate.

[h-ohta]

@ito-san Could you fix clang-tidy failure?

[ito-san]

@ito-san Could you fix clang-tidy failure?

@h-ohta Fixed in 84ff216

[h-ohta]

works fine