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

Let there be light, sound and color !

BEDinROSES (Ball-E Dead in ROSE Session)

Date and hour of birth: Monday 30th , 7 a.m. Since Sunday night we have been brainstorming for possible projects. Alexis and Sam adviced us to use Maestro’s modules. Some great ideas came up on Monday and we chose to work on three of them until Friday morning.

Monday the modules were able  to play music stored on their microSDs. Yesterday we worked on Zigbee communication by frame based  API and we synchronized the modules. Today we are working on Friday’s defense.

Otilia Anton

Ball-E’s last hours

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…

Otilia Anton

BallE Kalman

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

Otilia Anton

BallE Kalman

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)

y_k= H_k*x_k+v_k

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)

Questions:

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:

X_k=[bias quaternion]k

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

 

Otilia Anton

BallE – mechanics and control review

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

Otilia Anton

Kalman, PCB and paper

We started the week by working on Ball-E. I am very happy with the protoype that Matthieu & PH built on Monday afternoon, it gave us an idea on what motors we need and we had the chance to check that the system works (the mechanical part). While baby Ball-E was being built, I have been digging for information on the Kalman filter applied to problems of inverted pendulum. Dan Simon’s “Optimal State Estimation” gave me a better understanding of the mathematical context. Apparently once we have our kinetic model we can implement the filter. I still need to clear up some thoughts on applying it to Ball-E (sensor fusion… in which order, what defines the state -acceleration, orientations, how will we process data from the IMU).

Meanwhile yesterday I finished my PCB. I was satisfied about the final placement. I hope the routing is good. Still there were some ground vias missing in the end and I had forgotten the command that would have enabled me to perform the final corrections.

Today I worked on the paper on firmware and bootloader. It was the chance to use Latex after a long pause. Writing required re-reading some of the papers we studied for the presentation and searching for new information. Brice and Jeremy worked on their parts as well and we discussed in the evening on the paper’s structure, content and what each one of us has written.

 

Otilia Anton

STM32 getting ready for the communication challenge

LEDs on, LCD printing properly 2 different messages through xQueue, redefined system call handler (pressing the button connected to PC13 turns on the blue led). Starting ZigBee:)

Otilia Anton

Ball-E movement analysis

Today we tried to model properly the system’s mechanics for Ball-E’s movement by looking at what is happening in the zx-plane (similar approach to use for zy-plane) if the robot is at an incline. It implied defining the coordinates and the angles that we need further for describing the system’s dynamics. This is a compulsory step before working on validating the control part.

As it isn’t yet all clear, we will continue investigating tomorrow morning and validate this step through a SolidWorks design.

Ball-E Team

Otilia Anton