Balboa 32U4 robot I/O error

[fluerasil5612]

I recently purchased a Balboa32U4 robot and assembled it. I mounted a Raspberry Pi 4 on top and got it to balance with Pi as extra weight.
I then tried shifting the balance algorithm to Pi, utilising I2C communication, where Pi is master and the A-star board is slave device. I used pololu-rpi-slave library on github, balboa branch. I get the error: OSError: [Error no.5] Input/Output error, for read_unpack of encoders in a_star.py

I made the following changes to the original code in github:

1. I2C bus speed = 400 kHz
2. angle = 70 at rest, as I used the bumper cages at 20 degrees incline
3. Slave address changed to 21, out of the three available- 1, 20, 21

How can I debug this problem? Thanks!

[fluerasil5612]

Just a small follow-up:
I seem to have mistaken the 3 i2c buses as slave address. I corrected it to its original value of 20.
I also reset the i2c bus speed to standard mode of 100 kHz.

[PatrickM]

Hello.

Do you get the same result if you use the unmodified programs from our library (BalboaRPiSlaveDemo.ino for the Balboa control board and balance.py for your Raspberry Pi)?

Here are a few other things you can check:

1. Make sure you enabled I2C by following the instructions in this blog post under the “Part 1: Set up the Raspberry Pi” header.
2. Run i2cdetect to confirm that the Raspberry Pi and Balboa control board are communicating. Adafruit has good instructions for that here.
3. In the BalboaRPiSlaveDemo.ino program, try changing the pi_delay_us parameter in the creation of the PololuRPiSlave object according to the advice given in PololuRPiSlave.h.

- Patrick

[fluerasil5612]

Hi Patrick!

Thanks for suggesting the above. Here are my results-

1. Yes, I followed the instructions in the blog post to setup i2c
2. I2cdetect can confirm raspberry pi 4 and ATMega32U4 MCU control board are communicating. The address is 0x14 or 20. There are two more addresses I can see- 0x1e and 0x6b.
3. I tried changing pi_delay_us parameter according to suggestions in PololuRPiSlave.h. I tried values of 5, 10, 8, 15, 0, 20

The result is that I still get OSError: [Errno 5] Input/Output error

-Som

[PatrickM]

We are going to try testing this ourselves next week to see if we get the same behavior. First though, just to confirm, do you get the same result if you use the unmodified programs from our library?

- Patrick

[fluerasil5612]

Thanks Patrick!

Yes, the result is the same when using the unmodified program. I have set the baudrate of the Raspberry Pi at 100kHz, and due to CPU scaling, the pi_delay_us is set to 20.
If it could be of any help, I attached a screenshot of the python script to call forth the functions described in balance.py.

Som

[PatrickM]

We tried to replicate your setup today and were not able to reproduce the same problem. Can you run the following commands and let us know what your Raspberry Pi outputs:

cat /proc/device-tree/model;echo 
cat /etc/os-release
sudo cat /sys/kernel/debug/clk/clk_summary|grep i2c
apt-cache policy python3
apt-cache policy python3-smbus

Also, could you post some pictures of your setup, including close ups of both sides of the Balboa control board (which will mean temporarily removing the Balboa control board from the chassis)? In particular, we’d like to check the soldering to your header for the Raspberry Pi.

- Patrick

[fluerasil5612]

Hello Patrick,

It is surprising to learn about this. I have taken a screenshot of the results of the commands you suggested to try out. Unfortunately, I cannot remove the Balboa control board off the chassis currently, but I can assure that the soldering for the Pi’s 40-pin header was done properly. The example programs of blink.py and benchmark.py return expected results. The problem lies when I try to run Balancer.py, a custom program to call the function methods of Balancer from balance.py.

[kevin]

Hello,

We did some more testing here, including trying to match the exact OS version you’re using, but we were still unable to reproduce the problem. It also seems strange that your program is not working for you when the examples like benchmark.py are fine. Can you try running the unmodified server_balboa.py program to see if that works?

Does your Balancer.py contain exactly what is shown in your earlier post? If not, could you attach an updated version?

Finally, could you try changing the I2C frequency on your Raspberry Pi back to 400 kHz (and verifying it with sudo cat /sys/kernel/debug/clk/clk_summary|grep i2c), then loading the BalboaRPiSlaveDemo program onto the Romi again, making sure that the .ino program and all of the Arduino library files are unchanged from their original state? (You could use git to verify that there are no changes or redownload the library to be absolutely sure.)

Kevin

[fluerasil5612]

Hi Kevin,

Thanks for reaching out. I tested the unmodified server_balboa.py program and it works fine.
I want to share that I found what could be the solution to this problem.
In the unmodified Balancer.py script shared in this post, the troublemaker was the last line in this code snippet:

def main():
  balancer.setup()
  balancer.start()
  balancer.update_loop()

Upon observing the balance.py script, I find that update_loop function is performed by a thread defined in balancer.start() method. Perhaps calling it again explicitly caused the problem.
I made small corrections in the code, ensuring that the thread continues running:

def main():
  balancer.setup()
  balancer.start()
  while True:
    try:
      print(balancer.isbalancing) # a placeholder to ensure thread keeps running, any other program instruction works
    except KeyboardInterrupt:
      break # exit from while loop

if __name__ == "__main__":
  main()

However, I will try your suggestions using the unmodified Arduino .ino file from github, and setting the I2C bus speed to 400kHz.

-Som