Error running Apptainer bolt demo


I can successfully run examples with the masterboard SDK, however I am not attempting to run some of the robot_interfaces_bolt scripts, namely bolthumanoid_show_data, But I keep getting the following error, any thoughts on what I should do based on this error Log?

apptainer run -e solo_bolt_robot_latest.sif ros2 run robot_interfaces_bolt bolthumanoid_show_data ./config.yml

Using single process time series.
[2023-11-24 14:00:47.869] [BoltHumanoidDriver] [e[36mdebuge[m] Initialize BoltHumanoid
if_name: enp0s31f6
Using Ethernet (enp0s31f6)
Unable to start because the program could not set priority on low level link: Bad file descriptor
[2023-11-24 14:00:47.884] [BoltHumanoidDriver] [e[36mdebuge[m] Enable motors
Packet send error: Bad file descriptor
Packet send error: Bad file descriptor
Socket receive, error : Bad file descriptor
Socket receive, error : Bad file descriptor
Socket receive, error : Bad file descriptor

For communication with the master board root permissions are needed (*), so you need to run apptainer with sudo. If that doesn’t fix the error, the only other thing I can think of is a wrong interface name in the config file (unfortunately both cases result in rather vague error messages).

(*) It might also be possible to avoid running everything as root by using an appropriate user group. I never spent the time to find out which exact part does require the higher permissions but if someone here knows, I’d be happy to hear!

1 Like

@felixwidmaier Thank you Felix, that fixed it, but it still times out (on both calibration and show_data):

sudo apptainer run -e solo_bolt_robot_latest.sif ros2 run bolt bolt_humanoid_hardware_calibration enp0s31f6
if_name: enp0s31f6
Using Ethernet (enp0s31f6)
Controller is set up.
Shutting down connection (enp0s31f6)
ERROR: Robot communication timedout.
terminate called after throwing an instance of ‘std::runtime_error’
what(): Timeout during Robot::WaitUntilReady().
[ros2run]: Aborted

For avoidance of doubt, does everything “BoltHumanoid” still apply to the 6 dof Bolt? As I run the simulation it looks like a different Robot.

That might indeed be the issue. The “BoltHumanoid” has an additional simple torso, adding three more joints. So I assume when you use it with a lower-body-only-Bolt, WaitUntilReady times out waiting for the non-existing joints.

I only implemented the interface for “BoltHumanoid” so far. I’m afraid I won’t have time to add a proper one for the basic “Bolt” anytime soon (the current implementations for our different robots contain quite a lot redundant code, which I want to refactor first). But if you want to give it a try with a quick-and-dirty attempt I think mainly the following changes would be necessary in robot_interfaces_bolt:

  • Change Vector9d to Vector6d everyhere.
  • In the driver class, change the type of bolt::BoltHumanoid bolthumanoid_; to bolt::Bolt.

If you’re lucky, this is already be enough. If not, I’m happy to assist with resolving any problems that come up.

1 Like

@felixwidmaier Hi Felix, thank you. I have tried, and tried troubleshooting on my own for a few days here. When I strictly make your suggested updates I receive the following compile error:

Starting >>> robot_interfaces_bolt
— stderr: robot_interfaces_bolt
In file included from /home/ben/apptainer_dev/my_workspace/workspace/src/robot_interfaces_bolt/src/bolthumanoid_driver.cpp:1:
/home/ben/apptainer_dev/my_workspace/workspace/src/robot_interfaces_bolt/include/robot_interfaces_bolt/bolthumanoid_driver.hpp:40:11: error: ‘Bolt’ in namespace ‘bolt’ does not name a type
40 | bolt::Bolt bolthumanoid_;

I then tried to include the lower level bolt drivers vs bolt_humanoid drivers, but that doesn’t seem to support the same functions.

Do you have any thoughts on next steps?

Damn, I took a look myself, it seems the bolt::Bolt class is actually lacking quite a lot of functions (that’s part of what I eventually want to fix with refactoring). Then I would suggest another route: Hacking bolt::BoltHumanoid to work with only 6 joints. I did a quick attempt with the following changes:

In the package robot_interfaces_bolt:

diff --git a/include/robot_interfaces_bolt/basic_types.hpp b/include/robot_interfaces_bolt/basic_types.hpp
index b221127..280517c 100644
--- a/include/robot_interfaces_bolt/basic_types.hpp
+++ b/include/robot_interfaces_bolt/basic_types.hpp
@@ -9,6 +9,6 @@
 namespace robot_interfaces_bolt
-typedef Eigen::Matrix<double, 9, 1> Vector9d;
+typedef Eigen::Matrix<double, 6, 1> Vector9d;
 }  // namespace robot_interfaces_bolt

and in the package bolt:

diff --git a/include/bolt/bolt_humanoid.hpp b/include/bolt/bolt_humanoid.hpp
index 8047df8..efea513 100644
--- a/include/bolt/bolt_humanoid.hpp
+++ b/include/bolt/bolt_humanoid.hpp
@@ -20,13 +20,13 @@
 namespace Eigen
 /** @brief Eigen shortcut for vector of size 9. */
-typedef Matrix<double, 9, 1> Vector9d;
+typedef Matrix<double, 6, 1> Vector9d;
 }  // namespace Eigen
 namespace bolt
 /** @brief Control state of the robot. */

Beware that I only changed the typedefs of the Vector9d to reduce its size to 6, the name is still “9”, which can be confusing (could be renamed but I wanted to keep changes minimal).

It compiles for me but I didn’t test on the robot (I’m not in the lab at the moment), so use at your own risk :slight_smile:

1 Like

@felixwidmaier Felix, thanks again. I updated robot_properties_bolt/resources/odri_control_interface/bolt_humanoid_driver.yaml as well.

However, the connection still times out (output below), any thoughts as to next trouble shooting steps? It seems the robot response packet is larger than expected**

Apptainer> ros2 run robot_interfaces_bolt bolthumanoid_show_data ./config.yaml
Using single process time series.
[2023-12-27 16:57:00.222] [BoltHumanoidDriver] [debug] Initialize BoltHumanoid
if_name: enp0s31f6
Using Ethernet (enp0s31f6)
[2023-12-27 16:57:00.258] [BoltHumanoidDriver] [debug] Enable motors
Shutting down connection (enp0s31f6)
ERROR: Robot communication timedout.
ERROR: Robot communication timedout.
ERROR: Robot communication timedout.

The communication seems to be good with masterboard:
| lost | sent | loss ratio | histogram
Commands | 0 | 28299 | 0.00 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Sensors | 0 | 27670 | 0.00 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Shutting down connection (enp0s31f6)
average latency: 0.849137 ms
standard deviation: 0.380720 ms

There was a change in the master board code some time ago, which changed a bit the communication protocol, so boards with an older version of the firmware won’t work with the latest SDK. The fastest “fix” would be to simply roll back the master-board repository to commit 361f446 (at least for me that was the last version that still works). Alternatively updating the firmware on the master board should work as well.

@felixwidmaier that solved it.

In my above post it was not the wrapper I had to edit to run, but the YAML file in robot_properties.

Thank you very much for your help.