Use services for mockup states

[ndunkelb-nasa]

This really makes more sense to be a service rather than a topic bc we just need to send it once, and it is nice to have feedback that it was successful.

The main question I have - is using the full JointState message type overkill? Could have just set it to be a float, but I figured because we are actually publishing out the whole joint state (including velocity and effort), we might as well make velocities and efforts available (even if we have no use case for them now).

To support this, I added the mockup_msgs package with the required service.

If you want to test this with CLR ws, you can see the corresponding PR in clr_ws, with updates to chonkur_l_raile, and this update.

# start clr
ros2 launch clr_mujoco_config clr_mujoco.launch.py

# start moveit
ros2 launch clr_moveit_config clr_moveit.launch.py use_sim_time:=true include_mockups_in_description:=true

# send the service request to set the bench seat to open, and you should see the position change in the moveit rviz window
ros2 service call /mockup_manager/set_joint_state mockup_msgs/srv/SetJointState "{joint_state: {name: ["bench_lid_joint"], position: [1.57]}}"

[scastro-nasa]

I went searching for whether there was a built-in message we could use, and sadly there isn't... it feels heavy to make a new interface package just for this.

And in parallel, I'm kinda ambivalent about the service vs. topic thing.

So -- what if we make this just have a single subscriber to a sensor_msgs/JointState so we retain the simplicity of publishing to a topic (and not making new messages), with the clear win of not making one separate participant per joint?

[ndunkelb-nasa]

I went searching for whether there was a built-in message we could use, and sadly there isn't... it feels heavy to make a new interface package just for this.

And in parallel, I'm kinda ambivalent about the service vs. topic thing.

So -- what if we make this just have a single subscriber to a sensor_msgs/JointState so we retain the simplicity of publishing to a topic (and not making new messages), with the clear win of not making one separate participant per joint?

That could be a decent in between, but I might want some more opinions from the 5 people who gave the 👍 in chat yesterday! @mtobia-nasa @esheetz-nasa @eholum-nasa @msavchen-nasa

[esheetz-nasa]

Seeing how it all came together, I think I'm even more convinced that the service is the right way to go 😅 I think this looks great! I don't see any problems with providing a custom interface, since the service makes more sense for what we'd like.

We've had a publisher before, so if we decide to stick with it, fine. But I'm going to be pro-service since I've never really liked just trusting that joint state update goes through.

[ndunkelb-nasa]

I went searching for whether there was a built-in message we could use, and sadly there isn't... it feels heavy to make a new interface package just for this.

And in parallel, I'm kinda ambivalent about the service vs. topic thing.

So -- what if we make this just have a single subscriber to a sensor_msgs/JointState so we retain the simplicity of publishing to a topic (and not making new messages), with the clear win of not making one separate participant per joint?

[ndunkelb-nasa]

Oops didn't mean to close this (accidentally clicked close with comment instead of cancel putting the comment), but reopened it now. @scastro-nasa , I think I might agree with Emily, I think the service is potentially useful enough to get the feedback for something like imetro_behaviors where we want to know that the collision objects and stuff that we will be working with makes sense for the rest of a demo. But can wait for others to chime in as well to get consensus after seeing the implementation.

[scastro-nasa]

I'm pretty torn:

1. Service ensures the data gets through 👍
2. Topic is more conducive to "streaming" applications, say for example someone is opening a door and wants to rapidly update the mockup joint states during the door opening motion. (and distantly / secondarily means no custom package)

[msavchen-nasa]

I am putting my vote behind service, feedback from a service is just too useful for building autonomy on top of, having custom interface is a bit of drag but since we are reusing standard messages for request/response I don't think it's too much.

@scastro-nasa
I really like your "streaming" application use case. Mockup state manager can be easily combine with mock up state estimator, whatever it might be, so having the "streaming" pattern would make the integration more efficient.

We do have examples of architectures that combine streaming with request/response patterns, joint trajectory controllers. They provide both topic for streaming via the JointTrajectory msg and request/response with FollowJointTrajectory action.
We can provide both of the interfaces, and the end use case can decide which to use.

[ndunkelb-nasa]

Yeah, I was thinking on this more, and I feel like if you have some kind of streaming implementation, maybe you would just end up including the streaming in whatever node you are doing your "perception" in? I think for the streaming case, it wouldn't really make sense to stream joint states to a mockup manager to just stream those same joint states to /joint_states. So I feel like the service meets our use cases now, and we can think about streaming stuff later in whatever architecture we might have then?

@scastro-nasa , do others' opinions and this plan sound good to you?

[mtobia-nasa]

I would understand a streaming option of we were doing direct robot to robot interaction but imo services are great for this case

[scastro-nasa]

yep, sounds good to me!

[ndunkelb-nasa]

Alright, someone wanna approve then?

[scastro-nasa]

oh wow I didn't approve it yesterday? my bad