ELECINF344/381

Interactive web site of Télécom ParisTech's ELECINF344/ELECINF381 Robotics and Embedded Systems classes (a.k.a. ROSE, 2012 session).

Categories

It’s rolling now!

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 :-D ).

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.

Motor first run (ogg)
Motor first run (mp4)

Gabriel Teixeira

Wi-fi, Ball-E’s structure and real tests

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 !

 

Matthieu Tardivon

Wifi, and PD algorithm

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.

Matthieu Tardivon

Flashing to the FPGA fabric with the Smartfusion

It was tricky but now we can do it. We have now a program that downloads an image to write on the FPGA fabric.

Initially the approach was to write using the UART to download the image but it seemed that this could take more time to develop than intended initially so the approach was changed to another were we compress the image and store in the MSS RAM.

One problem with this approach is that the compressed image might be bigger than the amount of memory that the MSS RAM can hold, so this may require segmentation of the FPGA image (it is still not yet verified if the image can be bigger than that). Another problem is that the binary that programs the image in the FPGA has to be relinked to the image, which needs to be loaded to the MSS again. This problem can be overcame by downloading the image to the MSS RAM, without relinking it to the application that flashes it to the SPI flash, then writing the image to the SPI flash memory.

Another problem to deal with is that this was tested only on the SmartFusion eval board, and the eval board uses a flash memory that is different from that of the Tutobot. Since that SPI flash has a compatible instruction set, we expect that it will work with having to fix it.

Gabriel Teixeira

Tutobot – Project News

Hello everybody,

Updates of the project:

  • SmartFusion A2F200 and OpenOCD

After preparing the patch to OpenOCD to support writing in the flash memory, we sent the patch. It was refused due the amount of code from Actel we used to generate the embedded bin program. We could provide a cleaner code, removing the unused things from Actel’s driver, but it is working and we don’t have much time, after Rose we can work more in the patch.

If you are still interested in this patch you can found it here. Or send us an email :) .

  • PCB

Our PCB has arrived! \o/    Seems that we are going to weld the components tomorrow :)

  • Libero (FPGA and project configuration)

The routing of FPGA is done, a map between MSS ans FPGA, which are the things that can be connected directly with a GPIO and which can not. So after we have our robot, we will be able to drive the peripherals which doesn’t need a complex FPGA support.

Necessary HDL modules will be done together with the peripheral’s drive.

  • FreeRTOS

We integrated FreeRTOS to our project. There is just some minor things we need to configure, as the code work in the Ram but doesn’t in Rom memory =/

  • SPI Flash Memory
SPI driver is done and tested for SmartFusion Evaluation Board, we will need to adjust some aspects of the drive to our SPI flash memory
  • DirectC

After the OpenoCD patch, we tested DirectC in flash it is working but it is not fully integrated with the project. Tomorrow we hope to have the FPGA programing environment working and tested with our Robot.

 

More updates tomorrow.

 

Tutobot’s Team

 

Helen Fornazier