Description

When I try to send a command to the simulated robot I get:

[err ][rt_main] [J1_A] safety limit violation detected in delta tx (0.0  --->  0.009999999776482582): d(pos_ref)/dt exceeded: |9.999999| > 3.900000; 
[warn][rt_main] [J1_A] safety triggered: freezing qref and setting vref = 0, tauref = 0
[warn][rt_main] [J2_A] safety triggered: freezing qref and setting vref = 0, tauref = 0
[warn][rt_main] [J3_A] safety triggered: freezing qref and setting vref = 0, tauref = 0
[warn][rt_main] [J4_A] safety triggered: freezing qref and setting vref = 0, tauref = 0
[warn][rt_main] [J5_A] safety triggered: freezing qref and setting vref = 0, tauref = 0
[warn][rt_main] [J6_A] safety triggered: freezing qref and setting vref = 0, tauref = 0

How to reproduce the issue

1. Follow instructions reported in https://github.com/ADVRHumanoids/modularbots_fraunhofer#running-the-simulation
2. Start a gui using the command xbot2-gui
3. Enable ros_ctrl plugin
4. Enabl chain_A (joint panel of the gui)
5. Set the reference value for the joint J1_A to a small value (i.e. 0.01)
6. No motion will be performed and the error reported above will be printed

The same error is got if the motion is commanded using the Continuous control offered by the RViz interface spawned by mon launch ModularBot_6DOF ModularBot_cartesio_IK.launch

Note: to use the command mon launch ModularBot_6DOF ModularBot_cartesio_IK.launch in your docker you will need to install manually some missing dependencies

@alaurenzi have you any idea about how to solve this issue?

Hi,

I am encountering a strange behavior in the execution time of a function if the thread in which the function is run is scheduled using fifo.

Setup description

• A built library (let's call it my_library) in which i have a function defined (let's call it my_test_function)
• A plugin (let's call it my_plugin) that is including my_library and runs the function my_test_function in the update loop (the thread used by this plugin is rt_main)
• The execution time of the function is measured using:

  auto begin = std::chrono::high_resolution_clock::now();
  my_test_function();
  std::cout << "execution time: "
           << std::chrono::duration_cast<std::chrono::duration<double, std::micro>>(
                std::chrono::high_resolution_clock::now() - begin)
                .count()
           << " micros \n";

Problem description

If the scheduling type of the thread in which the plugins runs is set to fifo the execution time result ~100 micros.
If instead the scheduling type is set to other the execution time result in ~5 micros (same execution time that i get on other PCs)

Note: no rebuild is performed between the change of scheduling type so the difference of behavior must be introduced by this setting

@EdoardoRomiti @alaurenzi have you ever encountered a similar problem? have you any idea how to solve this?

@EdoardoRomiti, I was wondering:

• It is possible to set a custom (static) Tool during the RobotBuilder process?
• If not, how can i inform the controller that an additional weight is present?

Thanks

Description

I am trying to replicate this Control plugin example. The plugin seems to be correctly loaded and executed (I started xbot2-core in verbose mode and i added a print of the q_ref in the run() method and I can see it change) but unfortunately the robot does not move.

@alaurenzi can you help me in getting this plugin work?

Suppose that I am controlling the robot in effort mode (with zero stiffness and damping), if somebody stops the xbot2-core terminal using CTRL+C the robot remains in effort control mode and the last commanded effort is kept as reference.

Instead, I would like to have the chance to switch the control mode to position (restoring stiffness and damping values with a procedure similar to the one proposed in stopping method of your gcomp_example). I have already tried to use the on_abort method without success. Can you please provide an hint on how to achieve this "graceful abort" in case of effort control mode?

Hey all together,

I was playing around with the modularbots library today to create a "TUM-readable" module library when I realized the geometries for the joints are "offset" (see screenshot), meaning that the "lower surface" of their bodies (e.g., the cylinder-shaped body of the straight joint) is not passing through the origin (see screenshot).

I wanted to ask whether that's intentional and, when connecting multiple joints from this robot, whether the reference coordinate system for a connection would be the body origin (<0 0 0>) or the slightly offset geometry surface.

By running the command:

. docker/run.sh 

The following error is reported:

[sudo] password for user: user is not in the sudoers file.  This incident will be reported.
Could neither symlink nor copy file "/opt/ros/noetic/share/catkin/cmake/toplevel.cmake" to "/home/user/catkin_ws/src/CMakeLists.txt":
- [Errno 13] Permission denied: '/opt/ros/noetic/share/catkin/cmake/toplevel.cmake' -> '/home/user/catkin_ws/src/CMakeLists.txt'
- [Errno 13] Permission denied: '/home/user/catkin_ws/src/CMakeLists.txt'Base path: /home/user/catkin_ws
Source space: /home/user/catkin_ws/src
Build space: /home/user/catkin_ws/build
[Errno 13] Permission denied: '/home/user/catkin_ws/build'
./setup_catkin_ws.sh: line 10: devel/setup.bash: No such file or directory
bash: /home/user/catkin_ws/devel/setup.bash: No such file or directory

So when i try to run mon launch ModularBot_6DOF ModularBot_gazebo.launch (as described in the simulation readme section) I get:

[rospack] Error: package 'ModularBot_6DOF' not found
Could not find path of package 'ModularBot_6DOF'

@alaurenzi this issue is blocking me on running the robot in Gazebo simulation environment.