[erlang-questions] Semaphores

Christian S <>
Thu Mar 15 16:54:42 CET 2007


Hi, as you have good insight to robot programming. I would like to
query you about  the language http://en.wikipedia.org/wiki/Esterel
that I found interesting.  To me it screams 'robot arm control!' since
it can express FIR filters so eloquently for various automatic control
problems and can compile down to a huge statemachine in c source to
run quickly.

The programming model is parallell finite state machines that emits
signals and react to signals. It is reminiscent of erlang message
passing, only different.

I was imagining it as a component in robot programming, a high level
erlang one that deals with mission, communicating and getting alerts
from a lower level one in esterel that does automatic control for
positioning limbs as desired. The lower level can run with a high
priority to never miss a deadline. It can even run on a separate cpu
or micro controller.

Is this language (and the others in the same paradigm) discarded as
useless eye-candy, or is it one of those gems waiting to be
discovered?

On 3/15/07, Corrado Santoro <> wrote:
>
> Danesh Daroui wrote:
> > Its cool. I am interested to find out more about your solution.
> Maybe at the next EUC ;-)
>
> > It seems
> > that you have solved the problem using State Machines, but if you use a
> > server to pass messages through it, it might be the reason that message
> > passing is not fast enough as you expect. However, you said that the
> > problem is solved, but defining a channel which is accessible by all
> > processes to send their request (asynchronous or synchronous doesn't
> > matter but synchronous needs its own simulation in Erlang) to one or
> > more than one processes which handle requests. Each sender can also have
> > its private channel to get the result. Anyway, I thought sending
> > messages between processes (not in a distributes architecture) is fast
> > enough to avoid such problems. Your task must be very critical. ;)
> They are not so critical, but an unexpected latency could cause e.g. a
> wrong navigation. For example, one task is to make the robot rotate of a
> given angle: we turn on the motors and then we "poll" reading the
> current orientation. This is made by means a couple of communicating
> processes (one for interacting with the motor controller and another to
> perform rotation control): if the latencies are too high, the robot
> could overcome the target and stop with a wrong orientation.
>
> In our current implementation, there are no unexpected latencies. But,
> we experienced these problems when we used OTP behaviours (gen_fsm,
> etc.). Please note that the robot is quite fast, so milliseconds are
> important.
>
> In any case, if we have time, we'll make some measurement in order to
> give some numerical quantities!
>
> --Corrado
>
> --
> ==================================================================
> Eng. Corrado Santoro, Ph.D.
> University of Catania - ITALY - Engineering Faculty
>
> Tel: +39 095 7382380        VoIP: sip:
>
> Personal Home Page: http://www.diit.unict.it/users/csanto
>      NUXI Home Page: http://nuxi.diit.unict.it
> ==================================================================
>
> _______________________________________________
> erlang-questions mailing list
> 
> http://www.erlang.org/mailman/listinfo/erlang-questions
>



More information about the erlang-questions mailing list