ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

AMatt's profile - activity

2021-02-10 01:09:19 -0500 received badge  Nice Answer (source)
2021-02-09 18:06:10 -0500 received badge  Famous Question (source)
2020-08-14 12:40:19 -0500 received badge  Notable Question (source)
2018-02-26 02:22:22 -0500 received badge  Famous Question (source)
2018-01-24 08:39:44 -0500 received badge  Necromancer (source)
2018-01-24 08:39:44 -0500 received badge  Teacher (source)
2017-06-14 17:59:12 -0500 received badge  Popular Question (source)
2017-03-09 16:03:04 -0500 received badge  Notable Question (source)
2017-03-07 16:41:51 -0500 asked a question ros_controls resource allocation

I have used ros_controls to wrap hardware that has a velocity interface and turn it into a position controller. In other words I used velocity_controllers/JointPositionController to turn my velocity interface into a position interface.

Now I would like to use my position interface and have it controlled by position_controllers/JointTrajectoryController. However, when I try to load the JointTrajectoryController with my wrapped joint included I get a resource conflict. It seems the way I have defined the resources ros_controls considers the entire joint a resource. In my case I need a resource for the velocity interface and a separate one for the position interface. I'm not sure how to define this, do I need 2 state handles with the same inputs? I.E.

    hardware_interface::JointStateHandle state_handle_joint("joint_vel", &joint_pos, &joint_vel, &joint_eff);
    jnt_state_interface.registerHandle(state_handle_joint);
    hardware_interface::JointStateHandle state_handle_joint("joint_pos", &joint_pos, &joint_vel, &joint_eff);
    jnt_state_interface.registerHandle(state_handle_joint);

Or I guess I'm asking how do I get a resource for each interface on a joint?

2017-02-28 15:16:26 -0500 answered a question Roslaunch XML boolean operators

Adding this because I couldn't easily find it anywhere:

    <arg name="foo" default="false" />
    <group if="$(arg foo)">
        <!--do some stuff-->
    </group>
    <group unless="$(arg foo)">
        <!--do some different stuff-->
    </group>
2017-02-22 11:19:31 -0500 received badge  Notable Question (source)
2017-02-22 08:48:42 -0500 commented question Is there any command in ROS for knowing the system dependencies of the ROS packages ?

I thought this is what rosdep was for

2017-02-22 08:05:22 -0500 received badge  Editor (source)
2017-02-22 00:55:02 -0500 received badge  Popular Question (source)
2017-02-21 15:10:59 -0500 asked a question Split joint trajectory controller

I have an arm that uses dynamixel servo motors. I use the dynamixel motor stack along with Moveit! to operate it. The dynamixel stack is structured very similarly to ros_control, however, it is not directly compatible with it. It comes with it's own joint_trajectory_action_controller that interfaces with Moveit!. It looks like the author rewrote the joint_trajectory_action_controller so that he could broadcast positions/velocities of mutliple joints on the bus simultaneously and improve performance.

I have another motor that I want to put into the same kinematic chain as the arm (prismatic slider for the arm). I wrote the interface to it, and it is a standard ros_control hardware_interface. So I am faced with the problem of how to handle the trajectory action interface from Moveit!

Should I??

  1. Include each dynamixel joint in my hardware_interface, sacrificing the performance improvements made by @arebgun. Then I would use the standard joint_trajectory_action_controller.
  2. Somehow nest action servers so that the top one takes the request from !Moveit and separates it into dynamixel and "other" and then passes it own.
  3. Or is there some simple answer I am missing?

I am mostly asking from a typical architecture of ros_control point of view, as I assume I am not the first person to have this problem.

--EDIT in response to @DaveColeman--

  1. I guess that was my real question, has anyone thought of a clever way to do this yet. In the dynamixel version of joint_trajectory_action_controller he uses the low level function set_multi_position_and_speed. I guess I could write a dynamixel "multi joint controller" that looks similar but takes a topic of vel/pos commands instead of implementing an action server. Then I could wrap that node with my hardware interface and run it from the ros_controls joint_trajectory_action_controller.
  2. Did you mean one controller_manager? I have noticed this feature, but I'm not sure I understand it well enough to leverage it for this particular situation. I definitely see the advantage of having multiple hw_interfaces as I would prefer one for arm one for base etc. However, my problem is how to wrap the dynamixel stack without losing pos/vel (@arebgun only exposes position in his nodes but one could write a node exposing both) or the ability to broadcast across the 422 bus to multiple motors/joints.

What @arebgun did is quite good, all the bus i/o interface is controlled by one class and all the controllers have shared pointers to it. The dynamixel controller_manager gets status/diagnostics on all the connected motors. It seems like it will be hard to not sacrifice some performance if this was re-written to work on a controller by controller basis in ros_control. But likely I don't understand the the ros_control architecture well enough to determine that, suffice to say I'm not sure how to do it.

2016-11-23 17:53:52 -0500 received badge  Popular Question (source)
2016-08-31 20:57:33 -0500 asked a question Octomap "deteriorates" with each point cloud added

I am using a lidar sensor with laser_assembler to generate Point Clouds in the /map frame. The assembler gathers scans while the robot moves along a chain, so the transform to map is pretty precise. Now I am wanting to build octomap_server based on these Point Clouds.

This starts out fine, I dump the point cloud using something like periodic_snapshotter and bring it into octomap_server as the robot travels down the track. However, each point cloud that gets added changes the ones that were added previously(occupied voxels disappear). It is as if the octomap is thinking that each point cloud is applied to the entire map and is counting all the previous area as misses. Although, even if I set sensor_model/[hit|miss] to 1.0|0 this does not change my result.

So:

  1. Am I right to believe by publishing small sections of map point cloud to octomap_server it is impacting other portions of the map(If so, how to change this behavior)?
  2. Is assembling the point clouds in the /map frame the correct way to do this?
  3. Or what else am I missing? I expect to be able to add point clouds in a way that only impacts the section of the map that has data in that particular point cloud. I cannot seem to achieve this. I can provide code/images/better descriptions if helpful.
2016-08-23 09:12:23 -0500 received badge  Enthusiast
2016-08-15 12:37:12 -0500 commented answer Which IDE(s) do ROS developers use?

add 'set(CMAKE_INSTALL_PREFIX "${CMAKE_SOURCE_DIR}/../install") set(CATKIN_DEVEL_PREFIX "${CMAKE_SOURCE_DIR}/../devel")' to the top level cmake and it works for me.

2016-08-15 12:37:11 -0500 asked a question Clion output directory

Anyone using Clion for ROS development? It seems like a good fit due to the CMake compatibility. I have had good success getting Clion to find, build, and autocomplete everything in my catkin workspace. However, I can't seem to make the outputs of the compile process go to the /devel directory like it is suppose to. I have tried set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "../devel") in the top level cmake file, but it doesn't seem to change anything.

I would welcome advice from anyone who uses Clion for ROS as to there method from beginning to end. But my main problem is how to populate the devel directory as ROS expects?

To get this out of the way, EMACS is great and I love it, please don't tell me to use EMACS.

2016-08-15 12:01:40 -0500 received badge  Supporter (source)