| ROS Resources: ROS Homepage | Media and Trademarks | Documentation | ROS Index | How to Get Help | Q&A Help Site | Discussion Forum | Service Status |
Posted by @HughYZJD:
hi:
in the example office, I try to run the ‘delivery’ task. The robot stops at the pickup waypoint. What command should I send to make it run to the dropoff poin.I tried “ros2 topic pub -1 /dispenser_results rmf_dispenser_msgs/DispenserResult ‘{status: 1}’” ,but it does not work!t,thanks!,
Posted by @youliangtan:
Hi there. If you run the rmf_demos scenarios, they should all work straight out of the box. In this case, the dispensing process is not working 
Within the simulation, a TeleportDispenserPlugin will receive the /dispenser_requests and publish /dispenser_results during pickup. If this is not working, do you mind sharing some logs output for us to debug? Also, you can try to echo both dispenser_requests and ...results to check if they are being published. Thanks
Posted by @HughYZJD:
Hi:
After my test, when the robot reaches pickwp waypoint, I use command ‘ros2 topic echo / dispenser_ requests’ , the terminal will print out “request”_ guid: Delivery0 target_ guid: coke_ dispenser transporter_ Type: tinyrobot ', but the command ‘ros2 topic echo / dispenser_results’ used at another terminal has been no response after a long time and the robot does not move. According to the description of the document, the dispenser needs to send a reply message with success status. At the same time, the document also mentions that "in the future, these mechanisms will be replaced by the actual work unit or manipulator, but the underlying message exchange will remain unchanged."Therefore, is it necessary to send a response message artificially！
Thanks again！
Edited by @HughYZJD at 2022-01-17T03:11:51Z
Posted by @mxgrey:
Maybe a point for us to clarify: Have you customized your scenario somehow? Looking at the screenshot, it looks like you’ve stripped the office demo down to its bare bones. Have you also removed the dispenser object from the simulation? If so, that would explain why the demo isn’t working for you. The simulated dispenser object is responsible for issuing the acknowledgment for the delivery. The robot won’t leave until it receives a valid confirmation from the dispenser that the delivery is complete. This waiting is important for ensuring that the robot doesn’t leave before it has received the item, or even more important leave while receiving the item, would could break the physical dispenser in some cases.
If you would like to manually simulate the dispenser acknowledgment, you should endeavor to fill in all the fields for the response, not just a SUCCESS status. Without filling in the other fields, the fleet adapter doesn’t know which request was successful or when it was successful. There may be multiple dispensers in your scenario or multiple requests being made at the same time, so your result message needs to specify all of those details.
To know how to fill in those fields, you can simply copy their values from the DispenserRequest message that the robot is emitting. request_guid just copies over directly while the target_guid of the dispenser message becomes the source_guid of the response message. I can’t remember for sure if the time field matters, but I don’t think it matters beyond logging purposes.
