Overheating of motor control boards

Hi,
what temperature of the motor boards should we expect? When running the solo with 24V, the motor boards reach up to 55 degree C even when not in motion. Referring to the picture, it seems to be the voltage regulator that is sweating.


Using a lower voltage like 13V reduces the heat generation a lot. As they are stacked on top of each other with minimal air flow in between, the bottom boards probably reach much higher temperature. Is this something we should worry about? We are facing SPI connection issues one motor board and we are wondering if this might be a temperature problem or something else.
Thanks

Hi,

I don’t have a measurement for the temperatures. That said, we had the solo12 running for quite some time now without problems.

We are facing SPI connection issues one motor board and we are wondering if this might be a temperature problem or something else.

What exactly happens? Do you observe SPI errors send from the motor board or is the master board missing to receive the SPI packages in time and sends zeros?

Best,
Julian

Hi Thomas, thanks for the response.
We see that the motor board is getting quite hot just when connected to power after a few minutes, even without any operation. This is easy to feel when touching the motor board. The temperature is such that you cannot touch it for more than few seconds. We wonder if this is the same with your motor boards.

The master board recognizes an error code 0xf of one of the motor boards every few seconds. This error code is then read by the master board’s sdk and monitored. The error seems to become more frequent after a while of robot in operation.

Many thanks!
Ferdinand

Hi Ferdinand,

The master board recognizes an error code 0xf of one of the motor boards every few seconds.

we ran into a similar problem when running the solo12 here in New York. We didn’t had the problem in Tübingen.

To work around this, I ended up reducing the speed of the SPI communication from 6 to 4 Mhz. This resulted in reliable communication without the communication error. See also the thread about the debugging here: Make communication more robust by jviereck · Pull Request #82 · open-dynamic-robot-initiative/master-board · GitHub

To reduce the speed, instead of flashing the firmware with make flash, you have to call make menuconfig first. Then, find the menu for the speed and change it from 6 to 4 Mhz. I don’t have a PC at hand to tell you the correct submenu right now - sorry.

Once you change the speed, you have to flash the new firmware settings via make flash.

With these settings, we are able to run a stable communication since a few weeks now.

Hope this helps.

Best,
Julian