Nice work! I think this could be relevant outdoors as well, especially for robots using locally built maps rather than street maps. One challenge I'd expect, though, is real-time visualization of robot locations in outdoor environments, but if it works, it would be very valuable.
You're right that Leaflet is great for GPS, but this tool is specifically for robots using SLAM-generated occupancy grids in a local coordinate frame. Even for long-distance navigation, many autonomous systems prefer these maps for higher precision and better integration with their local planners.
Lowpass filtering with downsampling is definitely a more efficient way to simplify images compared to my approach. This project is an experimental demo of a genetic algorithm evolving random pixel patterns to approximate a target image.
I agree that true pixel art often requires artistic "reimagining" to stay visually appealing. Thanks for your feedback!
Thanks for pointing that out. You're absolutely right. What I'm doing here is definitely not pixel art in the traditional sense, and I now realize the term may have been misleading. My apologies for that.
Thanks a lot for the thoughtful feedback — I really appreciate it!
I think there might be a small misunderstanding regarding how the LLM is actually being used here (and in many agent-based setups). The LLM itself isn’t directly executing twist commands or handling motion; it’s acting as a decision-maker that chooses from a set of callable tools (Python functions) based on the task description and intermediate results.
In this case, yes — one of the tools happens to publish Twist commands, but that’s just one of many modular tools the LLM can invoke. Whether it’s controlling motion or running object detection, from the LLM’s point of view it’s simply choosing which function to call next. So the computational load really depends on what the tool does internally — not the LLM’s reasoning process itself.
Of course, I agree with your broader point: we should push toward more meaningful high-level tasks where LLMs can orchestrate complex pipelines — and I think your examples (like fetch-a-beer or map annotation via VLMs) are spot-on.
My goal with this project was to explore that decision-making loop in a minimal, creative setting — kind of like a sandbox for LLM-agent behavior.
Actually, I’m currently working on something along those lines using a TurtleBot3. I’m planning to provide the agent with tools that let it scan obstacles via 3D LiDAR and recognize objects through image processing, so that it can make more context-aware decisions.
Really appreciate the push for deeper use cases — that’s definitely where I want to go next!
TurtleSim itself doesn't simulate real-world physics — it allows instant position updates when needed. In this project, the goal was to create a digital turtle artist, not to replicate physical realism. So when the agent wants to draw something, it puts the pen down and moves physically (i.e., using velocity commands). But when it doesn't need to draw and just wants to move quickly to another position, it uses a teleport function I provided as a tool.
That's why in the rainbow example, you might see the turtle "jump" between arcs — it's skipping the movement to get to the next drawing point faster.
Thanks for the thoughtful question! The term “agent” definitely gets used in a lot of different ways, so I’ll clarify what I mean here.
In this project, an agent is an LLM-powered system that takes a high-level user instruction, reasons about what steps are needed to fulfill it, and then executes those steps using a set of tools. So it’s more than a single prompted LLM call — the agent maintains a kind of working state and can call external functions iteratively as it plans and acts.
Concretely, in turtlesim_agent, the agent receives an input like “draw a red triangle,” and then:
1. Uses the LLM to interpret the intent,
2. Decides which tools to use (like move forward, turn, set pen color),
3. Calls those tools step-by-step until the task is done.