-
Notifications
You must be signed in to change notification settings - Fork 3
support mapd #50
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
base: main
Are you sure you want to change the base?
support mapd #50
Conversation
|
Hi Ren, this sounds promising. However, I'm having a little trouble understanding the logic changes because most of the files also have indentation and formatting changes. Could you reduce this PR to just modify the logic so I can better understand it? |
|
Yes. I'll change it |
|
Hey Justin. |
| - **Pose**: Each `(...),` represents an agent's pose. The first two elements are the x and y coordinates respectively. The third element (e.g. `X_PLUS`) is optional if your solver considers orientation. | ||
|
|
||
| > [!WARNING] | ||
| > Please note that either **all** or **none** of the poses must contain orientation. A mix of orientation and orientation-less poses is not supported. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please update this warning to explain that all or none must contain orientation information and separately, all or none must contain MAPD state
|
|
||
| > [!WARNING] | ||
| > Please note that either **all** or **none** of the poses must contain orientation. A mix of orientation and orientation-less poses is not supported. | ||
| #### 📦 MAPD Example (Pickup and Delivery) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it might be useful to give 4 examples for the format
| no orientation | with orientation | |
|---|---|---|
| MAPF | A | B |
| MAPD | C | D |
| npm run dev | ||
| ``` | ||
| ```sh | ||
| npm run dev |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a big deal, but it's odd that our editors formatted this differently. I wonder how I can standardize that for the project...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please separate this into a new demo file and retain the original as-is
| } | ||
|
|
||
| export default AnimationControl; | ||
| export default AnimationControl; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just merged #51 which will enforce some new whitespace rules (requires newline at the end of the file and disallows trailing spaces), please pull the latest main and update the formatting as required (--fix with eslint is helpful for these)
| export enum AgentState { | ||
| PICKING, | ||
| CARRYING, | ||
| DELIVERED, | ||
| IDLE, | ||
| NONE, | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think in general the best practice is to list the null/none value first in the enum definition (i.e. so it has integer value 0)
| export class Pose { | ||
| public position: Coordinate = new Coordinate(0, 0); | ||
| public orientation: Orientation = Orientation.NONE; | ||
| public state: AgentState = AgentState.NONE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pose is only the position and orientation of an agent, i.e. it is a kind of state.
Try renaming Pose to AgentState and rework state: AgentState into something like mapdState: MapdState
| const o = orientationFromString(match[3] || ""); | ||
| const stateStr = match[4] || "NONE"; | ||
|
|
||
| console.log(stateStr); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove
| if (config.length === 0) { | ||
| throw new Error("Invalid solution: no poses found"); | ||
| } | ||
| if (config.length === 0) throw new Error("Invalid solution"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
redundant?
| // Goal markers | ||
| const goalMarkers = viewport.addChild(goalMarkersRef.current); | ||
| solution[solution.length - 1].forEach((pose, agentId) => { | ||
| const marker = goalMarkers.addChild(new PIXI.Graphics()); | ||
| const width = GRID_UNIT_TO_PX / 4; | ||
| marker.rect( | ||
| scalePosition(pose.position.x) - width / 2, | ||
| scalePosition(pose.position.y) - width / 2, | ||
| width, width) | ||
| .fill(AGENT_COLORS[agentId % AGENT_COLORS.length]); | ||
| }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these completely removed from MAPF visualizations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I think deliveredMarkersRef includes the MAPF and MAPD cases. If that's true, should goalMarkersRef be removed?
| continue; | ||
| } | ||
|
|
||
| if (!deliveredPose && pose.state === AgentState.DELIVERED) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fix indentation
| deliveredMarkersRef.current.removeChildren(); | ||
|
|
||
| solution[0].forEach((_pose, agentId) => { | ||
| let lastPickingPose: (typeof solution)[0][0] | null = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't necessarily the agent's last pickup, right? Is it more correct to say nextPickup ? It looks like the loop below scans the solution until it finds the next delivery/idle and optionally a pickup marker if one is present before the delivery/idle. Is my understanding correct?
In any case, this is a lot of computation to do every frame. For large visualizations this may have a substantial performance impact. Ideally, you would scan the solution once when it's initially loaded and work through a list of processed list of markers... Maybe it's ok because the loop breaks once it's found the necessary information, but I'm still not happy about looping over the solution more than we need to
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution. I really like this idea, but I have some concerns with how you're structuring agent state and how much overhead managing pickup/delivery markers is adding to every frame. All the markers are destroyed, then it searches the solution (could be quite large) for the next pickup (optional) and delivery for every agent between each frame. I think that aspect can be improved with some work.
Hello. I'm Ren in Tokyo tech.
I enabled each agent to manage state and made it compatible with mapd.