-
Notifications
You must be signed in to change notification settings - Fork 2
Bluetooth Troubleshooting
To monitor what the bluetooth is currently doing on the Jetson side, we recommend using bluetoothctl. While this is running, you'll be able to see which devices connect or disconnect and what services are available. To get the most out of this tool, launch it before starting the ROS nodes and keep it open while the nodes run. To get started, open a new Terminal window then type:
sudo bluetoothctl
You should see something like this:
Agent registered
[CHG] Controller 00:12:A3:4B:5C:DE Pairable: yes
Device F0:08:D1:CE:D8:52 Sailbot - Trim Tab
The [CHG] Controller line refers to the USB bluetooth dongle plugged into the Jetson (Note: The dongle address will not match the one in the example above). If you don't see a line for the controller, then check to make sure the dongle is plugged in.
You may or may not see additional devices listed below the controller. This will depend on a variety of factors including, but not limited to:
- How far away bluetooth devices are
- If the devices are on or off and whether or not they are advertising
- Whether or not the Jetson is actively scanning for devices
If the trim tab controller is visible in the list, then you should be able to connect to it. You can do so manually by typing connect F0:08:D1:CE:D8:52 (where F0:08:D1:CE:D8:52 is the bluetooth address of the trim tab controller). If it fails to connect, be sure that nothing else is connected to the trim tab controller and that the wingsail is within range and turned on (the range should be fine if the wingsail is mounted on the boat). Once you have verified that you can connect, be sure to disconnect by typing disconnect, otherwise you may see unexpected behavior when attempting to run the ROS nodes.
DO NOT attempt to pair the trim tab controller using bluetoothctl. We found that this creates issues.
If you run the ROS nodes while bluetoothctl is running, you will see some helpful debug information. Among the printed information, you should see something that looks like this:
[CHG] Device F0:08:D1:CE:D8:52 Connected: yes
[CHG] Device F0:08:D1:CE:D8:52 ServicesResolved: yes
If you see this, you're in business!
You may also see some additional details such as which services or characteristics are available and what the RSSI is. If you do not see ServicesResolved: yes, then you aren't yet fully connected. Something may be configured incorrectly. In some cases, if something is not configured properly or the connection is weak, you may also see the connection drop immediately after connecting or even toggle back and forth when the ROS node attempts to reconnect. Any of these symptoms suggest that something isn't quite right. Also be on the lookout for lengthy connection attempts. If you see the controller toggle between Discovering: yes and Discovering: no several times without connecting, the trim tab controller may be out of range.
When looking at the RSSI, you will want a higher value. Something around -40 or -50 dB is considered good. Anything around -70 dB or lower is not so good. At that point you may start having connection issues. To improve RSSI if it is too low, limit the number of obstructions (such as walls) and decrease the distance between devices. If that still doesn't work, you could replace the bluetooth dongle with one that has a higher receiver sensitivity or an antenna with a higher gain (although the dongle we have now should be plenty).
To debug issues with the trim tab controller, you can use a mobile device to connect to it directly. Check out the Wiki in the rigid_wing repo for more details.
You may receive an error similar to the one below the first time you run the trim_tab_comms node.
org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call",...
If you receive this error, try adding your user account to the bluetooth group.
sudo usermod -a -G bluetooth <your-username>
If that doesn't work, try adding the following to your /etc/dbus-1/system.d/bluetooth.conf file.
<policy user="sailbot">
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.GattCharacteristic1"/>
<allow send_interface="org.bluez.GattDescriptor1"/>
<allow send_interface="org.freedesktop.DBus.ObjectManager"/>
<allow send_interface="org.freedesktop.DBus.Properties"/>
<allow send_type="method_call"/>
</policy>
Note: If you do not have a user called sailbot be sure to replace the example above with your username!
On Linux, you may encounter an issue where nothing is returned if you attempt to read characteristics from the battery service (particularly the battery level). This is due to a conflict involving a battery plugin for the BlueZ backend. Disabling the battery plugin should resolve this issue. Note that the OS will loose access to the battery service, but you will now be able to read these characteristics using Bleak.
To disable the battery plugin, run sudo systemctl edit bluetooth.service and add the following:
[Service]
ExecStart=
ExecStart=-/usr/lib/bluetooth/bluetoothd -P battery
Save the new configuration and restart the service (sudo service bluetooth restart) in order for the changes to take effect.