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 !
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.
As mentioned by Pierre-Hugues, we got the Kalman filter working today (C++ and OpenGL simulation). The Matlab implementation seems to work as well. The results are shown below. One tiny problem is left for the conversion from the estimated quaternion to the Euler angles (as we can see here for yaw: the plots have an offset…). This is not the case for the C++/OpenGL
Through yesterday’s presentation and teachers’ comments, we have defined our new Project Specific Success Criteria.
Here they are :
|Kalman filter working
|Complementary filter working
|ADC to measure battery level working
|Ball-E is standing
|Ball-E moves the way we want
|We can pilot Ball-E with an Android smartphone
Yesterday, I also managed to make the leds blink on our Ball-E board, let’s begin the Wi-fi !
During the last two weeks, the Kalman filter for BallE has evolved. We now have the mathematical model as well as the Matlab implementation. 3 crucial questions were raised before reaching this point.
System and measurement equations:
x_k= F_(k-1)*x_(k-1) + G_(k-1)*u_(k-1) + w_(k-1)
where v_k and w_k are the measurements’ noise and the process’ noise respectively
X_k describes the state of the system at moment k, Y_k the measurements, F_k the transition matrix, H_k the measurement matrix, u_k the command (in our case we consider we don’t have any command applied for the time being)
1) What type of Kalman filter should we use?
After a literature review and the study of the possible filters, I decided that the Sequential Kalman Filter (SKF) was the most appropriate for our problem: SKF does not require matrix inversion for computing the gain matrix (K). However, in order to use this type of filter we must be sure that the measurement covariance is a diagonal matrix.
2) Knowing that we obtain data from the accelerometer, gyroscope and magnetometer, how can we model the state? How should we deal with the gyroscope’s drift?
To answer this question, I first analyzed filters with 6DOF where the state is defined by X_k= [alpha bias]k (as presented here: http://tom.pycke.be/mav/71/kalman-filtering-of-imu-data ). However, as we have the magnetometer we can use only the accelerometer and magnetometer to compute the Euler angles (Y_k = [roll pitch yaw]k ). We can put as well the bias of the gyroscope in X_k but what exactly should define the state of the system?
Starting on this path, we searched more information about the approach used by Copterix last year (http://copterix.perso.rezel.net/?page_id=26). After studying “Airborne attitude estimation using a Kalman filter”, the Master thesis of Matthieu Marmion(1), Richard Murray’s lectures on Sensor Fusion and Factorized Quaternion Algorithm, we used the following model:
Y_k=[roll pitch yaw]k
F_k the same as the one presented in (1)
H_k the Jacobian of the Euler angles in fonction of the quaternion
3) Do we really need to compute H_k or can we find a simpler form for it?
We know the conversions for Euler to quaternion/ quaternion to Euler, therefore we can write directly the Euler angles in fonction of the X_k. However, we will further need H_k for the filter (for computing the gain matrix and the a posteriori state estimate and a posteriori state covariance). I computed the Jacobian and implemented the whole approach in Matlab.
After testing it with real data obtained from our IMU, the filter didn’t give satisfactory results…Once I finished my code and after calibration (measurement noise, initialization, time step) and after performing the tests I tried to understand where the problem might be. Yesterday I looked at the Copterix implementation and noticed that the set Y_k= [quaternion]. This simplifies enormously H_k. If we take Y_k=[quaternion]k we obtain H_k=[O4x3 I4]. However I wonder if the measurement noise covariance is still diagonal in this case.
Therefore, after today’s presentations I did the necessary changes to my code to work with H_k=[O4x3 I4]. The results are better but the filter doesn’t seem to work properly yet…
During the holiday I will do my best to find out what is the problem and to fix it. If you have any suggestions with what may be wrong in this approach please let me know:D
For the past few weeks I have been working hard to understand a mash of Matlab, Simulink, VRealm, Mathematica, and most of all ‘math’ itself; all of this in attempt to fully understand and simulate the 3D modeling and feedback control of the state of the art rezero robot. The information included by the rezero team is impressive, but the matrix translations and binding equations for describing the coupled state of the robot are too complicated to understand and implement in the amount of time remaining.
The BallIP implements a straightforward planar model, in which the movement of the ballbot is described in 3 separate 2D planes (XZ, YZ, and XY). The feedback control loop is modeled as a PD loop. The theoretical values are computed and then tuned for the real system. The first attempts to reproduce the nyquist plots given in the BallIP report were unsuccessful. I can only imagine that its a misunderstanding on my part of the interpretation of transfer functions in matlab. This is something I will have to get help on from one of the TSI professors.
Today I started up on coding in ChibiOS along with the rest of the group by testing a thread which flashes a LED. Pierre-Hugues has set all of the configurations for the BallE board so it was fairly easy to pick up demo code and get it running.
To further understand ChibiOS I will also start playing the usage of the PWM during the vactatio (sooner than later). Hopefully in parallel I have time model the transfer functions used by BallIP.
More to come…
Yesterday we got our PCB soldered, next step is obviously to test it. First happy thing was that the board didn’t get on fire when powering it on.
We created a new ChibiOS project that will be the base for our code. To do things the proper way, we also made a new board folder, which is specific to our PCB. It specifies all the settings of the various GPIOs on the µC, such as the alternate functions.
One minor problem we hit, is that stm32f4 isn’t supported in the openocd build that is running on lab’s desktops, so we had to build master branch of openocd’s git. Thanks to Sam, that was an easy task. After that, the JTAG just worked out of the box.
Once everything was setup, first functions we’ve tested is powering on/off the red led, and the serial port. Testing them made us realize that the serial port has actually been wired the wrong way, TX on the usual RX pin of the micromatch. Hopefully, we aren’t the only group to have failed on that, so we can use SaMoRa’s serial cable .
Another mistake on the schematics we found out, is that one encoder plug isn’t properly usable: one pin is on a timer, while the other one is on another timer. This is no big problem, since it can easily be done in software, and that it seems really unlikely we’ll use encoder.
Yet another mistake on the PCB, is that the plugs aren’t named, so we need a map to know what function is on what plug.
Anyway, despite the various problems, all the features tested are working, so that’s great news !
Yesterday, we talked about all what we have done until now and we had a meeting in order to be sure that everybody understood mostly everything about others’ work.
Thanks to this meeting, we scheduled next steps of Ball-E’s conception and we prepared our presentation for today.