ELECINF344/381

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

Catégories

RoseWheel: Improvement of the PID

These last two days we mainly worked on tuning the PID coefficients to improve the stability. In this way, we tried to find the best set of PID coefficients so that RoseWheel could raise from an almost horizontal position and recover stability as soon as possible and then maintain this stability over time, even under hard external perturbation. We also worked on improving the coefficients we found for the human driving mode to make the right compromise between smooth-driving and responsiveness.

watch?v=Bn9MVGXuFqQ" /> watch?v=Bn9MVGXuFqQ" type="application/x-shockwave-flash" allowfullscreen="true" width="425" height="344">

During this test and improve phase, Alexis advised us to plot the curve of the different values critical for our system. Thus, we plotted over time the value of the angle and the angle rate before and after the kalman filtering and also the command sent to the motor calculated by our PID algorithm.

It made us find 2 problems in our software that explains why at the beginning RoseWheel was so unstable:

  • The Kalman filter wasn’t configured correctly. We first configured it for the testbench but we forgot to change the time step that was indeed ten times smaller than the correct value. That led to latency and incorrectness in the output of the Kalman filtering. Changing this parameter to its correct value made the system become really more stable.
  • Even after the Kalman filtering, we noticed that the angular rate was still a lot noisy. This noise caused our gyropod to vibrate a lot when increasing the derivative coefficient Kd in the PID. That is a problem because increasing the derivative coefficient is the only way we have to lower the amplitudes of the oscillations induced by a big proportionnal term Kp in the PID. Thus, we decided to smooth the angular rate value by using a low-pass filter after the Kalman filtering. It’s really a simple filter as it’s only made of 2 coefficients, but according to the plots, it made its work correctly and the angular rate seems to be really smoother than before. But while testing, increasing the derivative coefficient still leads to oscillations and vibrations, so we still have to work on it.

As we obtained satisfying results at making RoseWheel maintain its equilibrium, we started working on other features :

We implemented the safety switch and elaborated a protocol to avoid as much dangerous situations as possible :

At the very beginning, when one presses the power on button, RoseWheel is in self-driving-mode by default. That means it will try to reach its equilibrium position as soon as possible and then remain in this position. We assume that the user isn’t too silly and, for instance, will not try to power on RoseWheel in an almost horizontal position whereas he is facing it. Then, as soon as the safety switch that is located on the base is pressed, that means that someone has its foot on RoseWheel and wants to ride it : RoseWheel switches to its human-drive mode. If suddenly the safety switch is released, RoseWheel checks the angle. If it’s almost 0°, that means that RoseWheel’s speed is almost 0 and the person maybe wants to get out, then calmly RoseWheel switches to its self-driven mode (we still need to implement it). If the angle is under 75°, that could means two things: the person has felt down or the person has temporarily raised its foot. Thus, if the safety switch isn’t pressed within 1 second, RoseWheel makes a special noise, then, if it’s still not switched on within another second, RoseWheel switch to its self-driven mode. Finally, if the angle is greater than 75°, that means that the person has felt down and RoseWheel could represent a menace for people around, motors are disabled.

2) Concerning the obstacle detection, we almost finished to implement the sharps and sonar drivers. As these detectors are really sensitive to the external conditions, we still have to test them and see how they react in the different environnements RoseWheel will evolve in.

3) Concerning the remote control, we almost finished to implement the drivers for the Bluetooth, we made some tests yesderday, but we still need to continue them today and we will talk more about it in the next article.

IRL : Settings !

In our last article we described some ways to enhance the display of a text scrolling smoothly.
We actually tried several possibilities of settings for the scrolling text and finally found a convenient one (as shown on the video above).

We did some major improvements concerning the speed of the code on the card succeeding in speeding it by a factor of 5. We deemed that a major issue of that program lays on the access time of the memory. Indeed it takes more than 20 seconds to write an ILDA file of a tweet from the ram to the flash. Samuel suggested that we could use a socket to directly send the ILDA file from the python script to the C program in charge of the FPGA communication. In fact, with such a strategy we would avoid the slow speed flash access and be able to send a tweet to the laser around 30 seconds after its validation.

In addition we’re going to add some bit stuffing to make the frames equally populated in terms of points so as to assure a constant frame rate. You can easily notice that disturbing effect on the video above.

In parallel, we’re getting familiar with the DMX protocol and are working on the DMX board.
We haven’t forgotten the software fifo between the C program and the FPGA. We deemed that a zeromq socket would be a interesting solution and we are currently working on it.

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.

IRL : firsts tests with the real laser

Real laser

Today we replaced the oscilloscope by the real laser. As expected, it does not exactly work the same way, but our first test with « The Riddle » is not so bad. You can see it on the video below, it is little as we do not have a lot of space in the classroom. You can see that the image is blinking, this is partly due to our code, but also partly due to the camera sync, and the « real » result is cleaner than what can be seen here.

FPGA design

The new design suggested by our teachers has been implemented, except for the FIFO which for the moment does not use the internal RAMs This will normally be done tomorrow. The FIFO, as it is now sometimes, leads to some bugs that we do not really understand yet. We will also investigate those issues tomorrow. Nevertheless, we have a functional design, the one we used tonight to make the video.

Tweet to ILDA

Concerning the way we will display tweets, Sam suggested us to make a smooth horizontal scrolling. Our first idea was to generate a big ILDA image containing the whole tweet on one line, and to clip it at display time, just before sending it to the laser. It seems that is was not the best way to act. So, we are now trying to generate an ILDA animation corresponding to the scrolling with a Python script. We are on our way and we have yet disclosed a few points of intersert to change in our design to make it work soon.

Web interface

The library we mentionned last time (libmicrohttpd) seems to fit quite well with our needs. It is not a complete Web server, but it is enough to make the card serve a static HTML page and a little REST API to get tweets and validate them. The authentication is for the moment very basic it consists in a « secret » token as segment of the URI. It is not very secure, but it is not our priority at the very moment.