It’s been a while since our last update. This is the project that was presented here, and it was separated to two topics, the mechanical and the electronics part. Here we will present the first version of the PoppyUPC platform (new name, no more Poppy_Essaii).
As a reminder, the idea was to modify cheaper RC servos to make them at least as good as the Dynamixel in order to reduce the price of the Poppy Humanoid robot. The main goal was to create a platform that can be used to study bipedal walking algorithms and for that reason, only the lower part of Poppy Humanoid was considered (two legs). Even though our hope was to try also to make the platform walk, it was impossible to achieve that due to lack of time.
The motors that were modified are from Hitec and more specifically the model HS-7954SH. All the original electronics parts were removed and a new PCB board was designed in order to host a motor driver, a magnetic encoder (position sensor) and an arduino micro-controller (uC). The result is shown in the next photo (the magnetic encoder is on a “daughter” board that is mounted underneath the “main” board that is shown),
Some details about the parts of the control system of each motor.
The driver can output up to 8A (more than enough), undervoltage shutdown, thermal shutdown, cross-conduction protection and most important, a current sense output. Therefore, with that choice, we already have one feedback signal from the motor. The driver also provide two diagnostic pins to inform the user which of the protections was activated.
The position sensor is the second feedback signal. The magnetic encoder is the AS5145 from AMS and I think is the same as the one that Dynamixel motors are using. Even if it’s not, it also has 12bit resolution (4096 ticks - 0.088 degrees). This sensor needs a magnet to be placed on the output shaft of the gears system. The original system had a potentiometer to read the position that it had to be placed in the same manner. It was easy then to just print a small piece with the same shape as the potentiometer and place the magnet there.
Finally to interact with the driver and the sensor, an arduino (UNO) uC was embedded. The reason of that choice is obvious. The community and the knowledge base of the arduino it will attract more users. We did a small modification here too. We used a 20MHz crystal instead of the standard (for UNO) 16MHz one, in order to boost by 25% the speed of the controller. As in most cases of engineering, there was a trade-off to achieve this as it will be explained later in the communication part. To read the encoder, the spi port was used. This resulted to a reading that last just 60us - quite fast. A timer’s output is producing the PWM signal for the driver, and two GPIO pins control the direction (or braking) of the motor. An analog pin is used to read the current sensor of the driver. Finally two more GPIO pins were used to read the diagnostics from the driver.
What’s the point to have an arduino embedded to your motor if you are not able to re-program it. This feature that we wanted to include is what we think the biggest advantage over the Dynamixel motor. It was also the decision factor of which type of communication to use. The choice was between the I2C port and the UART port. To upload a sketch though, you can either use an ISP programmer or a FTDI programmer. The ISP needs 4 cables for that when the FTDI 3 cables and a bootloader. Since the amount of cables that go out of the motor is huge issue, the UART+FTDI option was chosen. But since we are using a 20MHz arduino , a new bootloader was needed.
So in the end, with the addition of a new bootloader and a new board entry in the arduino IDE, the user is able to upload sketches to the motor the same was as it uploads sketches to the arduino UNO board. Just click the upload button. Both the rx and tx pins are exposed as well as the reset pin that is needed during the uploading process. The only external hardware that is needed is the FTDI programmer. In the following photo is shown a typical choice that was bought from the local electronics store for 5 euros.
This chip connected to the PC with a USB cable and with one motor with rx/tx pins results in a typical PC-usb-arduino configuration. Which means that the user can also use the serial terminal of the arduino IDE.
To add all the motors on the same network, the RS485 protocol was used. The maximum baud rate though is at 500000 bps (compared to the 1Mbps of the Dynamixel motors). The reason for that is the 20MHz crystal (the trade-off we talked about at the electronics part. A custom library (basically not a library just a couple of functions) was used to handle the incoming and outgoing data in a proper (for the control loop) way. With this ‘library’, if the user is not interested to upload a sketch again, it can use the same configuration as the dynamixel motors (rx and tx pins connected to each other) without any additional external hardware (buffers, NOT gate etc) and of course the USB2Dynamixel adapter.
The following image shows the comparison between the two motors.
One of the disadvantage of the modified Hitec motor compared to the Dynamixel ones, is the number of cables. The Hitec motor needs 6 cables in total (7.5V, 5V, GND, Rx, Tx, Rst) compared to the 3 from Dynamixel. The 5V cable is there because of lack of space on the board to place a voltage regulator. In the future version of the board though, there will be a regulator so overall in total it will be 5 cables. The Rx and Tx pins are used for the communication between motors and along with the reset pin for uploading new sketches.
As for the performance, both motors can produce similar torque but the advantage of the modified Hitec motor is that the user can upload its own controller such as, optimal controller, H-inf etc. Of course, due to the lower supply voltage, Hitec will need more consumption than the Dynamixel.
Various controllers were designed for the motor. Starting from simple PID controllers either for position or velocity control. An observer was also designed to ‘observe’ the states of the motor (velocity, current) instead of measuring them (noisy signals). Finally, a colleague used a disturbance rejection observer to close the loop and control the position of the motor.
Main Computer Unit
The main computer unit was chosen to be an Odroid-C1 but the system was also tested with the XU4 model. The main reason for this choice (instead of Raspberry Pi) is the easy to install (and use) ROS. I have been working with ROS on Odroid during the last year and I have seen no difference with the ROS installation on my desktop computer. As it well known, both Odroid boards have two exposed UART ports on their pins. Because of that, the user has various options of how to connect the motors to Odroid. Someone can connect the motors of one leg to the first Odroid port and the motors of the other leg to the second port (it will loose the option of uploading sketches though) reducing the load of the lines to half. Or he can connect all the motors to a USB port of the Odroid board through an FTDI chip, install arduino IDE on Odroid, and communicate and upload sketches with the same configuration (even remotely- ssh). With this last configuration, he can also connect the motors to a desktop pc by just taking the usb cable from the odroid and use it on the pc.
A ROS package was created in order to communicate with the motors. In fact this package is using a C++ library (also created by us) that is responsible for the communication, and it uses the ROS ‘benefits’ to publish all the information in ROS topics. Any other ROS package can then subscribe to this topics connecting that way the platform to the ROS world.