ekusiadadus
Joined 3 years ago
Karma
71
Submissions
98
Member since
Nov 7
I'm a software engineer living in Tokyo. I was born and raised here, and have spent almost my entire life in the city.
View on Hacker NewsRecent submissions
Comment · 8 months ago
I've been working on multi-agent path finding (MAPF) for warehouse robotics, so when Amazon published the DeepFleet paper (arXiv, Aug 2025), I spent
considerable time dissecting it.
Four things I found most interesting:
1. The 97M-parameter Robot-Centric model beat the 840M and 900M alternatives. Local interaction propagation matters more than global context — a finding that aligns with what we see in classical MAPF (PIBT, LaCAM).
2. Image-based representations catastrophically failed (186% congestion delay error). You cannot represent a robot as a single pixel and expect to capture fleet interactions.
3. The 13M-parameter Graph-Floor model was surprisingly competitive. This suggests the warehouse's graph topology itself is the binding constraint on coordination quality.
4. The scaling laws section experimentally confirms power-law behavior over two orders of magnitude — giving substance to the "improves over time" claim.
I also tried to translate the technical findings into economic terms using Little's Law: a 10% travel time reduction in a 1,000-robot warehouse is equivalent to ~100 fewer robots ($1.3M/year).
I build Rovnou (https://rovnou.com), which does MAPF-based fleet coordination for non-Amazon warehouses. The DeepFleet paper validates many design choices we've made (event-driven, local context, graph-first), while also showing where foundation models may eventually surpass classical solvers.
Happy to discuss the architecture tradeoffs, MAPF vs. learned approaches, or practical deployment challenges.
Comment · 10 months ago
Great question! The current implementation is relatively straightforward:
Layout: The diagram generation uses fixed coordinate positioning (x, y values) calculated heuristically based on node indices and predefined
spacing. For example, flowcharts use a simple vertical layout with consistent spacing. There's no automatic layout engine - it's manual
coordinate calculation.
Arrow routing: Currently uses simple direct connections between source and target nodes. draw.io handles the actual path rendering, but we don't
leverage draw.io's advanced edge routing algorithms (orthogonal routing, etc.) - arrows just connect the specified entry/exit points.
CJK text sizing: This is actually an area that could use improvement. The current implementation doesn't dynamically calculate text width for
CJK characters. Node widths are set to fixed values (e.g., 120px for flowchart nodes), which works reasonably for short labels but may clip
longer CJK text. draw.io does handle CJK rendering internally, but we're not pre-measuring text to adjust geometry.
So to directly answer: it's mostly heuristic-based with fixed layouts, not leveraging draw.io's internal layout rules. The .drawio XML format
gives us the geometry, and draw.io renders it. Future improvements could include:
- Auto-layout algorithms (dagre.js style)
- Text measurement for proper sizing
- Smarter edge routing
Thanks for the interest!