[Bug] Motors with rotation sensors don't work about brickrail

[Novakasa]

Are you seeing this with motors used in switches? Do other motors work fine for you? I am using L-motors and 88008 motors as well as Spike prime motors for switches and they work fine for me. I haven't tested non-train motors on trains yet though. But I didn't have an issue with using the DCMotor class for motors with encoders up until now.

Can you post the logs as found here?

Windows: `%APPDATA%/Godot/app_userdata/brickrail-gui/logs`
Linux: `~/.local/share/godot/app_userdata/brickrail-gui/logs`

Also which pybricks firmware version are you using? The releases come with firmware binaries in release/firmware in case a pybricks update breaks some things.

Using the rotation sensor to track a specific speed is definitely something to look at, but I would need to think about how to integrate it with the marker speeds. I am currently using marker speeds to compensate for the fact that a train needs more power to go up a hill and less to go downhill, but if the train has a rotation encoder it will behave differently in these cases.

For experimenting with the python programs, you should be able to just modify the files in the release/ble-server-<platform>/hub_programs folder and a restart of brickrail should detect the change and download the new program to the hub automatically (hopefully, please report if this doesn't work). For trains, only the smart_train.py file is actually used as well as the layout_controller.py

A dev environment may be setup something like this:

• Download Godot 3.X and open the project brickrail-gui/project.godot
• Create a python 3.10 environment in .env/ and activate it (I am using anaconda for this, which might actually be required, not sure there)
• install the dependencies in requirements.txt via pip install -r ./requirements.txt

[Novakasa]

Confirmed with new pybricks firmware, I will ask upstream whether that is a regression or intended.

https://github.com/orgs/pybricks/discussions/1364

[Novakasa]

This was confirmed to have been unintended behaviour from the beginning, so I added the try except block to account for it. Thanks for reporting!

[iragm]

Thanks for the help! So far, I have determined that the pybricks firmware v3.3.0b4-6-g7aca502e bundled with brickrail works fine. Something about the current version doesn't -- not sure if this is a regression in pybricks or a deliberate change. I am still in the process of setting up a layout and seeing what works and what doesn't, I will continue to experiment with this over the next week and report back on how things go.