Brickrail - LEGO PoweredUp Train automation

[Novakasa]

Hey all,

Yesterday, I created the first alpha release for my open source LEGO train automation software, so I created a short trailer for it:

Brickrail features a GUI running on a BLE-capable PC. It connects to PoweredUp hubs running Pybricks firmware. The trains detect their location using a PoweredUp Color & Distance sensor pointed on the tracks. Block sections on the tracks are delimited by colorful markers.

Head to Github page to download the most recent release, and visit the Wiki on Github to learn more about how Brickrail works!

More longer demo videos are live on youtube.

Edited April 16, 2023 by Novakasa

[iragm]

This looks incredibly cool.

[Ts__]

Oh, really cool and a good movie. A little bit tooo fast and short, but good!

Very interesting concept. I don't have a train room at home and therefore no use for it, but I find it exciting what all can be implemented with Lego PU and PyBricks.

Therefore, thank you for sharing.

Thomas

[Novakasa]

8 minutes ago, Ts__ said:

Oh, really cool and a good movie. A little bit tooo fast and short, but good!

Thanks! The video above was made more like a trailer, if you'd like to see a longer demo, look here:

 

Edited April 16, 2023 by Novakasa

[Elphiel]

That is one very nice and easy to use software it seems. Always wished for some easy point and click software to get some automated movement for my trains. Never wanted to get deep into programing and was looking forward for someone to build some simple software like you did.
Looks like quite some effort with some real nice result.
Sadly I live in a macOS only world. So cant test it :(
If you ever get a version that runs on macOS I will be all in ;)

[Novakasa]

43 minutes ago, Elphiel said:

If you ever get a version that runs on macOS I will be all in ;)

Unfortunately, I don't have a mac device to test, however as far as I know all the dependencies are mac compatible in principle. So I might be able to build a mac version using Github actions, but I won't be able to test it. I think I'll see if I can do that and release it as an experimental build in the next days/weeks, and it would be great if you could test it! However, you'll need pybricks installed on your hubs, and specifically the version provided with the Brickrail release (independent of which OS you are using).

[iragm]

Thank you for making this available on Linux -- works great.  I think that long term, it might make sense to look into moving the project to the web, instead of a locally installed app (this would require Chrome, sadly), but it would allow Mac and mobile users to also use this.  Pybricks on the web seems to work pretty well with BLE.  About 75% of the traffic I see is from mobile, so it's a good idea to bring in these folks.  Additionally, a web platform would allow you to collect analytics on how it's used by users, which makes development a lot easier.

The documentation and videos are really nice.  I hope this project takes off, as I've wanted to make something like this and haven't had time.

[Lok24]

Is there a specific reason why you run Pybricks on the hubs?

[Novakasa]

25 minutes ago, iragm said:

Thank you for making this available on Linux -- works great.  I think that long term, it might make sense to look into moving the project to the web, instead of a locally installed app (this would require Chrome, sadly), but it would allow Mac and mobile users to also use this.

Indeed, that would be great. It's not planned in the short term but I am thinking about it. Technically, the Godot engine, which I am using for the interface and general logic also exports to the web. The most difficult part would be to move the bluetooth part away from the python server and move to web bluetooth in some way, but I have no idea how feasible this is with Godot engine. I have unfortunately no experience in web development yet.

24 minutes ago, Lok24 said:

Is there a specific reason why you run Pybricks on the hubs? 

I actually started this project using a different approach with official firmware and the `bricknil` python library, which exposes the LEGO API to the PC. However, since the hubs don't process the sensor data themselves using this approach, I had to rely on very high rate of bluetooth communications, and I might have found a limit of it only working reliably with at most 3 LEGO PoweredUp hubs at the same time.

With pybricks, I can move a lot of the sensor processing and logic to the hubs themselves. The communication then only has to handle quite high level commands and signals, so I have not found any limits with how many hubs I can operate at the same time yet.

