Ask Your Question

Daniel L's profile - activity

2020-12-03 06:37:04 -0500 received badge  Taxonomist
2017-08-17 08:48:57 -0500 received badge  Nice Question (source)
2016-12-08 05:35:19 -0500 received badge  Famous Question (source)
2016-05-28 02:29:26 -0500 received badge  Famous Question (source)
2016-05-28 02:29:26 -0500 received badge  Notable Question (source)
2016-04-11 07:12:42 -0500 received badge  Notable Question (source)
2015-12-10 02:58:53 -0500 received badge  Popular Question (source)
2015-11-11 14:47:31 -0500 received badge  Popular Question (source)
2015-11-09 21:11:37 -0500 asked a question How to set verbosity level for /gazebo node?

I am trying to display ROS_DEBUG_STREAM_NAMED messages (in terminal and rqt_console) of a class I wrote which is indirectly used by the /gazebo node. This class is part of a ros_control controller I wrote. I am able to see INFO, WARN, and ERROR, but not DEBUG.

I have tried several things that did not work. I tried adding the line log4j.logger.ros.gazebo_ros=DEBUG in ROSCONSOLE_CONFIG_FILE. It shows some debug messages, but not the ones from my class. I also tried adding the line log4j.logger.ros.gazebo_ros.safety_control_connected_controllers=DEBUG to the same file (the appended string is the name of the package/header of my class, which I am also using as the first argument in ROS_DEBUG_STREAM_NAMED). One thing that I observed is that in rqt_console, /gazebo has no loggers.

So what do I need to do to see my debug messages?

2015-10-30 13:51:14 -0500 asked a question How to safely use actionlib's goal handles in a real-time concurrent system?

We have been developing a new control system for our robots based on ros_control, and we would like to ask for advice on the proper way to use actionlib's goal handles in a real-time and thread-safe way. I am aware of realtime_tools::RealtimeServerGoalHandle<Action> (had a look at JointTrajectoryController too), but since we also need to cancel and reject goals and send feedback, it might not be sufficient.

Our control system must interact with the existing planning system through an actionlib interface. Goals must be processed in a specific way expected by the planning system. The solution we have in mind involves 2 non-RT threads and 1 RT-thread. One of the non-RT threads serves the goal and cancel callbacks. These callbacks fill in a data structure with a shared pointer to the goal handle, a representation of the goal which can be loaded into the underlying control system, and the request type (new goal, repair, cancel). These structures are passed to the RT thread where they get processed and the control system is driven accordingly. If it is required to accept/reject/cancel/abort/feedback a goal, the pointer to the goal handle is stored in a different data structure that is passed to the second non-RT thread. This thread calls the corresponding functions in the goal handle.

One of the problems here is that a goal handle could be accessed concurrently in the RT thread and second non-RT thread. For example, the non-RT thread could call publishFeedback() on the goal handle while the RT thread accesses the goal inside the handle to verify if a repair is possible. Is this thread-safe if the RT thread only reads from the actual goal? Could something in the action client code make it not safe?

The other problem is that the RT thread needs to check if the cancel request message matches the current goal, and this might not be real-time safe. The == operator of actionlib::ServerGoalHandle<ActionSpec> involves getting the goal ID, which involves mutexes. Is using the == operator real-time safe?

These are questions specific to the approach we have taken, but we are also interested in knowing what other people have done to deal with actionlib goals in real-time control systems.

2015-08-19 01:29:39 -0500 received badge  Scholar (source)
2015-05-29 00:23:03 -0500 received badge  Famous Question (source)
2015-05-20 11:27:14 -0500 received badge  Famous Question (source)
2015-03-05 13:04:23 -0500 commented answer How to aggregate command hardware interfaces in ros_control?

Would there be other parts of the code where the hardware_interface type string is used?

2015-03-05 13:03:08 -0500 commented answer How to aggregate command hardware interfaces in ros_control?

Thanks for replying. I went through the code in ControllerManager::ControllerManager and checkForConflict(...), and it seems that this would work. The first only uses the hardware_interface type as a string for reporting purposes. The second uses ControllerInfo::resources.

2015-03-05 12:53:56 -0500 received badge  Notable Question (source)
2015-03-03 09:55:20 -0500 received badge  Popular Question (source)
2015-03-02 16:09:22 -0500 asked a question How to aggregate command hardware interfaces in ros_control?

I would like to know what workarounds can be used to allow a controller to command more than one hardware interface in ros_control. The hardware interfaces could be homogeneous or heterogeneous (e.g. VelocityJointInterface + PositionJointInterface + MyCustomInterface). I am looking for a solution that does not involve creating a new hardware interface with gigantic handles. There is a workaround here for the case where only one hardware interface sends commands, but it might not work for our particular case.

