We are in the process of designing a mobile cobot (AMRs with a cobot) and found Isaac Mission technology to be suitable for what we want to accomplish, i.e., send a mission to the AMR to traverse a path and achieve a manipulation operation too. There would be multiple waypoints within the same mission.
Having gone through the Isaac Mission documentation (for Dispatch service and client), there are 2 key object types - Route and Action
We want to understand the following
On receiving the “route” order from the dispatch server, the client (also a ROS 2 node) is supposed to invoke the Nav2 node of the AMR. This is still possible even if the AMR is from a different vendor, let’s say Hik-Robotics. Is this right?
The “action” call/order from the dispatch seems to carry only the action name and some parameters. The actual logic of the action would be something that the client should resolve and instruct the AMR? Is there an actual example of passing a valid action to the client? as in asking the AMR to lift a pallet? Excerpt from the documentation
|action|Optional[object]|name(string): The name of the action to trigger on the robot params(json): An arbitrary, action-specific JSON payload to send as parameters to the action|Performs some generic, named action on the robot.|
| — | — |
I
Yes, the client node will trigger the Nav2 node regardless of the vendor. The client node calls the navigate_through_poses action provided by Nav2.
Mission Client node would handle actions by calling action servers. Users need to implement the corresponding action server and modify the function Vda5050ActionHandler to resolve the parameters. Currently, Mission Client supports several actions, such as dock_robot and undock_robot. You can use these as examples and add your own action.
Hello @Raffaello
Thank you for getting me the details. The timing was great. I reverse-engineered the code last night and found the referenced code sections. I will go ahead and implement action servers for both Nav2 and Actions.
Just so that the others in the community also benefit from this small piece of additional information,
The code repo has a couple of dummy server implementations for 1) Nav2 server - isaac_ros_vda5050_nav2_client/test/test_nodes/nav2_simple_server.py 2) Dummy Action Server - isaac_ros_vda5050_nav2_client/test/test_nodes/dummy_action_server.py
I will take this opportunity to shoot one more question here. I see that the tutorials and the videos suggest the use of /robot POST method to create robot objects. I am unable to connect the dots as to how the object created in the database would correspond to the real AMR?
The attached image is from the dispatch server code (packages/controllers/mission/server.py) that checks if the AMR is online. How do we actually communicate with the robot to check the presence of a heartbeat?
In the basic IoT/Connected Systems world, the connected systems are expected to send heartbeat as telemetry data every few seconds. How does the concept work here though?
The mission client publishes robot state periodically on some MQTT topic. The MQTT topic name is determined by your parameters when launching the client. It is uagv/v2/RobotCompany/<serial_number>/state by default.
Mission dispatch will process messages on that topic after calling /robot POST to create a robot with the same name (serial_number) in the database.
If no state message is published on that topic for a while, the robot is considered offline. However, the robot remains in the database. When the mission client is back online and publishes the robot state, mission dispatch will receive the heartbeat and mark the robot as online again.
