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…
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 !
We can finally control the leds one by one with the gumstix through the gpmc and the fpga and play a little bit with our system.
As usual, big thanks to Alexis for the help.
Now it’s time for the breakfast and the coffee in the students’ home !
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 !
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.
Hi, just some news about our project :
The PCB of the station and remote control are almost ready.
In the same time, Guillaume is working on the bootloader. Brice implements a NMRANet communication thread between can, ethernet and dcc. As for me, i tested if the remote control can be supply by 5V and i’m working on the conversion between Xpressnet (Remote -> Board) and DCC nmranet packet (Board -> Station -> Train).
Before the Athens week I started studying the Kalman filter. At the begining of this week I decided to work along with Scott who has been studying the mechanics of Rezero and BallIP as they were presented in the reports we found online. As two heads are better than one, since Monday we have been focusing on the mechanics, control and filters as a whole. The control system as well as the model are different for Rezero from the ones used by BallIP. Certainly Rezero performs better but BallIP seemed more comprehensible at this step. In most of the papers that we read the authors first implemented what was previously achieved with ballbot technology and then built upon those concepts. Therefore today we focused on understanding the planar model (forces, energies, inertia calculations, torque conversion).
Certainly, in practice this model has limitations: the effect of the wheels is not decoupled – this highly influences the angle of tilt (before Rezero the tilt angle achieved was maximum 5 degrees whilst Rezero can recover from a 20 degree tilt). However, we considered we had more chances to understand the planar model before starting directly with the 3D model of Rezero. One of our goals today was to actually implement a Simulink simulation based on the description given in the Rezero report for the planar model.
We discovered that that there is a significant learning curve to designing a Simulink simulation model. We had a nice surprise stumbling upon a 2D model of an inverted pendulum through the Simulink Demos. Though it is not exactly what we need, we intend to use it as a basis for learning and simultaneoulsy adapting it to the planar model.
More on this tomorrow:)
For BallE – Otilia & Scott
P.S. on Monday I have studied the robots’ parameters (mass of the ball, mass of the body, radius of the ball, moment of inertia…). Rezero and BallIP are have significant mechanical differencies: the center of mass of Rezero is significantly higher than the center of mass of BallIP; the ball used for Rezero is a hollow aluminium one of 2.29kg coated with soft rubber whilst the ball of BallIP is a bowling 3.8kg ball coated with Plasti Dip. We could try Plasti Dip as well: http://www.plastidip.com/home_solutions/Plasti_Dip