I recently received a Solo12 kit from PAL and I am proceeding with a preliminary test of the motors with the master board and drivers. I followed the guide on the site as suggested by the repo. I have completed all the steps correctly until the last one, in which it fails to flash hello_world. Obviously, the problem then is not related to hello_world but in general to flash what you need. I attach the output of the terminal related to the error.
(Mine is an ESP8266, but I saw it works in the flashing repo)
I’m not sure to understand what you are trying to do.
The flashing instructions are for reprogramming the MasterBoard in case of update. The MasterBoard is based on a ESP32. PAL should have provided you with a programmer for this, wich is a repurposed esp8266 dev board that is to be connected to the master board during flashing. Note that PAL is selling MasterBoard with the latest firmware already flashed, so you probably don’t need to do anything on this side.
If I understand correctly, the error you are getting is because you are trying to flash your own esp8266 with a esp32 program.
I hope this helps to clarify,
Do not hesitate to ask questions here about your setup.
Good morning Thomas and thank you very much for your quick reply.
Sorry in advance if I’m making any gross mistakes, but it’s my first time interfacing with this part.
Anyway yes, I received as you can see from the picture below (sorry for the poor quality but I’m not in the lab right now), both the masterboard and the ESP8266 in a sealed package, so I thought I should first flash the ESP8266 with these steps found on this site and then connect it to the masterboard to perform these instructions.
Again, sorry again for the irrelevant questions probably.
Ok I understand better now. So in fact we only use the USB chip from the esp8266 dev board. You need to desolder the esp8266 module and install wires instead that will go to the MasterBoard program port. I was expecting that PAL would have performed this task before shipping.
You can see details of the wiring on The GitHub instructions of the Master board.
Until today I had not had a chance to continue with the master board flashing process. I proceeded to desolder and solder the esp as in the attached photo, unfortunately, I can not complete the flashing process.
Do you have any suggestions? If not, I’ll try contacting PAL to see if the master board was already flashed, although since I received the ESP module I don’t think so.
I’m not sure about the errors you are getting,
however, from the picture, I can see that the WS2812 RGB LED is on, this can only happen if the board has the firmware running, so I would say you don’t have to reflash it.
Also, I see that you powered the masterbaord from the 5V of the USB. This is handy to quickly flash the board, but I realized that on some board, 5V is not enough to power the board. You can use instead any DC supply below 40V. On the robots, we directly use the 24V DC bus.
This can not explain the second error that is a compilation error.
Thank you for your prompt reply. I contacted PAL and asked them if they had any info, maybe as you suggest the master board has already been flashed.
Anyway, we will try to supply power as you indicated via a DC supply below 40V.
Thanks again, I will give you feedback via this thread.
Thank you very much. As I told you, I wrote to PAL and they told me that the master-board should already be flashed. We are now able to provide power to the drivers and the master-board.
We are not very experienced with low-level implementations on hardware, so we would like to know how to proceed to do some preliminary testing on the 12 motors.
Our idea was to communicate with the master-board via Ethernet and try to run an initial control command to see the motors moving, but we don’t know what kind of preliminary setup is needed on our OPC to communicate with the master-board. Could you suggest us a step by step procedure, starting from the software on the OPC to how to run the scripts needed for the preliminary tests.
We have now switched to GitHub - open-dynamic-robot-initiative/odri_control_interface: Low level control interface, and we have managed to complete the installation but we cannot run the python demo script. I attach the terminal, it seems that the libodri_control_interface_pywrap module is missing (although the libodri_control_interface_pywrap.so file is present in the devel/workspace/build/odri_control_interface folder).
Sorry for the long delay. @nim65s might help you with the installation issue.
About the torque control, the motor can be commanded in pure current control (torque control without torque sensor) and also in position and velocity.
The control low implemented in the motor controller is:
Iq = Iq* + Kp x (p* - p) + Kd x (v* - v)
With Iq the motor current (similar to torque due to transparent actuation)
Iq* the “feed forward” reference current
Kp the position gain (stiffness)
Kd the velocity gain (damping)
p*, v* the reference position and velocity
p, v the measured position and velocity
By setting Kp and Kd to 0, and only sending Iq*, you will command your motor in pure torque. You need to generate those torque with a higher level controller. Such as inverse dynamic, or whole body MPC.
Only sending torque is challenging though since the bandwidth of the actuation is high. In practice we usually keep some feedback at the low level.
If libodri_control_interface_pywrap.so is present but your python interpreter can’t find it, that’s because its sys.path is not configured with the folder where the lib is.
You could workaround this by adding devel/workspace/build/odri_control_interface to your $PYTHONPATH, or cleanly fix this by installing the project, and then adding the python site lib path (eg. something like $YOUR_PREFIX/lib/python3.8/site-packages or $YOUR_PREFIX/lib/python3/dist-package) to your python path if it is not already there.
I think the issue is that odri_control_interface python module can’t find eigenpy python module.
Keeping the same PYTHONPATH, can you try python -c "import eigenpy" to check if this works or not in your particular case ?
In any case, in a clean ubuntu 20.04 docker, creating a colcon workspace with eigenpy, master-board and odri_control interface is working, but only with colcon build --cmake-args -DPYTHON_STANDARD_LAYOUT=ON. After that, a source install/setup.bash provides a correct PYTHONPATH that fix this unreported exception issue.
Regarding the second question, I just followed this installation process.
For eigenpy I maybe did not complete well the whole setup before running demo_solo12.py, but I have no idea of what I should do to be sure that all the required packages are fixed.
Ok, if python3 -c "import eigenpy" works but not python -c "import eigenpy", you probably don’t have the python-is-python3 package. Then, I guess your configure and build process used python 2 by default instead of python 3, and if that’s the case, it could explain a lot of things.
I would suggest to sudo apt install python-is-python3 and start again (from your workspace, rm -rf build install then a new fresh colcon build)
