Errors with "demos" codes

[PaulRouanet]

Hi @MaximilienNaveau !

I am in internship at LAAS with Olivier Stasse. I have build a Bolt, and now I am trying to apply those codes on the robot. I am currently trying to use the “demos” codes. I forked the repo (https://github.com/PaulRouanet/bolt.git) in order to create “_test” versions that I am modifying. My main issue is that when I am running “bolt_demo_calibration” or “bolt_demo_sensor_reading”, I always have the same message : “ERROR: The slider box is not responding correctly, 10 iteration are missing.”

I have seen with Olivier, he think that communications between Masterboard and Micro-Drivers are the reason of this error. Firstly, we have though about message printing (on sensor_reading), but when we comment the lines, nothing change. Then, he though about real time priorities problem. That’s why he modified “thread” codes in real_time_tools (fork : https://github.com/PaulRouanet/real_time_tools.git). He give the first priority to the reading (-80).

Do you have an idea on how to solve this error message ?

And then, is there the “bolt_demo_calibration” code that allow us to calibrate our Bolt ? And finally, which code allow us to make walk Bolt (is it bolt_demo_pd ?) ?

Best, Paul

[PaulRouanet]

I have discovered that a "slider box" may be a hardware box of slider. And of course I have not got it, so it can't responding correctly ... Do you know the role of this box ? Is it used to move some actuators ? And how can I have one if I need it ?

[MaximilienNaveau]

Dear Paul Rouanet, I am sorry I did not see your message earlier.

The slider box is this box an arduino plugged to 4 linear potentiometers and a e-stop button. The connection to the computer is done via serial port (usb): https://github.com/open-dynamic-robot-initiative/bolt/blob/master/src/bolt.cpp#L80 The serial_reader_ object is responsible for the communication. It allows us to have a soft e-stop during the experiment. You can simply remove the object from the code if you do not have the box itself. Sorry this part of the hardware do not seem to be documented yet... I will ask if this can be fixed.

Otherwise you should not have to increase the priority of you executable at all, the code does it for you. You might just have to run it with sudo though in order to properly connect to the master-board.

Let me know if you succeed.

[jviereck]

Hi Paul Rouanet,

Here is some documentation about the wiring of the e-stop. It's important to use a pull-up line via a resistor.

Note that these days we use the Arduino Leonardo.

Let me know if you have any further questions.

Best, Julian

[MaximilienNaveau]

And then, is there the “bolt_demo_calibration” code that allow us to calibrate our Bolt ? And finally, which code allow us to make walk Bolt (is it bolt_demo_pd ?) ?

For these question in order:

• The demos in general are simple controller that demonstrate the capabilities of the API not the robot itself.
• The bolt_demo_calibration simply shows you what happens when you calibrate the robot.
• In order to make Bolt walk you need a more advance controller which is not the scope of this package. You need:
  • An estimation software providing you with the centroidal dynamics and other proprioceptive informations.
  • A reactive planner that will plan for centroidal dyanmics and foot step generation.
  • A whole body controller in order to track the above trajectory.
  • etc. We do have a solution but it is ongoing work and not very well documented/packaged.

[PaulRouanet]

Ok thanks to both of you ! I removed everything related to the slider box in bolt.cpp and I can do some tests. LAAS doesn't plan to make this box for the moment. And for the last answer, ok, I am going to check that

[jviereck]

Maybe this page will become handy for you as well: https://github.com/machines-in-motion/machines-in-motion.github.io/wiki/bolt_hardware

[olivier-stasse]

Dear Paul Rouanet, I am sorry I did not see your message earlier.

The slider box is this box an arduino plugged to 4 linear potentiometers and a e-stop button. The connection to the computer is done via serial port (usb): https://github.com/open-dynamic-robot-initiative/bolt/blob/master/src/bolt.cpp#L80 The serial_reader_ object is responsible for the communication. It allows us to have a soft e-stop during the experiment. You can simply remove the object from the code if you do not have the box itself. Sorry this part of the hardware do not seem to be documented yet... I will ask if this can be fixed.

Otherwise you should not have to increase the priority of you executable at all, the code does it for you. You might just have to run it with sudo though in order to properly connect to the master-board.

Let me know if you succeed.

Dear @MaximilienNaveau and @jviereck thanks for the quick answer. As for the thread, checking at the code of real_time_tools, I see the priority set for the RT_PREEMPT patch for linux and for xenomai for nothing for the usual Linux Kernel. But even in this later case, it is possible to change the scheduler and affect real-time priority. They are less real-time guarantees (like priority inheritance and priority handling of interruption) but it is still better.