Of course, 2 years ago I was still quite inexperienced in this project so there might have been a better way with only original firmware.

[Lok24]

I see! very interesting, and a nice solution.

[Sunil766]

I feel like this is a big thing for the PU train community and should get a lot of credit for it's ingenuity. It seems you have put a lot of work into it for a "hobby"-only project. 

I haven't tried this myself, as I am not willing to buy so many batteries for the hubs (I'm 9v), but if I understand this correctly, the beauty of the solution lies in the fact that you can more easily automate different (as in casual or "pop-up") layouts. A train room or permanent track layout only needs to be automated once. 

Great work! 

[Blacktron2]

I have been following Mattzobricks for a while and even implemented their system using ESP32/Rocrail/MQQT. However, I feel that it is quite complicated for the simple automation I am shooting for. Your approach might fit just that! Thank you for sharing.

[lego3057]

How do you install it in Windows (if possible).Thanks.

[Novakasa]

31 minutes ago, lego3057 said:

How do you install it in Windows (if possible).Thanks.

Brickrail doesn't need to be installed, the releases are just archives of a portable binary executable and some other files that need to be kept in the same folder.

• Go to the releases page on the github repository and navigate to the latest one: https://github.com/Novakasa/brickrail/releases/tag/v1.0.0-alpha.2
• Download the zip archive (not source code) for your platform. In your case, that would be brickrail-windows-v1.0.0-alpha.2.zip
• Unzip the archive to your favorite location using a zip extraction tool, e.g. WinRar
• Start Brickrail.exe (On linux you might need to enable the execution permission on the binary file before you can run it)
• For next steps read through the Wiki: https://github.com/Novakasa/brickrail/wiki

Edited April 21, 2023 by Novakasa

[iragm]

On Linux, I unzipped the archive and then:

cd brickrail-linux/

chmod +x Brickrail.x86_64

./Brickrail.x86_64

 

Worked fine.

[Novakasa]

Just published the 1.0.0-alpha.3 release.

Get it here: https://github.com/Novakasa/brickrail/releases/tag/v1.0.0-alpha.3

This release adds a number of usability improvements and quality of life features.

Brickrail now does not rely on a custom version of pybricks firmware anymore and aims to be compatible with the current pybricks beta firmware. It is still recommended to flash the specific version that comes with the Release, since this is the version Brickrail is tested with.

For people trying out the software, I would really appreciate a report here or over on Github discussions for any issues of even any success you've had. I'll need some reports to have an idea how stable Brickrail is.

Reports for any issues following the instructions in the wiki are also greatly appreciated.

Changelog:

Added

