Understand better the Fleet Adapter Handler start_process (#235)

Posted by @TheConstructAi:

Hi,

I don’t quite get how the RobotCommandHandle.py works, specifically the sending around with json data to a URL.
In the start_process() method, in the examples of rmf_demos.

Here is the code:

def start_process(self,
                      robot_name: str,
                      process: str,
                      map_name: str):
        ''' Request the robot to begin a process. This is specific to the robot
            and the use case. For example, load/unload a cart for Deliverybot
            or begin cleaning a zone for a cleaning robot.
            Return True if the robot has accepted the request, else False'''
        
        info = None

        url = self.prefix +\
            f"/open-rmf/rmf_demos_fm/start_task?robot_name={robot_name}"
        # data fields: task, map_name, destination{}, data{}
        data = {'task': process, 'map_name': map_name}
        try:
            response = requests.post(url, timeout=self.timeout, json=data)
            response.raise_for_status()
            if self.debug:
                print(f'Response: {response.json()}')
            info = response.json()
            return response.json()['success'], info
        except HTTPError as http_err:
            print(f'HTTP error: {http_err}')
            info = http_err
        except Exception as err:
            print(f'Other error: {err}')
            info = err
        return False, info

What exactly are we doing here? Which node is in charge of receiving this json data, and why not use ROS2 communications? Who is the one in charge of effectively process that start process?

How does it connect to the is_task_queue_finished?


Edited by @TheConstructAi at 2022-09-23T11:10:05Z

Chosen answer

Answer chosen by @TheConstructAi at 2022-09-23T12:48:08Z.
Answered by @xiyuoh:

Hello!

The API calls in RobotCommandHandle are just examples of how you can communicate with your own robots with your chosen API. The methods stored inside RobotClientAPI.py are callbacks for the fleet adapter to easily interface with the robots. The json data in these callbacks are being sent to REST endpoints residing in the simulation robots’ fleet_manager.

The fleet manager’s role is to consolidate the commands sent from the fleet adapter and relay them to the fleet robots. It will be the one sending actual task commands to the robot, and return a True/False to the fleet adapter via the start_process REST endpoint to indicate whether the task has started successfully.

To illustrate the flow of events with the start_process call in rmf_demos_fleet_adapter:

  • RMF tells the fleet adapter to start a docking process by calling dock()
  • Inside the fleet adapter’s dock() callback, it uses self.api.start_process() to signal the fleet manager to start the specified task over this REST endpoint
  • The fleet manager processes the request and sends the task-related path requests by publishing a ROS2 msg to the corresponding slotcar robot
  • While the robot is docking, the fleet adapter continues to (1) monitor the robot’s position and (2) checks whether docking is completed by calling self.api.process_completed()
  • When self.api.process_completed() returns True, the fleet adapter will know that docking is completed and the robot is free to accept other navigation or docking tasks.

You may also refer to the ROS2 Book under Mobile Robot Fleets, specifically under the Fleet Adapter Template and Case Study: RMF Demos Fleet Adapter sections. For the rmf_demos_fleet_adapter implementation here, we are using REST API to interface between the fleet adapter and the fleet manager, but you are free to pick whichever API you are comfortable with when writing your own fleet manager for integration. This is also to demonstrate the fleet adapter’s flexibility to integrate with different APIs and robot vendor software.

Posted by @xiyuoh:

Hello!

The API calls in RobotCommandHandle are just examples of how you can communicate with your own robots with your chosen API. The methods stored inside RobotClientAPI.py are callbacks for the fleet adapter to easily interface with the robots. The json data in these callbacks are being sent to REST endpoints residing in the simulation robots’ fleet_manager.

The fleet manager’s role is to consolidate the commands sent from the fleet adapter and relay them to the fleet robots. It will be the one sending actual task commands to the robot, and return a True/False to the fleet adapter via the start_process REST endpoint to indicate whether the task has started successfully.

To illustrate the flow of events with the start_process call in rmf_demos_fleet_adapter:

  • RMF tells the fleet adapter to start a docking process by calling dock()
  • Inside the fleet adapter’s dock() callback, it uses self.api.start_process() to signal the fleet manager to start the specified task over this REST endpoint
  • The fleet manager processes the request and sends the task-related path requests by publishing a ROS2 msg to the corresponding slotcar robot
  • While the robot is docking, the fleet adapter continues to (1) monitor the robot’s position and (2) checks whether docking is completed by calling self.api.process_completed()
  • When self.api.process_completed() returns True, the fleet adapter will know that docking is completed and the robot is free to accept other navigation or docking tasks.

You may also refer to the ROS2 Book under Mobile Robot Fleets, specifically under the Fleet Adapter Template and Case Study: RMF Demos Fleet Adapter sections. For the rmf_demos_fleet_adapter implementation here, we are using REST API to interface between the fleet adapter and the fleet manager, but you are free to pick whichever API you are comfortable with when writing your own fleet manager for integration. This is also to demonstrate the fleet adapter’s flexibility to integrate with different APIs and robot vendor software.


This is the chosen answer.