We are getting closer everyday to our goal, Ball-E manages sometimes to keep its balance for a bit more than a second.
Yesterday, we realized that the plastic between the wheels on the omni-wheels made a huge friction on the ball, preventing him from moving easily. Therefore, we used a soldering iron to melt the plastic and then a dremel to sand it and it is now working much better. We are now having a hard time choosing the coefficient of our PID algorithm. I hope you will be able to see videos of Ball-E standing by its own means soon !
Two days ago, we finally managed to flash the Gainspan Wi-fi module’s firmware and we can now talk to the module through the SPI interface and I managed to make it connect on a router which was in the room. I am now working on the driver to make it work completely.
As I had finished coding the PD algorithm, Pierre-Hugues worked in order to enable us making real tests of balance with Ball-E. Therefore, I build a system to put the robot on the ball while hanging in the air so that it couldn’t fall on the floor (you may see it on the pictures). We made some tests with several balls and it appeared that we needed to have a center of gravity higher. That’s why you can now see Ball-E with a tall structure. Today we are going to buy a bigger ball to make new tests, it should be easier for the robot to keep its balance with this one.
We hope that in a few days, we will post videos of Ball-E standing up and not falling !
As our FPGA must communicated with the gumstix using the GPMC bus, 2 clock must be used on the FPGA : GPMC clock for data transfert and, the internal FPGA clock for all the other operations.
To isolate the two clock, we use a dual clock fifo (a altera’s megafunction). Yesterday, Sylvain and I worked all day long trying to make work the fifo (and correcting some problem of simulation … ) in order to turn on LED indicated by the gumstix. It was not a success so, we will keep on working on this problem today.
We worked on the FPGA this last days.
While I was working on controlling the LED driver, Felix and Sylvain worked on the communication with the gumstix. The news are good :
- the communication between gumstix and FPGA is now working. But, the module for the communication must be modified because, in our real system there will be 2 clock : the FPGA clock and the gumstix clock (just for the data transmission). Felix and Sylvain have finished to implement this new architecture but, it must be tested.
- the control of the LED driver is perfect: we can now turn on all the LED on the propeller, choose the color and the intensity
The next steps are controlling the LED thank to the gumstix and, writing in the external RAM.
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.
The FPGA is now able to do a write access with the GPMC (a read access is not possible for the moment). While Sylvain will work on the reading problem (there are some problems with nOE signal … ), I will test some final modules on the FPGA. All modules are written (with the new calculation flow) and, most of them (but not all for the moment) are tested on simulation. Today, I want to test on the FPGA some modules : ram controller and ram switch modules.
Although I had finished implementing the calculation block in the FPGA, a discussion with Alexis changed the general architecture of this block. The choosing architecture is the following :
This architecture is simpler. I will now begin to implement it.
Afeter correcting some hardware errors, we spend the two previous days working on programming the FPGA. Now, we are able to command the GPIO of the gumstix and, the program JAM STAPL uwhich we use for programming the FPGA is ported on our system. FPGA answer to the gumstix when programming program is started but, for a reason we don’t know for the moment, 0 device are detected on the JTAG chain.
Because of our problem with the GPMC to communicate with the FPGA, we probably will command a new board. So, befoe buying a new board, we want to test if the FPGA programming (which does not use the GPMC but 4 GPIO to communicate with the JTAG ports of the FPGA) is working. So today,I worked on porting the software (jam STAPL )on out system (software which probably did not work on a system before I modify it). Now, the software is compiling and, tomorrow I will try to run it on the gumstix.
I began to debug the general system on the FPGA too but not a lot.
This week-end, I worked on the FPGA. All modules are written excepts the gumstix communication module because we have some problems with the gumstix I will explain next. I wrote a module to debug all system reading in ram (and so a module to simulate the ram behavior): debug is in progress.
On the gumstix, we use the NCS0 as chip select but, even if gumstix allows us to access to this signal, it is yet used by the NAND (which is not explain in the gumstix’s “data sheet”. So, we can’t use the GPMC to communicate with the FPGA for the moment. We have thought about several solutions: hardware patch (if it is possible) but, before doing this, Felix is trying to find a software solution to disable the NAND to be able use the GPMC with the FPGA …