search

BrickBot / brickOS-bibo

An alternative RCX operating system and firmware cloning brickOS. The kernel was written from scratch for better performance, but to the average brickOS programmer, changes should be transparent. There is a lot of code borrowed from brickOS, and numerous patches originally targeted for brickOS have been conceptually incorporated. While this project is based on bibo, as brickOS still seems to be the more recognizable name, it has been retained as part of the name.
http://brickos.sf.net/
Mozilla Public License 2.0
12 stars 3 forks source link

Trouble installing this package #7

Open Gun-neR opened 2 months ago

Gun-neR commented 2 months ago

"If things don't quite work, work at it. :-)" OK... I have been "working at it" for hours now... ;)

I have previously installed and used brickOS... but want to use this bibo's feature of RCX IR control of Power Functions receivers.

I am running RPi4 Bullseye, and this is all I get when trying to install this. 

pi@piLEGOHAT:~/brickOS-bibo $ ./configure

Welcome to the brickOS Makefile configurator.
Attempting to find the Hitachi gcc compiler. (This may take some time.)

 - CrossToolPrefix = /usr/bin/h8300-hms-
 - Found Linux/Unix system

pi@piLEGOHAT:~/brickOS-bibo $ make
demo/esterel/Makefile.sub:14: Esterel compiler not found; skipping Esterel programs
[ -z '' ] || sed -i -r 's/^BASE1[[:space:]]*=[[:space:]]*0x[0-9A-Fa-f]{4}$/BASE1 = 0xad2c/' Makefile.user
[ -z '' ] || sed -i -r 's/^BASE2[[:space:]]*=[[:space:]]*0x[0-9A-Fa-f]{4}$/BASE2 = 0xaf3c/' Makefile.user
cd xs/lisp && ../xs-rcx < ../../demo/xs-lisp/fact.lsp
Welcome to XS: Lisp on Lego MindStorms

>xsout written
xsout written
>xsout written
>xsout written
>Killed
make: *** [demo/xs-lisp/Makefile.sub:37: demo/xs-lisp/fact.o] Error 137
pi@piLEGOHAT:~/brickOS-bibo $ make install
demo/esterel/Makefile.sub:14: Esterel compiler not found; skipping Esterel programs
mkdir -p /usr/local/brickos/man/man1
mkdir: cannot create directory ‘/usr/local/brickos’: Permission denied
make: *** [util/host/Makefile.sub:72: /usr/local/brickos/man/man1] Error 1
pi@piLEGOHAT:~/brickOS-bibo $
mesheets commented 2 months ago

The last CI build of this project with GitHub Actions was successful, but as it had been several months, I kicked off a build again just in case there might have been any issues introduced by anything in recent platform or package updates. That ran with no reported issues on "Ubuntu-Latest" (c.f. log here).

I have not attempted to build and run on a device with an ARM processor, but from the build log snippet, I'm not necessarily certain that this is an ARM-related issue. Quick thoughts offhand—

Gun-neR commented 2 months ago

Not sure I understood most of what you said, Hah! :D

But I brought out my old slow laptop running Mint, and tried your 7 install steps again... As best as they make sense to me...

-1 $ ./configure - Didn't run, wanted more files first

-0 - Not listed here, but I recalled it from another brickOS instruction site - $ sudo apt-get install -y binutils-h8300-hms gcc-h8300-hms

-1 $ ./configure - Found what it was looking for.

-2 $ make - This time it did a ton of stuff... Way too much to list here.

-3 $ make install - Firstly, I don't understand the "You can change the destination directory by editing prefix in Makefile.config." The only directory there was referring to /usr/bin/h8300-hms- with didn't make sense to me why I would want to muck with that? But anyhow, it ran into errors... 

gunner@HP-2000-Notebook-PC:~/brickOS-bibo$ make install
demo/esterel/Makefile.sub:14: Esterel compiler not found; skipping Esterel programs
mkdir -p /usr/local/brickos/man/man1
mkdir: cannot create directory ‘/usr/local/brickos’: Permission denied
make: *** [util/host/Makefile.sub:72: /usr/local/brickos/man/man1] Error 1
gunner@HP-2000-Notebook-PC:~/brickOS-bibo$

-4 - No idea what to do with any path, but "Use firmdl3 to download boot/brickOS.srec to your RCX." can't find brickOS.srec And neither could I, when looking through the brickOS-bibo folder I am working out of. Perhaps that was something that needed step 3 to create?

-5 - Well, I am stalled out at 3 & 4 ;)

And here I just wanted to control some PF servos for a LEGO monorail setup (I already have that working with a Robot Inventor HUB and Pybricks, but wanted make use of my old RCX instead as it was more period correct). And here I thought that would be fun... But this is sucking all the fun out of that idea, hah.

But any assistance is still appreciated. Thanks!

Gun-neR commented 2 months ago

Doh... Right after posting all that, I thought to try sudo for step 3

gunner@HP-2000-Notebook-PC:~/brickOS-bibo$ sudo make install
[sudo] password for gunner:         
demo/esterel/Makefile.sub:14: Esterel compiler not found; skipping Esterel programs
mkdir -p /usr/local/brickos/man/man1
test -d /usr/local/brickos/bin || mkdir -p /usr/local/brickos/bin
test -d /usr/local/brickos/man/man1 || mkdir -p /usr/local/brickos/man/man1
install -s -m 755  util/fontdesign util/firmdl util/dll util/makelx util/genlds util/lnpmsg util/ir-server /usr/local/brickos/bin/
install -m 644 util/host/firmdl.1 util/host/dll.1 /usr/local/brickos/man/man1/
test -d /usr/local/brickos/h8300-hitachi-hms/lib || mkdir -p /usr/local/brickos/h8300-hitachi-hms/lib
install -m 644 lib/libc.a lib/libc++.a lib/libmint.a lib/libfloat.a /usr/local/brickos/h8300-hitachi-hms/lib
test -d /usr/local/brickos/h8300-hitachi-hms/include \
|| mkdir -p /usr/local/brickos/h8300-hitachi-hms/include
test -d /usr/local/brickos/h8300-hitachi-hms/include/rom \
|| mkdir -p /usr/local/brickos/h8300-hitachi-hms/include/rom
test -d /usr/local/brickos/h8300-hitachi-hms/include/sys \
|| mkdir -p /usr/local/brickos/h8300-hitachi-hms/include/sys
for i in config.h conio.h dbutton.h dirpd.h dkey.h dlcd.h dmotor.h dcc.h dsensor.h dsound.h lnp.h lnp-logical.h mem.h persistent.h powerfunctions.h remote.h semaphore.h setjmp.h stdio.h stdlib.h string.h swmux.h time.h tm.h unistd.h rom/lcd.h rom/registers.h rom/system.h sys/battery.h sys/bitops.h sys/dmotor.h sys/dsensor.h sys/dsound.h sys/dkey.h sys/h8.h sys/handlers.h sys/irq.h sys/lcd.h sys/lnp.h sys/lnp-logical.h sys/mm.h sys/program.h sys/time.h sys/tm.h sys/vis.h sys/waitqueue.h; do \
    install -m 644 include/$i /usr/local/brickos/h8300-hitachi-hms/include/$i ; \
done
[ -z '' ] || sed -i -r 's/^BASE1[[:space:]]*=[[:space:]]*0x[0-9A-Fa-f]{4}$/BASE1 = 0xad2c/' Makefile.user
[ -z '' ] || sed -i -r 's/^BASE2[[:space:]]*=[[:space:]]*0x[0-9A-Fa-f]{4}$/BASE2 = 0xaf3c/' Makefile.user
test -d /usr/local/brickos/share/bibo || mkdir -p /usr/local/brickos/share/bibo
install -m 644 kernel/bibo.coff kernel/bibo.srec kernel/bibo.lds BaseAddresses /usr/local/brickos/share/bibo
install: cannot stat 'BaseAddresses': No such file or directory
make: *** [kernel/Makefile.sub:32: install] Error 1

But while the error was a bit different than not finding a file, it still seemed to be an error ;)

gunner@HP-2000-Notebook-PC:~/brickOS-bibo$ firmdl3 --tty=/dev/ttyUSB0 boot/brickOS.srec
firmdl3: ERROR- failed to open boot/brickOS.srec
gunner@HP-2000-Notebook-PC:~/brickOS-bibo$
Gun-neR commented 2 months ago

Ahh... tired ;) But I remembered that this is a "new" install on a different system, so I had to go through the setup legousbtower0 rigamaroll.

But I have the firmware installed!! Yay!... No idea if it is the one I need for the IR demo. I will sleep first... zzzz

But, this is still not what I really need, as it is my RPi4 setup that I use for all other LEGO programming... This other laptop is toooo slooowww

Gun-neR commented 2 months ago

Well, I can't sleep without at least confirming a program can load and run...

And... Yes to the load, but NO to the run. At best, nothing happens, perhaps the word STOP shows if I hit the run button a 2nd time. At worse, the RCX locks up and I have to pull a battery, reload the firmware and try again.

I have tried a bunch of different programs in the demo/c folder, loading some in the 1st and 2nd program slots.

Tried a 1.0 and 2.0 RCX (I have a bunch) but same "Seems to load and acts like there might be something there, but nothing runs" results.

Now to bed :(

mesheets commented 2 months ago

The way BrickOS was setup, Make calls configure. Typically, when configure is present, one runs ./configure and then make, but with BrickOS a single make command does both. Not sure if it makes much of a difference manually running configure first and then make, but as only make needs to be executed, that is how I setup the GitHub Action.

Not listed here, but I recalled it from another brickOS instruction site - $ sudo apt-get install -y binutils-h8300-hms gcc-h8300-hms

As far as I have found in the distributions I have checked, Debian/Ubuntu is one of the few distributions (if not the only distribution) to include prepackaged h8300 tools. On a lot of other distributions, those tools will need to be built first. The Nix Package Manager is designed to work across different distributions and include nice isolation support for development scenarios, so it might be a nice "package once, use in multiple distributions" scenario, but there are not many contributors to RCX-related projects these days to help support such efforts…. I had also posted a message recently to the Debian Lego Packaging Team about possibly updating some of the Debian packages designed for use with the RCX, but I've yet to hear any response….

install: cannot stat 'BaseAddresses': No such file or directory

This error will eventually yield problems, even if an srec file was generated….

~/brickOS-bibo$ firmdl3 --tty=/dev/ttyUSB0 boot/brickOS.srec

I guess you found some documentation that apparently need updated, but I'm not sure where that firmdl3 is being sourced from (perhaps from the Debian brickOS package?). With the refactor of the host utilities that is part of the brickOS-bibo codebase, the firmware downloader should now be named just firmdl. That said, firmdl3 will probably still work with brickOS-bibo, but I'm wondering if there might be a mixing of the two environments going on that potentially might be causing some side effects.

mesheets commented 2 months ago

~/brickOS-bibo$ firmdl3 --tty=/dev/ttyUSB0 boot/brickOS.srec

…in addition to the firmdl3 question in the prior post, if building brickOS-bibo, I'm also not sure why the .srec file would be named brickOS.srec. In brickOS-bibo builds, the name of the .srec file should be bibo.srec (c.f. GitHub Action build log).

Gun-neR commented 2 months ago

Thanks for looking at this... FYI, aside from the h8300 tools I was following this forks README instructions, including the use of brickOS.srec (and firmdl3)

I still don't understand why I can seemingly load programs, but they do nothing... Unless the installed firmware from the whole process is incorrect (and not just in name).

I'll possibly take another stab at this later today.

mesheets commented 2 months ago

I have updated the GitHub Action to capture and post artifacts from the build run. It is now posting three different artifacts following a successful build:

For running on a Raspberry Pi, the installed file tree wouldn't work due to the processor difference, but the first two (.srec and .lx) would because those are targeting the RCX and have no dependencies on whatever the host platform might be.

While doing this, I was able to figure out the BaseAddress error that was appearing, and if you get the latest that is in the version control repository, I think that should be addressed now.

If it might be of use for testing, the initial developer behind bibo also created an RCX emulator called brickEmu. While it provides special support for brickOS-bibo, it should work with any firmware. A successfully-building GitHub Action also exists for this project, so it should hopefully be in a reasonably good state.

I have not specifically tested this, but I expect that the tools included in the Debian "brickos" package should be able to download both this latest .srec firmware and the .lx programs.

As to the state of documentation, those that are still involved are pretty much all doing so in what spare time they can find. Distributions can have their own specific quirks, so having something fully comprehensive was always a challenge to begin with, not to mention trying to keep up with new things that have since come along, such devices having ARM processors (like the Raspberry Pi). :-/ (Contributions welcome! 😉) Part of the hope with the GitHub Actions is that they will be able to provide somewhat of a "documentation by example."

I appreciate your ongoing engagement!

Gun-neR commented 2 months ago

Hello again. So, I downloaded and ran the "new" package on my RPi to test, and this time everything seemed to go OK? I can't tell anymore :) but no obvious errors.

However, I must have really pooched something with prior attempts, as I just couldn't get any firmware or programs to install (on RCX that already supposedly had a firmware)... I kept getting executable not found, or something like that with firmdl3 and dll even thogh I could see the file. Nothing that worked before was working at all, not even the formerly working WebPBrick, and I was at my wits end...

Dealing with disability due ME/CFS has me getting wiped out, all to often, and giving up on stuff out of sheer exhaustion, but I am trying one more time :)

This time I did a clean reinstall of my RPi's OS to the latest one as recommended by them.

NOW... before I try again on a clean RPI and/or my Linux laptop... Is this basically what I need to do to install and run your fork? (paraphrasing a bit here until I have a better idea, but I think these where the steps I last made, and seemed to at least install OK on the RPi... If I get this working I might be able to lay out some new directions for you to post??)

1 - git clone https://github.com/BrickBot/brickOS-bibo.git 2 - run make 3 - run make install 4 - perhaps do stuff to get the USB IR tower to work (not sure about the serial IR tower if it needs tweaking as well) 5 - use firmdl3 to load in bibo.srec (I noticed that it was in the util folder) or do I need to install the official BrickOS to get all that prerequisite brickOS.srec stuff first? 6 - use dllto load in programs

Thanks for sticking with me on this journey.

mesheets commented 2 months ago

With the brickOS-bibo source, a make install with no variable assignment arguments will install utilities such as dll, firmdl (without the "3"), ir-server, lnpmsg, etc. to a user space under /usr/local/bibo (so the path to firmdl would be /usr/local/bibo/bin/firmdl). Typically, a path like that probably isn't in the system path, so unless providing a path one of those when attempting to run, the system might not find it.

Variable assignment arguments to make install, though, allow both distribution package managers and users installing directly from source to specify where/how they would like the package to be installed on their particular distribution and for their preferred user environment setup. Back in the day, some apparently liked to keep the brickOS environment somewhat isolated, which likely accounts for the default /usr/local/bibo path prefix. (An install path like that would make removal easy—just delete the /usr/local/bibo directory and the whole installation is gone.)

If, however, one doesn't feel a need to keep the tools isolated and would like to interact with the tools in a more "normal" fashion, a prefix variable assignment argument could be supplied to make install like as follows:

A list of supported installation variables is towards the top of Makefile.common and allows package maintainers to really fine-tune an install for their particular distribution, but most folks probably don't need to explicitly define special paths for everything. With the prefix=/usr variable assignment argument, for example, some of the common subfolders would be installed as follows:

All of the above to say, if your steps down through make install (or make prefix=/usr install) work successfully, you should be able to just use firmdl and dll from the build and not have to worry about trying to use firmdl3 and dll from the Debian package.

The USB IR tower is a bit of its own entity, but those details are more specific to the given distribution that to software packages brickOS-bibo. The Linux kernel does include 64-bit drivers for it in its source, but whether that driver was configured to be included in the kernel build and/or how to include that driver if it was built as a module that is published separate from the kernel varies depending on the distribution used. It can be made to work; it's just a matter of determining how a particular distribution was build to handle/manage drivers. Ideally, if your chosen distribution hasn't already included the driver with its default kernel build, it has made it available as a module that can be added.

The RCXTTY environment variable should still be supported for declaring the default IR tower device that your particular system uses, so that the device does not need to be specified with each command. (NQC uses the environment variable RCX_PORT; ultimately, I'd like to align all these various RCX programs so they can all share a common, unified setting.)

Gun-neR commented 2 months ago

OK... for the record... I have successfully installed this onto my RPi4, and it seems to work (was a hassle getting the tower functional, but that was mostly me being wiped out by this time). Anyhow, I have been able to transfer the firmware and test out several demos on multiple 1.0 & 2.0 RCX bricks.

Unfortunately :( The one and only demo I really wanted to see working, and eventually dissect to work out how to use it's control features for my own code, powerfunctions didn't seem to do anything at all with my IR receiver!!! But it did show on the screen as going through some motions on the RCX, so that was better than anything in the past with this particular demo. Who knows why this demo didn't work, but the one that led me on this journey did?

I had based my entire approach here on a "self contained executable demo" (AKA, something I couldn't edit without recompiling, and doing so on a brickOS fork that supported IR functions; Thus ending up here) from Bob Kojima - https://www.bong69.com/site/pages/software.php - Power Function on the LEGO RCX (found at bottom of page).

Anyhow... I have tried, but couldn't figure out how to compile a *.c to *.lx (by now the typical brain fog rolled in and will probably shut me down for days, weeks or more) and besides, I am unsure if it even matters at this point.

So I think I am finished this journey, but must call it a failure with some minor benefits; As in that I managed to figure out a thing :) and supply some confirmation on the steps that now work on an ARM based device, thanks to your (mesheets) efforts and assistance.

I sincerely Thank You!

My hardware & OS: RPi4 Raspberry Pi OS with desktop Release date: July 4th 2024 System: 64-bit Kernel version: 6.6 Debian version: 12 (bookworm)

The steps I used: 1 sudo apt-get install -y binutils-h8300-hms gcc-h8300-hms 2 git clone https://github.com/BrickBot/brickOS-bibo.git 3 cd brickOS-bibo 4 make 5 sudo make install

Fiddle around to get the USB tower links setup: My records got messed up here, so I will leave this to be Googled, but any application for RCX should have some references to follow.

Load firmware: /usr/local/bibo/bin/firmdl /usr/local/bibo/share/bibo/bibo.srec

load demo: /usr/local/bibo/bin/dll ~/brickOS-bibo/demo/c/{demo name}.lx

mesheets commented 2 months ago

Glad to hear of some progress!

I'm pretty sure I know exactly what is going on with the PowerFunctions demo. As you probably know, the RCX has a limited amount of memory, and the larger BrickOS is, the less memory is available for user programs.

Some behaviors and features of BrickOS can be enabled or disabled through the #defines in the file ./include/config.h. In that file, the #define for CONF_POWERFUNCTIONS is currently disabled. If that line is uncommented, the PowerFunctions capabilities will be built into brickOS-bibo and the PowerFunctions *.lx demo will then actually do something.

It is possible to create new C programs and compile them to *.lx files. However, given the scope of your purposes, at least for starting out it might be easier to just modify one of the existing demo programs to suit your purposes.

As all of the demo programs (such as powerfunctions.c) are automatically built as part of the larger brickOS-bibo build, so you could optionally just edit that to your liking. Then, when executing make again, it will not only generate the brickOS-bibo firmware, but it will also compile any edits to the demo programs, too.

I'd be happy to try to walk through creating new C files if you'd like, but by beginning with demo modification approach, it is easier to take more incremental steps and verify along the way that things are still working.

Thank you also for passing along the link to the PowerFuctions on the LEGO RCX program—I'm always on the lookout for RCX-related content, and I had not come across this before.

In looking at the contents, it appears to be based on brickOS but conveniently has everything already pre-configured and pre-built, so if you did need to tweak any of the behavior, it should be possible….

mesheets commented 2 months ago

…PowerFunctions should now be enabled in the source in the repository.

Gun-neR commented 2 months ago

Some behaviors and features of BrickOS can be enabled or disabled through the #defines in the file ./include/config.h. In that file, the #define for CONF_POWERFUNCTIONS is currently disabled.

Yup, that would get in the way :)

Unfortunately (again) it seems that powerfunctions.lx demo program doesn't even actually load (but doesn't throw any error)???

When supposedly "running" the demo, I had been hitting the VIEW button as required and getting ADR and various numbers as I kept pressing, thinking this was referring to the IR receiver address and what not, as per the notes in the demo file. But always getting NONE when pressing RUN or PRGM.

Then, while working on a differnt RCX that I had just loaded in the firmware, but no program, and I accidently pressed VIEW and got same results??? Some Googling later shows this is a function of BrickOS firmware; showing LNP (??) address of the brick, free memory and battery level... DOH!!! All alone I was being totally misled in my past diagnosis... Yep, happens a lot ;)

As all of the demo programs (such as powerfunctions.c) are automatically built as part of the larger brickOS-bibo build, so you could optionally just edit that to your liking. Then, when executing make again, it will not only generate the brickOS-bibo firmware, but it will also compile any edits to the demo programs, too.

OK... So now that I have an idea how to modify and compile the existing demos (I experimented with helloworld.c) I need to find out why the one demo I want to experiment with doesn't even seem to load, or load properly?

Also, how do I add in a completely new *.c program and get it compiled? I tried, but it didn't seem to work.

And finally, on a possibly related note... when I run make, I still see the "Esterel compiler not found" message (I can't remember if that is normal?) But more concerning, it stalls out after >xsout written without returning to the prompt. And if I don't force an exit, in a few seconds it will lock up the entire RPi, requiring a reboot.

pi@RPi4:~/brickOS-bibo $ make
demo/esterel/Makefile.sub:14: Esterel compiler not found; skipping Esterel programs
[ -z '' ] || sed -i -r 's/^BASE1[[:space:]]*=[[:space:]]*0x[0-9A-Fa-f]{4}$/BASE1 = 0xae6c/' Makefile.user
[ -z '' ] || sed -i -r 's/^BASE2[[:space:]]*=[[:space:]]*0x[0-9A-Fa-f]{4}$/BASE2 = 0xb07c/' Makefile.user
cd xs/lisp && ../xs-rcx < ../../demo/xs-lisp/fact.lsp
Welcome to XS: Lisp on Lego MindStorms

>xsout written
xsout written
>xsout written
>xsout written
>Killed
make: *** [demo/xs-lisp/Makefile.sub:37: demo/xs-lisp/fact.o] Error 137
pi@RPi4:~/brickOS-bibo $
mesheets commented 2 months ago

The Esterel warning is fine, as there is not an Esterel binary for ARM-based devices like the Raspberry Pi. On top of that, it doesn't appear that Debian has a package for that. I updated the warning message to note that what is being skipped is Esterel demo programs.

The hanging during XS is a different issue. It's possible there might be a yet-unidentified incompatibility with XS tools running on ARM processors. With there being a failure during the build process, I can't be sure of the state of either the firmware (.srec) file or the program (.lx) files. Running make realclean should clean up the environment and remove all files generated by a build attempt.

how do I add in a completely new *.c program and get it compiled? I tried, but it didn't seem to work.

Good question…. At the present, the process involves manually adapting and using the Makefile installed by make prefix={YourPrefixPath} install under the "share" folder. Consequently, though, that requires an understanding of how Make and Makefiles work. For folks just looking to tinker with an RCX on the side, that perhaps poses a bit of a barrier to entry.

In looking at this a little closer, I think it might be possible to simplify this further by wrapping all of the necessary details in a command or shell script so that end users don't need to worry about all the Make-related details. Would need some time to implement, but I'm thinking perhaps something along the lines of the following for building a single user program:

While that doesn't offer everything that a Makefile could do (such as building multiple different user programs at one time), I think that should work for most users in most cases. If someone wants a more sophisticated build setup, they could still either chain multiple calls to the simple command or create their own Makefile adaption, so it's not like any functionality (even if marginal) would be lost.

Does that sound like it would be a littler easier to manage? As noted, some time will be needed to update brickOS-bibo to support that, but given the benefit, it might be worth it. For starters, it would probably only work for user programs written in C or C++; further work would be needed to support user programs written using Esterel or XS:Lisp.

Gun-neR commented 2 months ago

Running make realclean should clean up the environment and remove all files generated by a build attempt.

Thanks for that... I was getting confused with all those *.dc* etc. files while trying to determine what possible extra files I was supposed to have, along with *.c test files that I was trying to compile. As is, I am still not sure what feature.c files might be referring too? Perhaps libraries imported in the main *.c file?

Does that sound like it would be a littler easier to manage?

Honestly, yes... whatever can be done to make these old yellow bricks a bit easier to keep relevant is appreciated. While I do have experience with Arduino code, which I believe is closely related? Even making my own. But I am more a copy/paste programmer, if programmer is even the proper description :) Figuring out others code and with trial and error, much error, making it work for my needs.

I have taken a short break on this RCX IR control project... It was getting too overwhelming. But it is still something I want to continue with, and will help in whatever capacity I am able to here.

I am basically trying to use RCX to do what I currently can do with a more costly Mindstorms HUB, as shown in this YouTube demo of mine (but eventually on a larger, more automated scale, with sensors and automated switch tracks etc.):

https://youtu.be/MzR8HeodX3o