Today we focused in the encoders. The module to correct the speed of the motors is done but it is not using directly the encoders yet, we tested it with a fake function to simulate the real velocity that is going to be calculated from the encoders.
The module which calculates the real velocity from the encoders is not 100% yet, but almost. Tomorrow we are going to complete this module and link it with the corrector module.
We fixed FreeRTOS too, as it was not running in flash memory, seems that the first position of flash (where the stack pointer should be) is protected as we couldn’t write on it, we still need to investigate why. Now we are able to turn on Tutobot and the program runs automatically.
The OLED is not working yet, we verified the pin assignments in the FPGA (in Libero) and it seems ok, the code seems ok too, we are still investigating.
While measuring some pins with the oscilloscope, we got once the same curve that we got yesterday while trying to measuring the line sensors, so we concluded we never captured a signal from them. Today we notice that in Libero they are not configured as inout pins, and for some reason we can not change this parameter, this still needs to be investigated.
Time of death: Sunday, 30th April, 4 a.m. After our first real experiments on BallE, one of the transistors from the H bridges controlling the motors burnt on Sunday at 1 a.m. We aren’t sure about the cause underlying this incident: at that time we were varying the acceleration. While stopping the motors, in order to stop them faster we forced the current to 0. This induced a high voltage in the circuit: one transistor burnt and then we weren’t sure the others hadn’t been damaged in the process. Once we figured out what happened, we tried to replace the transistor. As the components on the card were really crowded given the surface (and didn’t satisfy the theoretical constraint of having enough space for the H bridges to cool down) it was hard to extract the transistor and re-solder a new one. We didn’t have the exact replacement so Samuel and Alexis tried to improvise with the transistors we had in stock. The replacement didn’t succeed and at 3 a.m. we had the choice between:
a) redoing the whole mechanics and design for a 2-wheel ballbot
b) picking up another project for the following 4 days until the defense
By choosing option A, we couldn’t guarantee that what happened for one H bridge wouldn’t happen for the others… we barely started our tests with BallE in the final form. BallE wasn’t stable and we needed time to calibrate and perform a broader range of tests. None of us wanted to give up working on BallE. However, we had absolutely no guarantee that we will have succeeded in keeping Ball-E stable for this Friday. We all enjoyed working on this project and we were very emotional about our choice… However, the risk of not having anything stable for our defense was very likely even if we kept working hard on Ball-E.
After a Sunday night full of nightmares, we spent the day thinking of replacement projects that were doable with the hardware we have for ROSE.
The following post will be dedicated to explaining our options and choices. Now, let’s keep a moment of silence for Ball-E…
Today we worked on the peripherals of our robot.
We debuged the motors and now they are working fine.
The encoders are returning values with good resolution, tomorrow we will work to assemble a control with motors+encoders.
The pins of the line sensors seems not responding really good, we tried to capture the signal with a logic analyzer and an oscilloscope. We could measure the response with the oscilloscope, but only once =/, using the same program and same osciloscope.
The proximity sensors are not giving us good resolution between closer objects and farther ones.
Leds with pwm are working really well, we can choose in a register to use the pwm mode or not.
Zigbee is still not working after we programmed the SysBoot with DirectC.