Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).


IRL : Good news !

As you see, yesterday we were having fun with the laser trying to enhance the performances of our smooth text scrolling show. We now have embedded the whole program and it generates directly the ILDA file on board. We still have some speed issues, namely the program which generates the ILDA files is still pretty slow (it takes more than a minute for a tweet), but our imagination is thriving regarding optimization tricks and yet we gained a significant factor on the computing time.

We are also concerned about the beauty of the text. In fact we noticed a few effects in which we’re focusing on :

- When the laser goes more quickly, the line between 2 given points tends to look like a curve Solution : we are going to fix the derangement by adding several intermediate points between our points, this will be done in C at the end of the display chain.

- When the points are too faraway one from another, the galvanometers tend to be more noisy and we tend to be more worried about the survival of our system. Solution : we reduce the size of the text (so as to narrow the space between points) and insert intermediate points between the characters and at the end of the frame to make the shifts of position smoother.

- When the laser isn’t quick enough, we recognized that the flickering effect is more important.
Solution : we need to speed the laser up.

We did some major improvements on those different points not to mention the complexity issues. Step the text is getting more and more beautiful !

I’m sure you want to know a little more about our FPGA. We have enhanced our previous design by adding a RAM FIFO which will allow us to reduce the load of the CPU. We’re working on the CPU’s side of that program. Anyway, our security module seems to be a bit too sensible and it is triggering more often than expected.

In the next few days we will stress on the development of the DMX card.

RoseWheel: first ride

Tuesday evening, after nearly two days of fine-tuning our testing procedures and security measures, we finally did the first tests on our own vehicle. In order to make sure we didn’t damage the equipment (nor hurt somebody), we followed a simple and strict protocol:

1. First of all, we checked that we could control manually the motors via our interpreter;

2. Then, we verified that the limitations we applied to the variation of the voltage of each motor were adequate (as mentioned in a previous post, an abrupt increase or decrease on the voltage could severely damage the motors);

3. Finally, we determined a maximum speed that seemed reasonable, so that we could stop the vehicle manually should the worst happen.

After this initial procedure, we could start the actual tests of our system. After some iterations of tuning the coefficients of our controller, we realized that it was actually much easier to equilibrate the vehicle with a human being on top of it than without any load, since:

(i) the person enhances the performance of the control system by balancing his/her weight in a way that maximizes stability;

(ii) the presence of the human being makes the test conditions closer to the physical model we used to compute and simulate the parameters.

After several adjustments, we were able to take our first ride on the RoseWheel -- with basic steering capabilities via the integrated potentiometer implemented as a plus.

Nevertheless, by wednesday morning we had not yet found a way of balancing the RoseWheel alone -- a must for our next major goal, remote control. Then, we realized that the chassis we used had a very interesting property: by tilting it to a specific angle, we could align the center of gravity of the steering bar with the axis of the wheels, reaching a metastable equilibrium. We used this fact to offset the error variable of our PID controller, and that proved to be very effective, since we obtained as a result a pretty good stability. But all this comes at a price: since we now have two different equilibrium positions, we must use the safety button located on the chassis to determine if we are carrying a person or not; nothing too difficult to implement, though.

On the other hand, the PID coefficients may be trickier to master. We are still working on them to solve the issues we are having, notably oscillations and vibrations that sometimes occur. To help us with the debugging, we set up a solution to plot angle, angular velocity, and output voltage command for each one of the motors. Our next actions on this front will be to use all these data to better tune Kp, Ki and Kd, so as to have a more responsive and stable control algorithm.

Meanwhile, we started to move on to our next goals: we began to study the Bluetooth controller, and are already able to compile and run a « hello world » Android application. Next steps include implementing drivers for our distance sensors to implement obstacle detection.

To summarize all our work, we prepared a special video showing some of the most interesting (and/or funny) demos we made so far. Enjoy!