-
Notifications
You must be signed in to change notification settings - Fork 66
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
Comments
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? |
Thank you for noticing the issue with doors 🚪 . I'll open a separate ticket for the doors issue, to keep this ticket lift-specific. |
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:
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 In that setup, for a robot to "correctly" navigate from a waypoint on
A rough ASCII diagram would look like this (numbers are waypoints and letters are edges):
|
To see how these edge properties tie into the RoMi-H fleet adapters, you can see how the navigation graph is being parsed here. |
Hi @mxgrey , In traffic-editor, is L3 configured as 'level'? and are waypoint 2, edge b, and waypoint 3 are placed on level L3 ? |
The point of the 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. |
No description provided.
The text was updated successfully, but these errors were encountered: