ELECINF344/381

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

Catégories

RoseWheel: tests preparation

This week we tried to put together our developments and make them interact with each other. It includes sensors communication, kalman filter, control feedback, motors control, CAN communication protocol. We were dogged by bad luck as we realized the heatsink of our mainboard was too big to fit in the Zzaag… A few millimeters required us to order for a new one with a more suitable shape. Fortunately Alexis and Samuel helped us to find a new one. Because of that we were not able to validate the following « feedback control tuning » PSSC for Saturday as planned. Adviced by Samuel we also decided to postpone the « encoders drivers » PSSC as it wasn’t really in our first order priorities.

 

We tried to make profit of this situation and decided to prepare everything for the first tests. Alexis helped us defining our tests procedure to be as safe as possible for both hardware and people. Motors need special attention as they can be broken with unsuitable commands. Because of the wheels and the weight of the chassis they have a really high inertia. Asking them sharply to reverse their direction of rotation when they are rotating fast can seriously damage them and the H-bridges. If we damage them we wouldn’t be able to order new ones before the end of the course, it would be fatal for our project. Therefore we need at first to make some testing at low speed so as to define the maximum acceptable speed at which we can run the motors before they get damaged. To this extent we need an interpreter running on the mainboard and communicating using RS232 to be able to give motors various commands and define this maximum speed. Then we need to limit our commands to this maximum speed using software limitations. Finally the interpreter should be able to change the feedback control values for our testing to be more flexible. We implemented such an interpreter and made a video. The motors commands in the video are given between 0 and 1000 such as:

  • ml0 = 0%:  max negative speed
  • ml500 = 50%: stop
  • ml1000 = 100%: max positive speed

 

Before trying the Zzaag motors we do some testings on other DC motors with less inertia that we cannot damage as easily as the Zzaag’s ones. Putting all the pieces together we were able to shoot a video which shows the motors reacting appropriately to the inclination of the sensorboard. As for the Kalman filter, we implemented a lighter version than the one of RoseWheel as it works best when tested on the real system. This version was only able to track the gyroscope drift and correct it. As far as we could see during the testing, it did it well. Concerning the PID, we tried to test the version that we are going to use in the RoseWheel but it still needs to be improved during the next tests.

 

Tomorrow we will be able to work on the Zzaag motors using our safe procedure and the tools developped. We look forward to it as it is a major step further for our project…

Sur le même sujet :

  1. Copterix : first moves
  2. RoseWheel : banc de tests et filtre de Kalman
  3. Copterix: motors control, 1st test
  4. RoseWheel : CAN & Kalman
  5. RoseWheel motor control: 1st step

5 comments to RoseWheel: tests preparation

  • Using an interpreter is a good idea, although I would have chosen a Forth one :)

  • Clément

    Actually it was Alexis’ idea :)

    What do you mean ? An interpreter in forth on a computer which talks to the board ? All our interpreter code is on the board, we just need minicom to use it. Isn’t it more simple than having two different codes in two different languages to maintain ?

    • You can link a small Forth (such as PFE) with your program and add some primitives. For example, you would then be able to connect using a terminal emulator as you currently do and type « 400 left » or « 150 right » to drive the motors.

      One immediate advantage is that if, for example, you need to drive both motors at the same speed and you haven’t planned for it in your interpreter, you can just type interactively the following sentence to define a new Forth word (command) « both »:

      : both dup left right ;

      Then typing « 230 both » will be the same thing as « 230 left 230 right ».

      And that’s no more « two languages to maintain » than your own interpreter which has its own language that noone knows a priori :)

      (note that you could have used eLua as well)

  • Phh

    A little link:
    http://www.kernel.org/doc/Documentation/input/rotary-encoder.txt
    It only needs to feed it with proper GPIO as platform_device.
    This driver seems overcomplicated though, compared to what we use on Telecom Robotics’ bot