•     Added "discouraged" reversing behavior. With this option, the train will only reverse when there is no other option. (#125)
•     Distinguish current train position from "home" position. Current position is saved in settings, home position saved in .brl layout file. (#78)
•     Added "Download" checkbox to hub GUI. Unchecking it skips downloading the program to the hub, assuming that it is stored on the hub (#92).
•     Brickrail stores for each hub name the last hub program hash. If it is different, Download checkbox is checked automatically to make hub download the new program.
•     Added File logging. Logs will be available in user folder.
•     Added Control devices mode for switches only, allowing manual train control (#77).
•     Move view appropriately when changing "layers unfolded" or changing active Layer.
•     Finally added ability to remove hubs from project.
•     Make track section select easier by flipping the selection of single track appropriately.
•     Automatically select connected track when deleting a single track segment.
•     Current brickrail layout path now displayed in window title.
•     Added configurable motor and sensor parameters to Trains (#116, #85).
•     Added battery voltage display for hubs (#111).
•     Added ability to invert train motor polarity (#112).
•     Added layout changed label in status bar to highlight unsaved changes (and for debugging).
•     Added robustness for crashed BLEServer, new button to manually start it again and display more errors related to BLEServer connection (#51).

Fixed

•     Fixed issue when adding layer after loading a layout.
•     Fixed requirement for program start timeout being very long by instead starting the timer after program was downloaded.
•     Fixed some track connections not disconnected properly when deleting track.
•     Fixed phantom prior sensors reappearing despite deleted after loading brickrail layouts (#117).
•     Disable Godot HiDPI setting, since we currently don't react to user OS-level DPI scaling (https://github.com/Novakasa/brickrail/discussions/107#discussioncomment-5689736).
•     Fixed false unsaved changes prompt when train had been selected.
•     Fixed "control devices" enabled despite error while starting hub program.

Changed

•     Moved away from frozen module in firmware. Brickrail should now be compatible with standard pybricks firmware.
•     Allow enabling/disabling "only forward" setting for trains in "Control layout" mode.

 

Edited May 5, 2023 by Novakasa

[BatteryPoweredBricks]

Hoping to test this soon, I just tore down my last layout so I can make something specific for automation.  What design are you using for the motorized TrixBrix switch tracks?  I just got a load of them in, but haven't nailed down a solution for them yet.  The double crossover is a royal pain, there is zero room to work with, I may just abandon that one.  Thanks for all the hard work on this project!

[Novakasa]

Thanks for the interest! I did write about my switch solution in the wiki: https://github.com/Novakasa/brickrail/wiki/5-Setup-your-devices#setup-your-switches

I also linked some instructions for it: https://github.com/Novakasa/brickrail/files/11241947/technic-switch-motorized-v2-steps.pdf

I also had to fiddle quite a bit, this is my second design which I made mostly using technic pieces, as I wanted something that absorbs all excess torque by itself, not applying any force that could disconnect the mechanism from the switches. However, the clutch gear seems to be a bit too weak for my newest trixbrix switches. I think using a trixbrix switch a lot loosens the mechanism, since all my older switches work flawlessly with this design.

I guess you can try to replace the clutch gear with a normal gear, but then I should probably expose some settings in the Brickrail GUI for the motor strength (in DC) and pulse duration, in order to not apply too much torque.

Also since I made the instructions above, I noticed a flaw where the brown axle would sometimes block the mechanism from switching. To fix it, move the black pin in step 10 one hole to the right. This blocks the brown axle from entering this hole.

 

Also when trying Brickrail, currently it is expected that the sensor only sees dark or desaturated colors except for the markers. This can be an issue when using a layout e.g. on green baseplates or a colorful floor. I am planning to do something about it (see also this disccusion), but for now there is only the "chroma threshold" setting for trains which can be increased if you get wrong marker detections.

 

If you encounter any issues, feel free to report them on github (discussions is a good place if you are looking for help), and I might be able to apply fixes as well.

Edited May 8, 2023 by Novakasa

[BatteryPoweredBricks]

Thanks for the quick reply!  This design seems to work very well.  I quickly built it on my lunch break.  I completely skipped the clutch gear, I've had far too many issues with them when motorizing official Lego switch tracks.  No two clutch gears act the same and any added variables only compound the issue.  I also added a piece that helps it to not over-rotate as much.  I'll play with it some more when I get home.

I for one would very much appreciate the option to control the motor strength and duration.  I'm not a software guru so I don't know how much work this would be to implement but I would imagine some users would find it useful.  Whether they are using different switch tracks or a different motorized switch design.

(apologies for using a competing software solution , I only had a few minutes to test it)

 

[Novakasa]

I'll definitely try to implement the motor customizations soon, but in the meantime, you could tweak the numbers in the pybricks programs once you have extracted the brickrail release. The program is located in ble-server/hub_programs/layout_controller.py

In line 35, you should be able to customize the pulse duration here (currently it is 600 ms):

def __init__(self, port, pulse_duration = 600):

And the motor strength can be adjusted in line 49 (default is 100 DC):

self.motor.dc(100*sdir)

Changing these values will change it for every switch at the same time, in the future I'll make it so you can change these values on a per-switch basis.

Edited May 8, 2023 by Novakasa