One of our applications for this is a mobile manipulator where the arm has velocity and position hardware interfaces, and the base has a velocity hardware interface. We would like to control both the arm and the base within the same controller.

To get familiar with ros_control, we developed the control architecture for the arm first. The RobotHW specialization has a VelocityJointInterface and a PosVelJointInterface for visual servoing/joystick and trajectory tracking control modes, respectively. The design of the architecture is such that several components (e.g. arm + base) can be aggregated in a single RobotHW specialization. Now we are facing the difficulty of aggregating hardware interfaces at the controller level. So I would like to know what other people have done on similar scenarios.

2015-01-28 11:25:25 -0500 received badge  Notable Question (source)
2015-01-27 19:54:28 -0500 received badge  Famous Question (source)
2015-01-25 23:48:10 -0500 received badge  Enthusiast
2015-01-24 16:52:26 -0500 commented question Gazebo Joint's GetForce() returns zero when used in conjunction with SetMaxForce() and SetVelocity()

I think so, since I can see they are correctly enforced. There is a similar question in Gazebo's forum. The strange thing is that after I send some commands through the panes, I can read forces afterwards.

2015-01-24 16:44:18 -0500 commented answer Proper use of ros_control's RealtimeBuffer

Thank you for taking the time to answer. I think I was not clear with my first question. In JointPositionController, command_struct_, which is not the RealtimeBuffer, is used in both threads: ROS message handling (setCommand) and the control loop (starting and update). Is this ok?

2015-01-24 16:36:20 -0500 received badge  Popular Question (source)
2015-01-19 14:44:22 -0500 asked a question Proper use of ros_control's RealtimeBuffer

I am new to real-time programming, and I am trying to learn how to properly use realtime_tools::RealtimeBuffer in my ros_control controller by looking at source code from related packages. After looking at the source code of RealtimeBuffer, effort_controllers::JointPositionController, and forward_command_controller::ForwardJointGroupCommandController, I am still confused about three things.

First, JointPositionController uses the buffer to share command data between the RT and non-RT threads, but command_struct_, the member variable used to set the buffer, is also accessed by both threads. Is it safe to access command_struct_ in this way? If it is safe, why is this the case?

Second, in ForwardJointGroupCommandController, why is RealtimeBuffer not used at all? My controller has several joints and I was thinking on using RealtimeBuffer to protect a vector. In order to pre-allocate the buffer internally, I was thinking on passing a vector with dummy values to RealtimeBuffer::initRT() in the init() method of the controller (I don't know the size of the vector until this point). Then call initRT() again in starting() with appropriate values.

Third, why doesn't RealtimeBuffer::initRT() check the lock of the mutex? Under the context of the JointPositionController , I can imagine messages published to the command topic even before the controller is started. Would this be safe?

Source code: RealtimeBuffer, JointPositionController, ForwardJointGroupCommandController.

2015-01-19 13:37:54 -0500 commented question Gazebo Joint's GetForce() returns zero when used in conjunction with SetMaxForce() and SetVelocity()

Thanks for the heads-up. I'll post there too.

2015-01-19 05:50:22 -0500 received badge  Notable Question (source)
2015-01-16 09:41:21 -0500 received badge  Popular Question (source)
2015-01-15 12:30:26 -0500 received badge  Student (source)
2015-01-15 10:10:21 -0500 asked a question Gazebo Joint's GetForce() returns zero when used in conjunction with SetMaxForce() and SetVelocity()

I am writing my own robot sim interface (to replace the DefaultRobotSim plugin for our robot), and gazebo::physics::Joint::GetForce() returns zero when velocities are sent directly to the simulator through gazebo::physics::Joint::SetVelocity() + gazebo::physics::Joint::SetMaxForce(). The function starts to return values different from zero for a particular joint when a command has been issued to it from Gazebo GUI's Joints pane, where force, velocity, or position can be set. But until the pane is not used, GetForce() returns zero even if a controller from ros_control is active and the robot is moving. Is there a way to get non-zero force values without having to use the Joints pane first?

The functions gazebo::physics::Joint::GetAngle() and gazebo::physics::Joint::GetVelocity() return non-zero values from the beginning as expected.

To make sure the problem was not related with my robot sim interface, I tested using DefaultRobotSim with standard ros_control controllers. I got the same results. The problem does not happen if gazebo::physics::Joint::SetForce() is used instead of SetVelocity(), and SetMaxForce() is not called. I found a similar question in ROS Answers, but in that case, GetForce() seemed to return zero always because the function was not implemented yet.

ROS Indigo Gazebo version: 2.2.3 gazebo_ros_control: 2.4.6