search

open-rmf / free_fleet

A free fleet management system.
Apache License 2.0
157 stars 65 forks source link

ros1 robot without multi-level support #73

Closed txlei closed 3 years ago

txlei commented 3 years ago

Hi, my robot does not have any mutli-level management. Hence, its location does not have level_name parameter. How do I overcome this by setting the level_name to a default level in my free fleet client? Tried to indicate in my launch file for free fleet client node using 

<param name="level_name" type="string" value="L7"/>

Currently experiencing error from fleet_adapter:

Robot named [] belonging to fleet [] is lost because we cannot figure out what floor it is on. Please publish the robot's current floor name in the level_name field of its RobotState.
aaronchongth commented 3 years ago

Hello @txlei!

Thanks for putting up this issue. Unfortunately I have not been able to reproduce this error. As a sanity check, could you verify that the level_name field in the robot states is being populated with L7?

After sourcing your ROS 2 workspace, you can check by using ros2 topic echo /fleet_states

txlei commented 3 years ago

sorry. im referring to a physical robot on ros1 navigation stack for the ff client. The robot itself does not track which level it is on since each map is for one specific level (not labelled too). Over in RMF side, the level_name field is an empty string, which is expected.

What do I have to do to publish the level_name value? Is it on the rmf side or ff client side? I am thinking it should be the rmf side since the robot's own map is not being used at all since all navigation is done on rmf traffic using traffic map that tracks the level.

aaronchongth commented 3 years ago

sorry. im referring to a physical robot on ros1 navigation stack for the ff client. The robot itself does not track which level it is on since each map is for one specific level (not labelled too). Over in RMF side, the level_name field is an empty string, which is expected.

Sorry, I am having some trouble understanding this statement. The level name parameter will be used to populate the client's state location, which in turn should let RMF know which level it is on, and which navigation graph to use.

What do I have to do to publish the level_name value? Is it on the rmf side or ff client side? I am thinking it should be the rmf side since the robot's own map is not being used at all since all navigation is done on rmf traffic using traffic map that tracks the level.

Could you check the topic /fleet_states if the level name is already populated?

txlei commented 3 years ago

the level name is not populated in the fleet_states topic. Where should the level_name be populated?

The ff client aka ros1 robot does not have the capability to manage multi-level deployment.

aaronchongth commented 3 years ago

The level name should be populated statically in the launch file parameters for the client, like so, https://github.com/osrf/free_fleet/blob/master/ff_examples_ros1/launch/multi_turtlebot3_ff.launch#L63-L74

Could you share the snippet you have for launching the client? I have not been able to recreate the issue. Thanks!

txlei commented 3 years ago

Hi @aaronchongth, I've indicated the level_name param in the launch file as mentioned in my first post. 

<node name="free_fleet_client_node" pkg="free_fleet_client_ros1" type="free_fleet_client_ros1" output="screen">
    <param name="fleet_name" type="string" value="gobot"/>
    <param name="robot_name" type="string" value="gobot1"/>
    <param name="level_name" type="string" value="L7"/>
    <param name="dds_domain" type="int" value="42"/>
    <param name="max_dist_to_first_waypoint" type="double" value="10.0"/>
</node>
aaronchongth commented 3 years ago

Hello @txlei! Could you check that the server has the fleet_name field populated, like so, https://github.com/osrf/free_fleet/blob/master/ff_examples_ros2/launch/turtlebot3_world_ff.launch.xml#L10?

From your initial issue comment it looks like the fleet adapter is not registering a fleet name too, could you check that it is populated properly like so, https://github.com/osrf/rmf_demos/blob/master/demos/launch/office.launch.xml#L25?

txlei commented 3 years ago

yeap, fleet_name is populated. in the first post, I've removed the name of the fleet in my error message. sorry if that caused confusion. The server is able to successfully register the client.

On the side note, if the level_name is populated on client side via launch, what happens when the fleet on rmf traffic map changed to another level? Would the fleet_states reflect the same level_name value or would it continue to populated the initial level_name indicated in the ff client node launch?

aaronchongth commented 3 years ago

yeap, fleet_name is populated. in the first post, I've removed the name of the fleet in my error message. sorry if that caused confusion. The server is able to successfully register the client.

So does that mean the missing robot name has also been redacted?

On the side note, if the level_name is populated on client side via launch, what happens when the fleet on rmf traffic map changed to another level? Would the fleet_states reflect the same level_name value or would it continue to populated the initial level_name indicated in the ff client node launch?

It will continue with the statically configured level from the client, hence you will need to ensure that the client's level name is consistent.

I still have not been able to recreate this scenario, let me know if you come across any additional information, especially if it is related to the level_name in rmf_traffic map.

txlei commented 3 years ago

So does that mean the missing robot name has also been redacted?

Nope. The robot name is not missing. The error is not because the robot name is missing as the server is able to successfully register the client. Issue on level_name is not resolved yet.

It will continue with the statically configured level from the client, hence you will need to ensure that the client's level name is consistent.

so lets say a delivery task that involves two levels is sent in rmf, when the robot comes out of the lift and switches level in the traffic map, I need to also configure the level_name in my ros1 free fleet client environment? What happens if the level_name value populated in fleet_states is incorrect (out of sync with traffic map level)?

aaronchongth commented 3 years ago

so lets say a delivery task that involves two levels is sent in rmf, when the robot comes out of the lift and switches level in the traffic map, I need to also configure the level_name in my ros1 free fleet client environment?

Since the current free fleet client does not support navigation on multiple levels, the navigation graph for this fleet should not contain nodes going through elevators to other levels. The delivery task in this scenario will fail.

The free fleet client at the moment only supports single level operation, of which the name of the level must be statically configured at launch. Changing level names during runtime is currently not supported.

What happens if the level_name value populated in fleet_states is incorrect (out of sync with traffic map level)?

If the robot state's level name is our of sync with the expected level name within the fleet adapter, the fleet adapter will assume that the robot is lost, hence the error message you received in the first comment.

simk0024 commented 3 years ago

Hi @aaronchongth Does free fleet have door_request and lift_request integrated?

aaronchongth commented 3 years ago

Hello @simk0024! No it does not, free_fleet tries to be a fleet manager only, while infrastructure integration is done either by the user, or by a system like RMF

simk0024 commented 3 years ago

Hi @aaronchongth, I am trying to integrate free_fleet_client on a ROS1 robot, and issuing a robot_path_request from RMF. I am wondering who should be the one command door to open. RMF, free_fleet_client or free_fleet_server? So far, I don't see DoorRequest msg implemented on free_fleet. Should I assume RMF will automatically command door to open when robot approaching?

aaronchongth commented 3 years ago

Yes, this occurs if a door is within a lane connecting two waypoints in the navigation graph. This is handled by the fleet adapters on the side of RMF.