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.
Today we solved our Zigbee problem, it was really silly: we were not waiting enough time before and after entering the Zigbee’s command mode. We had a loop to do this waiting that worked fine, but since we programmed the System Boot with a clock twice as fast as before, the loop was not long enough anymore.
Since we had both motors and zigbee working well, Helen wrote a basic program to control the motors with the keyboard, sending directions through Zigbee.
Gabriel is working on driving our OLED screen. He wrote a program following the example in the datasheet but it did not work. It is difficult to debug because the bug can be either in software or in the pin assignment done in the Libero project (FPGA). We will re-check the pin assignment tomorrow. He also started working on a way to make it simpler to write the .dat file (the image to program the FPGA and the System Boot).
I wrote some code to use the encoders, and set the Libero project to set flags for the corresponding ADCs, so an interrupt would be generated when the measure in the ADC overcomes a certain threshold. For some reason I have not figured out yet, the interrupt routine is never called. For now I will leave the interrupt approach, and create a FreeRTOS task to monitor the ADC samples.
We did it: we can activate the Tutobot motors now! After having brushing lots of bits to flash the FPGA image we could flash one that that implemented the interface to the motors and LEDs with the MSS using the FPGA. You can checkout the first run in the attached video (don’t mind about the shake to the camera since I scared when the motors started ).
It could had been earlier but we are still having issues to write the FPGA image file to the SPI memory. We already tried many approaches but we are still losing a few bits in every write (and when I mean a few, it is some 32 bits for the entire 191kbytes file). We still have to figure out how what is going on with the SPI interface.
During the vacation, I had a hard time coding the wifi driver using the SPI interface. Hopefully, we had foreseen a serial interface in case of problem. Through the serial interface, typing the command AT+SPICONF=0, 0 (taken from the reference manual) gave us the answer ERROR: INVALID INPUT. Therefore, we concluded that it must be the firmware of the Wifi module that doesn’t handle the SPI interface. However, to download a new firmware, I had to firm a NonDisclosure Agreement and send it to Gainspan and fortunately they answered us quite fast and we now have access to all the firmwares available. Today’s objective is to flash the Gainspan module and code the Wifi driver through the SPI interface.
While I was waiting for Gainspan’s answer, I studied the PD algorithm in order to control Ball-E’s balance and I coded a function that should (if I didn’t make any mistake) make Ball-E keep its balance. We will only be able to test it on Wednesday when we receive the external motor control card.
First of all, I would like to apologize for not having given you news about Ball-E for such a long time.
Let me make a short summary of where we are now.
Before the Athens week, we decided several components of our robot and we received most of them. Actually, we have our 3 stepping motors (Trinamics QSH5718), our two-rows 4″ omniwheels (Kornylak). With Pierre-Hugues, we made the pin assignment of our STM32405RG-based card and finished the schematic of our PCB. Routing will be done as soon as Alexis will have corrected our schematic. Scott and Otilia are working hard in order to implement a Kalman filter and to understand a huge part of the mechanics.
Alexis lent us a card with an accelerometer, a gyroscope and a magnetometer so that Otilia and Scott can test their Kalman filter. Pierre-Hugues is going to code tomorrow a bootloader which will make the card dump the values of the sensors through the usb port.
My objective of tomorrow is to build the whole robot so that it will be ready for real tests when we will receive the PCB.
The motors we choose are 6V nominal but the documentation says they can be driven with 9V. The stall current is of 360mA.
I choose a driver IC we had on our mentor graphics library, the L6206. I have one uncertainty about it, it’s its over current protection. The datasheet gives information on how to calibrate the current threshold using a resistance between 5k and 40k. The problem is that the minimum threshold previewed (with a 40k resistance) is about 552 mA, which is above the stall current. I am not sure this is a big problem, if anyone has comments I’d appreciate =].
Meanwhile I am searching a voltage regulator for the motor. It has to generate the 9V with 800mA, from the voltage coming from the battery/usb system. This input voltage is not constant and may vary from 2.5 to 4.2 V. Looking for some options at Linear technologies, I found some ICs, and narrowing down to the simpler and most adapted ones I got these:
None are available in our library, so one of them needs to be added. I could not see important differences between them, but I think the 1872 is a little more powerful than we need. For now I am going with the 1370.
Today, while Otilia and Scott tried to learn things about Kalman filter and from Rezero’s final report, and almost commited suicide after :p (don’t worry they’re ok), Pierre-Hugues and I continued the mechanical calculations.
Unfortunately, it appears that our calculations must be false as the result with numerical values didn’t make any sense.
So we decided to make tries with a real ballbot. We asked the Telecom ParisTech Robotics’ Club if we could borrow them some omniwheels and DC motor in order to estimate physically the power that need for each motor. We would like to thank them for accepting and we would like to introduce you our new friend : Baby Ball-E