We recently received our Solo12 from Pal Robotics. We aim to use it to test our control algorithms. I am currently aiming to send torque commands to motors and read sensor information using the solo package in the odri github page.
I downloaded and installed the software (as described in the readme of the solo package) on an RT-patched Raspberry Pi 4 and tried to run the demo. I am receiving an error saying “assert fd!=1 failed”. This is at line 131 of https://github.com/open-dynamic-robot-initiative/master-board/blob/master/sdk/master_board_sdk/src/Link_manager.cpp.
I know that the problem is not with using Rasperry Pi, because I tried to connect to the robot with my laptop after installing the master-board library, and I get the same result when I try to run the example in the master-board. I think the problem is about connecting to the master board. Note: I am connecting to the robot using an ethernet cable only. I had to change the “does_not_matter” to “none” to avoid using SerialReader in line 175 at https://github.com/open-dynamic-robot-initiative/solo/blob/master/demos/demo_solo12.cpp
I had assumed the master board was flashed already by Pal Robotics. The LED on top was blinking green. There was another LED blinking red on the other side of the board.
Also saw someone wrote that it comes flashed in the forum. Yet as described in the github page, I downloaded the flashing program, I ran “make monitor” yet, received an error saying I need to flash first. I was able to run “make simple_monitor”, yet there was no traffic between the master-board and my computer. The LEDs and the fact that I bought the robot from Pal made me think that I don’t need to flash the master-board. Or should I?
In the documentation it says that the software communicates through MAC adresses. I have not set or changed any of the MAC adresses in the code. Could this be causing the problem?
I am very excited about using the robot. I would be very happy if you could share insights and help me get the robot running.
We, as a team, are facing with similar problems. We tried a lot but couldn’t find the reason. Any ideas on what might cause this? We would be happy if you could help.
In case you’re not already doing this, try running the demo with sudo. There is some part in the communication that requires root permissions (I’m not sure which part exactly, so there might be a nicer solution than simply running the whole thing as root but if so, I’m not aware of it).
Sorry for the does_not_matter issue. There was a change recently on how the slider box port is configured and I apparently didn’t update it everywhere. As you already figured out, “none” can be used to disable it. If you have a slider box and want to use it, you can set “auto” instead to automatically detect the port.
I have already tried with sudo . I was able to connect to the master-board using make monitor, after cpu-init it just printed meaningless stuff. I checked the ethernet connection with Wireshark and I saw a message coming from Espressif and a message is sent when I start the code (just before it gives timeout error)
So, I have all the more reason to believe the problem is about the master-board-sdk. I am trying this on Ubuntu 22.04, if that could be of importance?
Or is there anything that comes to your mind that might break the connection?
correction: when i run the code in sudo mode the error i receive is
Timeout while waiting for ack.
Masterboard timeout detected. Either the masterboard has been shut down or there has been a connection issue with the cable/wifi.
I assume you already double-check that the network interface you specify is correct (I think specifying a wrong interface would result in a connection timeout)?
Apart from that, I saw that there were some updates in the master board repository recently, so maybe you need to update the firmware on the board to make it work with the latest version of the SDK (or alternatively, try with an older version of the SDK first). @thomas.flayols might know more about this.
Hey, not sure if you resolved it, but anyways I think it’s good to have written solution.
I had exactly the same issue.
The MCU was flashed by PAL and robot was delivered to me later. I downloaded latest master-board, but couldn’t connect. The solution that worked for me is to revert master board to previous commit.
Namely I ended up using master-board on this commit