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

RoseAce final website.

The project has ended for some months now and RoseAce team is proud to present its website, and this video of the final project.

 

Sylvain Ract

RoseAce displays a picture from the ram.

After a long debugging phase of our external RAM where we encountered many issues from the simple bad solder to timing issues we finally manage to deal with it.

For the moment we still have only one RAM which has five unavailable pins. So we can store only a eighth of on image but it allows us already to display symmetric pictures like this RoseAce!

You may notice that as we expected the center of the picture is much brighter. So we will have to change the parameters of our LEDs in order to be homogeneous.

 

Sylvain Ract

A snake on a RoseAce.

This video is a little Snake implemented on our device.

To do that, we have stored ten different ranges of pixels in a RAM. (This RAM is a virtual RAM implemented in the FPGA)

Then we displayed alternatively these ranges by reading new addresses in RAM each 0,1s.

Now there are two new step to make; replace the virtual RAM by the real RAM soldered on our PCB and making the pale turn and alternate these ranges no more each period but each position of the blade thanks to the coding wheel.

Sylvain Ract

RoseAce deals with FFmpeg

In order to display a video file on our device we decided to use FFmpeg. That is a well known software program used to deal with multimedia files and – for the anecdote – it has been created by a former student of Télécom ParisTech, Mr. Fabrice Bellard.

It provides us with libraries that allows us to deal with media files and I tried to use it in order to implement a short player that takes in argument a video file and sends the frames to the FPGA.

But I encountered two main difficulties: The compilation and the use of the libraries with which I was not familiar. Moreover the tutorials to create these type of players that can be found on the official website for example are out of date.

So I decided to rewrite a program following this pseudo-code:

-open the video file.

-while the video stream provides with frames; do something with it.

-close the video file.

The program works and there are now two things to do to complete it:

-Define what will be the “do something with frame” and for that I will discuss with Félix who is dealing with GPMCs.

-Implement a protocol to command the system through a server interface.

And of course make all that running on our Gumstix rather than on my personal computer.

Sylvain Ract

Mechanical point of view: the result.

 

Thanks to M. Croullebois, our devices is ready to welcome the pale. (excepting the motor  that is not relevant for the moment).

The most important aspect is the electrical  contact to supply power toward the pale. And it works well! We tested statically with a voltmeter, then with a battery and by turning the device by the hand.

Let’s wait for the blade!

Sylvain Ract

[RoseAce] Mechanical point of view

The mechanical aspect of or device may appear simple besides the complexity of hardware but managing to make the blade turn while fueling it with 120W is a real challenge.

Here is a view of the draft used to propose the solution to the person who will make some pieces: The tree (in the center of the device), the base to support it (represented down and right to the device) and the piece that will hold the blade (at the left of the device).

To better understand it I colored several parts of the scheme.

In yellow is the pale bearing the leds, the gumstix, the fpga, memories etc.

In red is the part that will turn: the tree, the piece that will hold the blade and a part of the coding wheel.

In blue is the part that will stay: the base, the engine, the outside ring of the ball bearings and the second part of the coding wheel.

In green is the system of reduction (2:1) that links the engine and the tree. It will allow us to have a better torque.

Sylvain Ract

Current through ball bearings – the final decision

Throughout the beginning of the project we have encountered various results to our endeavors of throwing current through ball bearings.

We have tried a week ago to fuel the gumstix (see our related post of 12/03/12) through the biggest of our bearings. (1 cm of diameter for its internal ring) But the mean value of the current traversing the bearing was close from zero. We concluded that this bearing was not designed to transmit current.

Then we decided to try with the smaller bearings, those that we used in the experiment related in the post of 22/02/12, in which we managed to send a signal.

But these bearing are to narrow to go around the rotor of our ventilator.

So we came back to an experiment with a 12V engine, quite similar to that of the 22/02/12 but we soldered a wire across the two bearing for a greater stability.

 

We send a 9V CC signal (generated with a battery) trough the two bearings and we measured the tension between the poles of the battery.

There are still some problems related to the crocodile clips that we used but if we remain careful we managed to obtain this result. The tension received has a non null mean value. It varies with the speed of rotation from 9 to 4V. There are still a lot of noise with a characteristic period of 500µs.

So we decided to observe the result through the pole or a RC circuit with a characteristic time of 100µs. ( R= 100Ohms and C=1µF )

The result totally correspond to what we expected, we transmit a signal of 4,5 V (a half of the initial value) at a speed of rotation of 1200 rpm. (measured with audacity as in the post of the 12/3/12).

 

We conclude that we will use this way to feed the card and these bearings. So we will have to adapt a rotor to the size of their internal ring.

We will send a 12V CC signal and our last calculus lead to a consummation of almost 10A. RoseAce is reade to shine!

Sylvain Ract

Rose Ace : My computer is running at 1000rpm – Strikes back

Here is a new version of our experimentation with some points corrected.

First we balanced the blades by putting one battery on each blade.

We had problems to connect in Wifi. Indeed we realized that the channel we chose randomly (the 7th) was the most occupied. We switched on the 4th channel and communication was much easier.

Flx© also eased the experimenting protocol by writing a tiny sh script that kills NetworkManager just after booting.

Then we had problems with our batteries again; tomorrow we will try to feed the board through ball bearings.

But we were able to lauch the experimentation:

We launched a scp of movie from a pc to the board. The transfer rate grew stable to 2.5 MB/s.

Then we started the rotation, the rate dropped to 2 MB/s but then remained stable.

We mesured the rotation speed by recording and analyzing the sound of a paper sheet striking the blade: We were turning at 12 rotations per second so 720 rpm.

 

The first conclusion is that in the worst case, we will be able to transfer informations using WiFi on our blade up to several Mb/s.

 

Now we have to improve the experimentation:

-if we use a scp, the flow may be slowed by other parameters. We are going to try to get a file from the internet.

-we have problems with our batteries so we are going to feed the board with ball bearings (the rotor is connected to the ground).

Sylvain Ract

RoseAce has dirty hands

We are still discussing the point that we will use a wireless transmission or not in order to send power and information from the static card to the blade.

Tonight we tested whether we could send information (and until which frequency) trough ball bearings. We used an engine (12V up to 5500 tpm) on which we attached to ball bearings. We sent a square signal to the outer ring of the first one. It is then supposed to reach the inner ring (that turning with the engine) then to follow a metal stack until the second ball bearing and to cross it from the inner ring to the outer ring and then to be read on the oscilloscope. (and to be compared with the original signal). Up to a frequency of 1 Mhz for the signal, it is perfectly transmitted.(in the condition that we do not have to much vibrations due to the queer rotor) At 10 Mhz (the maximum allowed by our generator in this experimentation) the signal is modified but we can still recognize the information.

The operating condition were definitely not the best as we could obtain moreover we sent information through two ball bearings instead of one. The conclusion is that, at least for sending power, and up to a frequency of 10MHz, transmitting through ball bearing can be a solution.

 

Sylvain Ract

Might fire have been discovered twice?

That’s not very pleasant to discover that what we expected to do – a POV display that can be plugged on VGA just like a screen – has already been done.
Moreover in a bright way by this team.

Actually I right now feel like that.

Well these German people did pretty good job, let’s do better!

Sylvain Ract