Project Logs

Collapse

• From Data Mapping to Real Gravel

  Olda • 06/10/2026 at 07:38 • 0 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:

  • quarry and heavy road transport
  • bus and tram operation
  • railway operation
  • supply and delivery lines
  • agricultural work scenarios

  So the cable...

  Read more »

• Control Monitor video

  Olda • 05/29/2026 at 10:37 • 0 comments

• Track Editor and Control Monitor

  Olda • 05/29/2026 at 10:31 • 0 comments

  When I started this project, I had to figure out and test many things on my own. Model railway forums contain a lot of information, but they are not always very open, organized, or helpful when it comes to specific solutions. In the end, you search wherever you can, test things, print parts, rebuild them, and slowly put together your own system from many small pieces of experience.

  Over time, this project has grown into something much larger than a single hidden magnetic road. A custom Track Editor, Control Monitor, and a set of tools are being developed to automate a large part of both the design and physical construction of the track.

  The goal is to keep the physical track, the control logic, and the traffic visualization connected. I do not want one version of the layout on the table, another one in the software, and a third one somewhere in my notes. The whole system is based on the idea that the layout is designed once, and from that single source both the physical parts and the data files for control and simulation are generated.

  Track Editor

  The Track Editor is a custom program for designing the track. It is not just a drawing tool, but a generator for both the physical and logical form of the system.

  The editor works with track pieces from which the final route is assembled. Each segment can contain geometry, direction rules, traffic rules, allowed load state, and connections to other parts of the track. The track is therefore both a physical object and a graph for the control software.

  Unlike normal layout drawing, it is not enough to simply connect lines. In this system, every part also has a mechanical meaning. A vehicle cannot magically turn around in place, a long vehicle may not be able to pass through every junction, and some sections may only be allowed for empty or loaded vehicles.

  For that reason, the editor does not only describe the visual shape of the route, but also the rules that will later be used by the control applications.

  STL generation

  STL generation already works in the editor. The program can create physical 3D-printable parts from the designed route.

  This is one of the most important parts of the whole project. The track is not created by manually drawing every part separately, but as an output from the editor. The same design is therefore used both for printing and for traffic control.

  The editor can work with physical segments, split them into printable parts, and prepare STL files. This makes it possible to design a route, generate the parts, print them, and use the same data in the Control Monitor.

  This approach greatly reduces manual work and, more importantly, reduces the risk that the physical and software versions of the track will start to drift apart.

  Vehicle and accessory configurators

  The same principle can also be used for vehicles and other layout elements.

  The goal is for the program to generate not only the track, but also configurable vehicle models and accessories. For example, a truck can have different chassis variants, axle counts, body types, or working roles.

  In the same way, the system can later generate other trackside elements: embankments, holders, signals, turnout parts, service points, or other layout components.

  Over time, this creates a library of elements that are not just one-off hand-made models, but parts of a larger system.

  Control Monitor

  The Control Monitor is the second part of the system. It is a separate C/GTK application that loads the data generated by the editor and uses it for simulation, visualization, and debugging of traffic.

  The editor creates the track.
  The Control Monitor operates it.

  The monitor can display the track topology, vehicles, planned routes, occupied and reserved segments, the dispatch log, planner score, and other information. It can simulate vehicle movement without real hardware and verify whether the route logic matches what was designed in the editor.

  The screenshots show the Control Monitor...

  Read more »

• Local Positioning System (LPS)

  Olda • 04/28/2026 at 19:14 • 0 comments

  I’ve been trying to improve how accurately I can determine vehicle positions on the layout. The original approach was purely theoretical – position estimated from speed and direction (dead reckoning), with occasional corrections using Hall sensors.

  I also experimented with other approaches (e.g. ultrasonic), but those quickly turned into a dead end – too complex, unreliable, and without any real benefit.

  In the end, I settled on something that could be described as a local “GPS-like” system – a simple LPS based on RSSI using ESP-NOW.

  Implementation

  On the test quarry layout I’m currently running:

  • 2× ESP32 (low master, top master)
  • 2× ESP32-C3 placed in the corners of the layout

  Each vehicle (worker) uses an ESP32-C3 that periodically broadcasts a simple packet with its ID.

  The corner nodes receive this packet and evaluate signal strength. The result is four RSSI values (in dBm), which are then used to estimate the vehicle’s position within a predefined track.

  Why this makes sense

  RSSI on its own is noisy and inaccurate. Dead reckoning alone drifts over time. Hall sensors are precise, but only at specific points.

  So instead of relying on a single method, I combine:

  • theoretical position (speed + direction)
  • corrections from Hall sensors
  • continuous correction from the LPS

  The result is not an exact position, but a stable estimate that is continuously refined.

  frequent imprecise measurements + occasional precise corrections = usable reality
  

  Result

  The goal is not millimeter accuracy.

  At vehicle speeds around 2 cm/s, the system allows me to:

  • predict vehicle positions
  • control spacing between vehicles
  • smoothly approach target points (loading, unloading)

  For controlled operation, this is more important than absolute precision.

  Context

  On paper, this is a bad solution. It combines imprecise methods and ignores “cleaner” approaches.

  In this specific context (low speed, constrained space, known trajectory), it makes sense and performs better than trying to force a perfectly accurate solution using a single method.

  Conclusion

  The goal here is not to find the most accurate positioning method, but one that enables:

  • stable system behavior
  • smooth operation
  • predictable interaction between vehicles

  In other words:

  I’m not solving “where exactly it is”, but “how the system behaves as a whole”
  

• Update: PC monitoring application

  Olda • 04/22/2026 at 18:48 • 0 comments

  I've added a PC application to the system, written in C (GTK3 + Cairo, compiled in MSYS2 for Windows). The goal was to get realtime visualization of the vehicle position on the track, without depending on any proprietary tool.

  What the application does:

  It renders the quarry track from 200 control points, which are refined at runtime into 800 interpolated points for a smoother curve. The vehicle is displayed as an arrow with smooth rotation based on the tangent to the track. The arrow color indicates the mode — blue for manual control, cyan for automatic, orange during safety stop, red in the local simulator.

  Communication with the top master (ESP32) runs over HTTP — the ESP provides a /data endpoint with JSON payload (position, speed, direction, hall states, safety stop). The application fetches data in a separate thread via libcurl with a 2s timeout, so the GUI doesn't freeze when the ESP doesn't respond.

  Hall sensors and track behavior:

  There are five hall sensors placed along the track, between the end points and the middle. Both the application and the low master evaluate hall state themselves — meaning they detect changes in the magnetic field, not its absolute level. This matters because each hall has a slightly different polarity depending on how it was mounted. Instead of looking for a common level, the system simply watches for transitions. On top of that there's debouncing in a time window, so short transient spikes are ignored and only a stable change is propagated to the system.

  Basic vehicle behavior is built on top of the hall sensors. When the vehicle reaches one of the end halls, safety stop kicks in — the vehicle halts and the system waits for user intervention. When the user presses a direction button after 5 seconds, safety stop is released.

  Local simulator:

  The biggest added value is the local mode. Flipping a switch disconnects the application from the ESP and the vehicle is controlled by FWD/BWD/STOP buttons plus a throttle slider. This let me tune the visualization, end-of-track detection, arrow rotation and overall UX without having to wire up the ESP and run the hardware. Nice side effect — when the ESP is running and WiFi drops, the application doesn't crash and keeps the last known state, or you can switch to manual testing.

  End-of-track rotation:

  I was solving a topological issue — the track is visually a one-way line, but physically the vehicle reverses. Instead of the arrow just flipping back and forth along the same line (nonsense), I implemented a state machine: the vehicle reaches the end, stops for 2s, then smoothly rotates 180° over 3s, and waits for another user input. This way the visualization behaves the way an observer intuitively expects.

• Karosa ŠM11 test

  Olda • 04/07/2026 at 15:54 • 0 comments

  First test drive — bus on magnetic track

  Test drive of a bus on the magnetic track in the quarry test polygon. The purpose was to verify curve clearance with an extended chassis. This is the first long chassis on this track, so the key question was whether it would fit through the switchbacks at all. Manual control.

  The bus has an issue with the front axle lifting the chassis in curves — currently unsolved due to the constraints of TT scale, but it´s in progress :)
  

  Next step — automatic position tracking system. In traditional DCC, you only know that a train is somewhere within a block, not where exactly. This system aims to track vehicle position continuously along the entire route with reasonable accuracy, using hall sensor pairs as reference points and speed-based interpolation between them.
  

View all 6 project logs