I’m trying to use the FSM walking controller example supplied in the latest version of OpenSourceLeg on GitHub. When I run it, I get the ValueError: State machine isn’t active.
From what I can see (screenshot attached), the encoder communication is trying to open /dev/i2c-3. However, when I check available I²C buses, I only see i2c-1, i2c-20, and i2c-21. In order to overcome this issue, I tried adding an overlay (i.e. dtoverlay=i2c3) to the /boot/firmware/config.txt file, but it didn’t change anything.
I have not been able to run the supplied tutorial to read encoder data either. Besides that all motors and connections are working fine and I could run the basic motion script without issues.
Also, I have tried using the opensourceleg v2.3.0, in which version I can get the FSM_walking_controller.py (found in the legacy branch of the OSL Github page) to start running without errors, however ideally I would want to continue development using the latest version of the OSL (v3.4 if I am not mistaken).
Has anyone encountered this issue before or know how to get the encoder communication to use the correct I²C bus or any suggestions for the FSM walking controller to be functional and what could be the issue?
I wrote the explanation myself, but I used ChatGPT to help me style and polish it so it’s clearer:
The error appears because the with osl … block executes and tries to establish communication with hardware devices. Since the code is configured to talk to AS5048B encoders on buses /dev/i2c-2 and /dev/i2c-3, but those buses don’t exist on your system, initialization fails. As a result, the FSM can’t start properly and you see the error “State machine isn’t active.”
There are two main ways to address this:
Use virtual encoders
If you don’t have real AS5048B encoders connected, or just want to confirm that the problem is software-related, you can replace them with the VirtualEncoder class. This bypasses hardware I²C communication and lets you test whether the FSM logic itself runs correctly.
Use the correct I²C bus for your hardware
If you do have AS5048B encoders, you need to tell the software which bus they’re actually on.
On a Raspberry Pi, the default I²C bus is usually i2c-1.
If you’re using a custom board or a cape that exposes additional buses, the encoders might be on something like i2c-20 or i2c-21.
The example code uses i2c-2 and i2c-3 because that matched the developers’ reference hardware setup (two separate buses for knee and ankle encoders).
So in practice, you’ll want to run i2cdetect -y <bus_number> on each available bus until you find your encoders, and then update the bus parameter in the code accordingly.
Finally, it’s a good idea to go through the “common issues” steps in the encoder tutorial (permissions, group membership, I²C enabled in config, etc.) to eliminate those potential problems too.
If it still doesn’t work after correcting the bus paths, please share details of your hardware setup (which encoders are wired, to which I²C pins/buses) so we can dig deeper.
It seems that in my setup, both encoders are actually connected to I2C bus 1, which explains why i2c-2 and i2c-3 could not be found. I tried changing the parameters accordingly in the code, but the State Machine still would not start.
Upon testing the encoders, I was able to read the ankle encoder separately on I2C bus 1, but was not able to establish a connection with the knee encoder. Eventually, I discovered that two of the knee encoder cables were disconnected.
As for the older version of the FSM, it seems that this code was using only the motor encoders (USB communication), same as the basic motion script. This explains why I was able to run these scripts and not the current FSM controller, which relies on the joint encoders rather than the motor encoders.
Appreciate your guidance — it pointed me in the right direction to debug the problem!
