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 lift supported? #125

Open
cwrx777 opened this issue May 15, 2020 · 6 comments
Open

is lift supported? #125

cwrx777 opened this issue May 15, 2020 · 6 comments

Comments

@cwrx777
Copy link
Contributor

cwrx777 commented May 15, 2020

No description provided.

@webvenky
Copy link

webvenky commented May 17, 2020

I, too, would like to know if lift is supported. Also on that note, I tried building two levels with different elevations (0 and 10 m). However, the doors get generated only at elevation 0m for both levels. Am i doing something wrong or is the door generation a work-under-development as well?

@codebot
Copy link
Contributor

codebot commented May 17, 2020

Thank you for noticing the issue with doors 🚪 . I'll open a separate ticket for the doors issue, to keep this ticket lift-specific.

@mxgrey
Copy link
Collaborator

mxgrey commented May 17, 2020

Proper lift support (by which I mean specifying an actual lift that can move between floors, and exporting that information into the navigation graph) is not something that has been developed yet due to time constraints and the need to prioritize certain features over others.

However, for testing and demonstration purposes, we did put in two special navigation graph edge properties that can allow a RoMi-H fleet adapter to emulate lift usage. This is meant for demo scenarios where a "mock lift" has been created that receives lift commands and transmits lift states but does not actually move between any different floors in a building. These properties were initially put in so we could perform a specific demonstration back in December, but we might make them officially supported properties since there may be broad interest in having single-floor hardware test setups that still want to emulate multi-floor scenarios.

The edge properties are:

  • demo_mock_floor_name: The name of the floor that the robot is on while traversing the edge
  • demo_mock_lift_name: The name of the lift that is being entered or exited while the robot traverses the edge

The idea here is that if you have a single floor demonstration environment but want to demonstrate interaction with a lift, then you can set up a mock "lift" and imagine that each side of the "lift" opens to a different floor, and the robot is only allowed to enter/exit that side of the "lift" when the "lift" believes it is on that floor.

To make this idea more concrete, imagine you have a single-floor hardware testing area, and a box is drawn on the ground with an LED display next to it that reads off pretend floor names. The mock lift will transmit lift state messages that match up with whatever floor the LED is displaying. There is also some indication of whether the lift doors are open or closed. You can further imagine that entering or exiting from west side of the "lift" is only allowed when the lift believes it is on floor L1 whereas entering or exiting the "lift" from the east side is only allowed when it believes it is on floor L3.

In that setup, for a robot to "correctly" navigate from a waypoint on L1 to a waypoint on L3, the robot needs to:

  1. Approach the "lift" from the west side
  2. Call the "lift" down to L1
  3. Wait until the lift state has it on floor L1 with the doors open
  4. Move into the "lift" (i.e. the box drawn on the ground) and request that it "moves" to L3
  5. Wait until the "lift" indicates that it has reached L3 and that its doors are open
  6. Exit the "lift" on the east side

A rough ASCII diagram would look like this (numbers are waypoints and letters are edges):

1 <---a---> 2 <---b---> 3
  • Waypoint 1 is on floor L1
  • Waypoint 2 is inside the "lift" named LIFT001
  • Waypoint 3 is on floor L3
  • The properties of edge a are:
    • bidirectional: true
    • demo_mock_floor_name: L1
    • demo_mock_lift_name: LIFT001
  • The properties of edge b are:
    • bidirectional: true
    • demo_mock_floor_name: L3
    • demo_mock_lift_name: LIFT001

@mxgrey
Copy link
Collaborator

mxgrey commented May 17, 2020

To see how these edge properties tie into the RoMi-H fleet adapters, you can see how the navigation graph is being parsed here.

@cwrx777
Copy link
Contributor Author

cwrx777 commented May 17, 2020

Hi @mxgrey ,

In traffic-editor, is L3 configured as 'level'? and are waypoint 2, edge b, and waypoint 3 are placed on level L3 ?

@mxgrey
Copy link
Collaborator

mxgrey commented May 17, 2020

The point of the demo_mock_... edge properties is that it doesn't matter what level the waypoints are actually placed on; the lift will be "summoned" to whatever "level" is specified by demo_mock_floor_name.

In the scenario described above, all the waypoints and edges should be placed on the same level inside the editor, and the edge property is the only thing that determines where the mock lift "goes" to when that edge needs to be traversed by a robot.

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

4 participants