Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is the current code applicable to AMR mode? Or is it only applicable to AGV mode? #410

Open
daichuihua opened this issue Dec 23, 2021 · 5 comments

Comments

@daichuihua
Copy link

Is the current code applicable to AMR mode? Or is it only applicable to AGV mode? Can "traffic-editor" edit the "theta" of the robot's [vertex] and the origin of the map? If yes, how?
In traffic-editor, i can modify the Vertex's X and Y, but for AMR ,i need to give the AMR next goal(X,Y,theta)

I need your help ! please ~ THX very much.

@mxgrey
Copy link
Collaborator

mxgrey commented Dec 31, 2021

Fundamentally a waypoint in a navigation graph is just a 2D location. I don't think it generally makes sense to specify a single orientation for a waypoint because that would imply the robot must be facing a specific direction in order to qualify as being "on" that waypoint. I don't think that's ever a helpful requirement to impose.

Can you elaborate more on when and why you want orientations to be specified? The path following commands that are sent to the individual robots (whether they're AGVs or AMRs) from the fleet adapter do specify recommended orientations for the robot. Is there a different level where you want to be able to specify orientations, e.g. "To plug into its charger, I need the AMR to approach its charger waypoint with a certain orientation"?

@daichuihua
Copy link
Author

Fundamentally a waypoint in a navigation graph is just a 2D location. I don't think it generally makes sense to specify a single orientation for a waypoint because that would imply the robot must be facing a specific direction in order to qualify as being "on" that waypoint. I don't think that's ever a helpful requirement to impose.

Can you elaborate more on when and why you want orientations to be specified? The path following commands that are sent to the individual robots (whether they're AGVs or AMRs) from the fleet adapter do specify recommended orientations for the robot. Is there a different level where you want to be able to specify orientations, e.g. "To plug into its charger, I need the AMR to approach its charger waypoint with a certain orientation"?

yes, I need the AMR to approach its charger waypoint with a certain orientation & i need AMR to approach its take_photo_waypoint with a certain orientation & i need AMR to approach its workcell_connect_waypoint with a certain orientation ... and so on

@mxgrey
Copy link
Collaborator

mxgrey commented Jan 24, 2022

In that case there are already some methods you can use for this through the traffic editor.

To tell the traffic management system that the robot must always face a certain orientation when going down a certain lane, you can use the orientation: forward or orientation: backward lane property, as shown in the screen shots below. Notice the direction of the box+line that gets rendered over the lane when these properties are set.

Forward
forward

Backward
backward

This constraint was made with differential drive robots in mind, so it currently only supports forward and backward.

Alternatively, if you need a robot to arrive at a certain point and the face a certain direction once it arrives, then you could use the "docking" pipeline. Select the waypoint on the nav graph in traffic editor and give some name to its dock name property:

  1. Select the waypoint, click Add property... and select dock_name from the drop down.
    select_dock_name

  2. Type the desired name into the dock_name field.
    set_dock_name

Now you can program your fleet adapter to respond to the docking command however you'd like. You can command the robot to go to the waypoint and face a certain direction, then trigger some action to happen (e.g. "take a picture") before triggering the "docking finished" callback. The details for how exactly to do this will depend on how you're integrating your fleet adapter.

In the upcoming release there will be simpler ways to do this, e.g. you can create a custom task that commands the robot to go to a waypoint and then face a certain direction. But the orientation constraint or docking approaches are already available and may be suitable.

@daichuihua
Copy link
Author

In that case there are already some methods you can use for this through the traffic editor.

To tell the traffic management system that the robot must always face a certain orientation when going down a certain lane, you can use the orientation: forward or orientation: backward lane property, as shown in the screen shots below. Notice the direction of the box+line that gets rendered over the lane when these properties are set.

Forward forward

Backward backward

This constraint was made with differential drive robots in mind, so it currently only supports forward and backward.

Alternatively, if you need a robot to arrive at a certain point and the face a certain direction once it arrives, then you could use the "docking" pipeline. Select the waypoint on the nav graph in traffic editor and give some name to its dock name property:

1. Select the waypoint, click `Add property...` and select `dock_name` from the drop down.
   ![select_dock_name](https://user-images.githubusercontent.com/1307217/150731656-6fa3c04e-2259-4892-8267-43bba2c31c9a.png)

2. Type the desired name into the `dock_name` field.
   ![set_dock_name](https://user-images.githubusercontent.com/1307217/150731743-2912f0d9-86e0-4475-81ea-8054f67a292c.png)

Now you can program your fleet adapter to respond to the docking command however you'd like. You can command the robot to go to the waypoint and face a certain direction, then trigger some action to happen (e.g. "take a picture") before triggering the "docking finished" callback. The details for how exactly to do this will depend on how you're integrating your fleet adapter.

In the upcoming release there will be simpler ways to do this, e.g. you can create a custom task that commands the robot to go to a waypoint and then face a certain direction. But the orientation constraint or docking approaches are already available and may be suitable.

Screenshot from 2022-01-25 18-23-02
Screenshot from 2022-01-25 18-24-46

Screen shot:
[full_control-17] [INFO] [1643106395.761572810] [AiMbot_fleet_adapter]: Fleet [AiMbot] is configured to not accept task [Clean5]
[full_control-13] [INFO] [1643106395.761575929] [tinyRobot_fleet_adapter]: Fleet [tinyRobot] is configured to not accept task [Clean5]
[full_control-19] [INFO] [1643106395.761584189] [cleanerBotA_fleet_adapter]: Dock param for dock_name:[zone_3a] unavailable. Rejecting BidNotice with task_id:[Clean5]

about clean tasks, Dock param for dock_name:[zone_3a] unavailable ? any thing wrong?

@brsbilgin
Copy link

I use free_fleet adapter for my ros1. The lane orientation was not defined on lane. The behavior of robot was forward orientation. During forward moving it was perfect. But while robots turn back from lanes the robot turn back in every waypoint and turn back again to continue. It mean it turn 360 degree in each waypoint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants