frederikheld / robotrain

Lego® 4558 Metroliner train on steroids

Robotrain

Robotrain is the LEGO® 4558 Metroliner model on steroids.

I modified the original LEGO model and augmented it with Arduino, Raspberry Pi and several electronic components to make it remote controllable.

The main features are:

• More cars which are connected by Jacobs bogies instead of standard bogies with coupling
• Train running on 12 V permanently powered tracks
• Train carries an Uninterruptible Power Supply that allows it to run on non-powered tracks
• NodeMCU Mini with motor driver as motor control
• NodeMCU Mini as remote control
• Raspberry Pi Zero W with camera module as cockpit cam
• MQTT as common communication interface

Planned features are:

• Mobile app that resembles the cockpit of a real train with a view from the drivers seat

This is work in progress. Please see the the sub-directories of modules for more information!

Join Development

Feel free to fork this repository and use it for your own projects!

Electronics and Software

The electronics and software work for all 9 V track-powered train motors and should also work for the battery powered version.

You need to modify the motors to lead the current out of the chassis through one pair of cables and take the motor power in through another pair of cables. I will provide a tutorial on that later!

Working with the Repository

This repository uses the Git LFS extension for binary files. Please activate Git LFS before you commit changes to any of the file types listed in .gitattributes!

Contribution

I'm happy to accept contributions to the main project!. Please have a look into the Issues and see if you can submit a pull request that implements one of it. I'm happy to discuss details with you before you start to work. Maybe we can collaborate on a new feature.

You can also submit pull requests for fixes and features that are not alrady in the issues. If I like it, I will merge it ;-)

robotrain's Issues

Battery indicator in remote control

AS an operator
I WANT TO see if the battery is critical
SO THAT the train doesn't break down on non-electrified tracks.

Context: UPS seems to run out of juice pretty quickly (and over night if the train isn't used)

Acceptance Criteria:

• MQTT topic that publishes a message if the battery is critical
• remote-control indicates critical battery level with an icon

Add mqtt-publisher tool

AS a developer
I WANT TO easily publish messages to selected topics
SO THAT I debug MQTT communication.

Acceptance Criteria:

• Can publish messages to topics
• Works via command line like: $ mqtt-publish 'topic' 'message'
• Allows to configure address and port of MQTT broker in an config file (that comes as an template)
• Can be run with Docker

auto-export Fritzing (.fzz) files as PNG in build pipeline

Right now I need to keep the Fritzing exports in sync with the source files manually. This should automatically be done in the CI pipeline. Those exports should be deployed somewhere so they can be linked in markdown files.

Make MQTT config common for all modules

AS an operator
I WANT TO have all config related to the common communication infrastructure in one place
SO THAT I don't need to spend time configuring each module with the same information.

Acceptance Criteria:

• Common config file for MQTT related settings
• File format that can be consumed by all modules (aka used languages)

Note: This US does not include that all modules need to be refactored to use this config, but the config has to be ready that each module can consume it!

Make backbone cable separable between cars

AS a developer
I WANT TO fully separate the cars from each other
SO THAT I can take a single car and put it on the table which is more handy than the full train.

Context: Right now, the backbone cable that connects the drives at both ends of the train and goes through the whole train is inseparable. This makes the train very unhandy in development.

Add out-of-the-box MQTT broker

AS an operator
I WANT TO have an out-of-the-box MQTT broker
SO THAT I can start playing without much time spent for setup.

Acceptance Criteria:

• Broker works with the modules
• Prepared configuration (like the modules have)
• Broker can be started without much effort

Cockpit-Cam

AS an operator
I WANT TO have a live view from the cockpit of the train on my remote device
SO THAT I can pretend to be sitting in the train while driving around.

Acceptance Criteria:

• camera facing through the windows to the track (roughly the same view as a real driver would have)
• for a start it's enough to have a camera in the front cockpit of the train
• image has to be symmetric
• stream can be received and displayed in a web browser (HTML5) through wifi
• stream should have very little to no delay for a realistic experience (less than 1 s, stable over time)

Get familiar with Arduino Motor Shield

Motor control NodeMCU drops out of WiFi

If the train is powered on for a certain time, the NodeMCU is not available via MQTT anymore as it drops out form WiFi. This can happen after an hour, after a couple of hours, sometimes not at all through the whole day.

You can mitigate the bug by resetting the NodeMCU or by unpowering the train and then powering up again.

Possible Reasons

Arduino Sketch has memory leaks

• check if the dropout is related to the number of MQTT messages sent to the NodeMCU.

I read about ways the library can leak memory in https://github.com/knolleary/pubsubclient.

• similar issue
• this might be my issue

I would appreciate help on that as I'm not firm with memory management in C

Other possible issues with the Arduino Sketch

• Wifi issues

NodeMCU is overheated

With all the electronis inside, the train gets pretty warm. Active ventilation might fix the issue.

Dockerize mqtt-sniffer

AS a developer
I WANT TO be able to run mqtt-sniffer with Docker
SO THAT I don't need to install NodeJS

Context: all infrastructure and tools should provide an option to be run via Docker. Other options can be kept for those who have the necessary installed already.

Acceptance Criteria:

• mqtt-sniffer can be run with Docker

Make names of config options for min and max speed more explicit

Now:

#define SPEED_NOMINAL_MAX 100 // max value of "speed nominal"
#define SPEED_NOMINAL_MIN -100 // min value of "speed nominal"

What SPEED_NOMINAL_MIN actually means is "max speed in reversed direction"!

Therefore change names to:

#define SPEED_NOMINAL_MAX_FWD 100 // max value of "speed nominal" in forward direction
#define SPEED_NOMINAL_MAX_REV 100 // min value of "speed nominal" in reverse direction

The value sent for reverse speeds should still be negative to have a fallback if the information for nominal direction wasn't transmitted correctly.