Close

From Data Mapping to Real Gravel

A project log for Magnetic Road Transport System for TT Scale Layout

Magnetic Road Transport System for TT Scale Layout — DIY Control on ESP32

oldaOlda 06/10/2026 at 07:380 Comments

While working on the data transfer between the Track Editor and the Control Monitor, I ran into some issues with variables and data mapping. Instead of staring at log files forever, I decided to move another physical part of the project forward: the cable shovel excavator.

The excavator can now load real crushed stone, ideally in the 2–4 mm fraction, and this brings me to something I probably have not explained clearly enough yet — the transport system behind the whole project.

At the beginning, this was supposed to be a much smaller idea: a way to move away from classic DCC-style control and use modern ESP-based control instead. Over time, the project grew far beyond that. The current goal is no longer just “control a vehicle”. It is becoming a complete model transport system for railways, road vehicles, trams, buses and industrial transport sets.

The first full test scenario is a quarry.

In this quarry setup, real material is loaded by an excavator. The cable shovel is now working in a simplified form, while a diesel-hydraulic excavator is still under development. After loading, the material is transported to a dump point, where the amount can be weighed. From there, the material can either be exported further or, in the test quarry version, returned back under the excavators as a closed physical cycle.

The Track Editor already supports the quarry set and the basic elements of bus transport. The user creates a route from segments and nodes, sets simple operating rules, and the route is then exported in two ways: as STL files for physical 3D printing, and as JSON data for the Control Monitor.

The Control Monitor runs a planner that makes deterministic decisions based on a weighted score system. Whenever something happens on the route that requires a decision, the situation is recalculated and the state of the vehicles, trains or other moving units can be updated.

I also added a local LLM layer. Originally, it was meant only as a debug assistant, because reading plain text log files is not exactly my idea of fun. The LLM can reformulate log events and explain what is happening in a more human-readable way.

Over time, it became clear that the LLM can also be useful as an advisory layer in the planner. However, it cannot be part of the hard real-time control loop. A local LLM needs some time to answer, and the deterministic planner cannot wait for an LLM response every time it recalculates a situation on the layout.

For that reason, the LLM has only a limited advisory weight. At the moment, the maximum decision score is 100 points, and the LLM can contribute up to 20 points. In other words, it has a voice, but it does not stop the whole system while it thinks.

The system is not tied only to the quarry. If I select a bus scenario in the editor, the same logic can be used for bus stops, service points and route rules. A vehicle configurator is also part of the idea: the user can select a vehicle type, such as a bus, truck, dumper or tractor unit, choose a body type, number of axles and other parameters, and the program generates the required STL files.

Because the visible vehicle model does not need its own electronics or motor, the generated body can simply be printed and used with the hidden drive system.

The updated goal of the project is simple to describe, even though it is not simple to build: I want to create arbitrary transport situations on a model layout and let the system operate them. The position of each vehicle or train can be tracked using a combination of local positioning, Hall sensors and the theoretical route position calculated by the software.

This modular approach means that the system is not limited to one fixed layout. It can be used to create different working dioramas or extensions for a model railway layout.

The planned transport sets include:

So the cable shovel shown here is not just a separate animated model. It is the first working physical machine in a larger generated model transport system. The quarry is the first full scenario where the editor, printed track parts, Control Monitor, planner, physical vehicles and material handling can come together.

It is still rough, and many parts are still prototypes, but the important point is already visible: this is no longer only scenery. The model can actually work.

Discussions