This week started with one meeting with professor Miguel Oliveira.
During the meeting some ideas were discussed, and some work was pointed out:
- Make an URDF/XACRO file to define the platform.
- Introdution to the ROS packages to the camera and pan and tilt unit (these packages algo have the URDF files to integrate in the robot).
- Discussions about the platform architecture.
The URDF/XACRO file was made and integrated in rviz and gazebo, where is possible to send commands and see the platform moving in the simulation. Despite this part is partially implemented, is still necessary more time to fully understand it’s concepts.
The Arduino Micro ordered previously was installed and the code was downloaded to collect and transfer the encoder data to ROS. This part is work, witch means the data is being transfered, but the encoder signal is not good. Despite the bad encoder signal, to test this part of the code, was not necessary a perfect wave.
Also, the work of writing the thesis was carried out, as it’s expected to be continued regularly in the next weeks.
The work of the previous week was carried out during this one:
- The skeleton of the thesis was improved and some pictures, tables and diagrams were introduced in the Latex template;
- The code was also improved: timer interrupts were conflicting with PWM pins and therefore the timer was integrated with PWM; also the I2C code was changed to transfer only two integers via I2C, instead of a string (the code had some changes because it can only be transmitted one byte at once).
- A new Arduino Micro was ordered and a new PCB (with sockets to facilitate the replacement) was made to integrate the Arduino when it arrives (Figure below);
- Some tests were perfomed with the remote control. The ROS tutorial to control the turtle bot with the remote control was made.
This week was dedicated to the following tasks:
- Design of electric schematics that match what’s connected at this point;
- Elaboration of the thesis skeleton (main chapters and sections) and template in Latex;
- Interconnection of all developed code that was implemented separately. In this stage was detected that some code could not be combined together
The next step is to implement the PID control, but this stage was not performed because an Arduino Micro malfunction was the detected. The board cannot communicate via I2C, everything else works, except the I2C pins SDA and SCL. The board needs to be replaced.
This week was dedicated to solve the DC drives problem.
The problem is that the driver has a PCB (designed by Robosoft and not the DC Drive manufacturer) and it works in a different way: 1 single analog continuous signal from -5V to 5V allows to control the motor speed and direction. Because of this, a circuit had to be designed to convert the PWM signal from the Arduino Leonardo to a type of signal explained before.
The circuit schematic can be observed in the picture below.
Additionally, the circuit was implemented, tested and mounted in prototype PCB.
In the beginning of this week has been set a goal: finish the hardware. This means finish all the connections, install the Arduinos, the back LED status panel and fix everything up.
The first task was to project a way to fix the used eletronic. It was drawn, in SolidWorks, a board that could fit in the rack mount. Some holes and space was left to fix the Arduinos and to pass to cables. The used material was polycarbonate (similar to acrylic). This design can be watched further in this post.
After that, the goal was to make the board to put the Arduino Micro to receive the encoder signals. As you can see in the picture below, screw connectors were used to make the connections.
Another detail is the existing socket, witch will be used to place capacitors to filter the signals from the encoders.
After mount the Arduino Micro, the rest was assembled and tested in the mean time:
Arduinos and relay module installed with connections.
In this picture it is possible to observer the pan/tilt unit installed.
The next step was to connect the LED status panel to the main circuit, and make the emergency button disable the DC drives power and the ON/OFF disable the DC power supplies (DC/DC converters).
After the assembly the following items were successfully tested:
- Status LED’s : 5, 12 and 48V;
- Emergency button;
- ON/OFF button;
- Read encoder data and transmit it via I2C;
- Data transmission via Ethernet to ROS;
- Actuate motors (the motors can be actuated but not as desired)
Despite that, a major problems persists, the motors are not rotating both ways. There is a problem with the PWM signals to the DC drive that could not be solved yet.
The week has started well, the new Arduino Micro was already available in the lab so the development was carried out on the new board, meaning the Arduino Uno was left behind. After having the SPI communication established between the Arduinos, this part was merged with the code of the TCP/IP communication to ROS.
While doing this a new problem came across that was not detected previously: the SPI pins are used to the TCP/IP communication, witch means both parts can’t be merged!
Knowing that, a new protocol was used: I2C. It is a little bit slower than SPI, but has the advantage of connect multiple devices easily.
This protocol was implemented successfully with encapsulated messages (with special characters in the beginning and end), witch means the message can vary in length and still be recognized properly.
Note that the same method was used with the Ethernet communication between ROS and Arduino Leonardo ETH to prevent errors and make the data transmission more reliable.
On the rear of the vehicle there was a status panel giving information about the Robuter’s signals. On the picture below this can be observed.
On this rear part the following tasks took place:
- Removing the existent ultrasound sensors;
- Pinout the DB25 connector to match the wires to the PCB connection;
- Add roofmate to give resistance to the rear part. This way can absorb some unexpected impact;
- Study and alter the circuit to the new requirements;
- Extend the wires from the main connector and solder some resistors.
The improvements can be observed in the next pictures
The batteries are already connected. It’s visible in the picture that the cables are longer than needed, but this way each battery car can be take separately without disconnect anything. The final arrangement was the series of the 4 batteries, resulting in 48V.
Additional wires were made to charge the batteries from the rear of the vehicle. To power the robot, the 48V terminals were soldered to a main connector on the bottom of the battery support.
Read encoder data
After establishing connection between ROS and the Arduino Leonardo ETH in the previous week, a new goal was put in place: use an external chip to count the encoder pulses, communicate with the Arduino Leonardo ETH and display the values in ROS.
The first test was made with an Arduino Uno reading the data using interrupts to count the pulses and transmit it via SPI. Several ways of transmission were tested in order to simplify/reduce the amount of transmitted data.
When implementing the temporary setup, the necessary specifications were identified and the Arduino board was selected: Arduino Micro. It has 5 interrupt pins, I2C, SPI and a 16Mhz crystal witch are enough specs to solve the needed problem.
The batteries have arrived and they’re heavy! They weight about 24 kg each, witch gives almost 100 kg in total.
During this week the following tasks took place:
- Check the 20 year old battery charger: clean it and test it;
- Look for the best setup for the batteries and gather the necessary material to do it;
- Creation of a ROS node (client) to communicate via Ethernet to the Arduino Leonardo ETH in a private network: this step was implemented successfully and now messages can be sent from ROS to the Arduino;
- Integration of doxygen in the ROS envoirenment;
- Tutorial in ROS and C++ (1 day).
This week was dedicated for two main tasks:
- Choosing and ordering batteries for the platform
- ROS and C++ tutorials with professor Miguel Oliveira
For the first task a lot of research was needed to choose the batteries. There are numerous battery types on the market and choosing the right one for the right job is no easy task. For this particular application there were several aspects took into consideration such as size, weight, capacity, discharge rate and as in every project, price.
We are aware that lithium batteries have more energy density, witch means they have more energy per kg. But these batteries also are more expensive and have a more sophisticated way of charging.
On the other hand, since this project is about retrofitting, the existing equipment was analyzed. There were 4 batteries of Lead, each with 12V and 60Ah. To hold this batteries there are 2 cases that have an open space measuring [210x340x140]mm and a set of wheels underneath them witch makes operating the batteries easier.
After conducting the research, discuss budgets and analyze the up and downs of each solution, the ordered batteries were similar to the previous ones but with bigger capacity (watch in image below).
The main reasons for this solutions were:
- The increasing of the platform’s capacity in 25% (total energy of 3.6 kWh)
- The batteries are the same size, witch means the existing cases and the charger can be used
- The price is significantly lower than a lithium solution
- The weight of the 4 batteries is useful to balance the platform and lower it’s center of mass. This is important because it’s expected to place a robotic arm on top of the platform and it will to counterbalance it.
As previously referred, a ROS and C++ tutorial took place. The duration was one and half day and was important to get familiarized with ROS environment and C++ programming. This learning will continue during the next weeks since it’s needed to the rest of the project.