Skip to content

Conversation

@RenKoya1
Copy link

Hello. I'm Ren in Tokyo tech.
I enabled each agent to manage state and made it compatible with mapd.

@JustinShetty
Copy link
Owner

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?

@RenKoya1
Copy link
Author

Yes. I'll change it

@RenKoya1
Copy link
Author

Hey Justin.
Sorry for the late.
I removed formatting.

- **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.
Copy link
Owner

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)
Copy link
Owner

@JustinShetty JustinShetty Jul 2, 2025

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
Copy link
Owner

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...

Copy link
Owner

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;
Copy link
Owner

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)

Comment on lines +4 to +10
export enum AgentState {
PICKING,
CARRYING,
DELIVERED,
IDLE,
NONE,
}
Copy link
Owner

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)

Comment on lines 41 to +44
export class Pose {
public position: Coordinate = new Coordinate(0, 0);
public orientation: Orientation = Orientation.NONE;
public state: AgentState = AgentState.NONE;
Copy link
Owner

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);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove

Comment on lines +83 to 86
if (config.length === 0) {
throw new Error("Invalid solution: no poses found");
}
if (config.length === 0) throw new Error("Invalid solution");
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

redundant?

Comment on lines -261 to -271
// 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]);
});
Copy link
Owner

@JustinShetty JustinShetty Jul 2, 2025

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?

Copy link
Owner

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) {
Copy link
Owner

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;
Copy link
Owner

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

Copy link
Owner

@JustinShetty JustinShetty left a 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.

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

Successfully merging this pull request may close these issues.

2 participants