caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Axel Poigné" <poigne@gmd.de>
To: "Rafael 'Dido' Sevilla" <sevillar@team.ph.inter.net>
Cc: Caml List <caml-list@pauillac.inria.fr>
Subject: Re: [Caml-list] Playing Soccer with OCaml
Date: Thu, 08 Nov 2001 09:31:39 +0100	[thread overview]
Message-ID: <B810017A.3AFB%poigne@gmd.de> (raw)
In-Reply-To: <20011031100150.A28924@team.ph.inter.net>

Dear Rafael

> In order to implement a subsumption architecture in OCaml you would
> probably need to use the threads library to make one thread for each
> behavior you wanted to make the robot perform, and two more threads to
> get inputs from the robots sensors and arbitrate the access of behaviors
> to the robot's actuators.

Programming robots using threads is notoriously bad idea. More or less all
the robots I know of, and, in fact, the hard real time part of most embedded
systems are implemented using one execution loop only, "synchronously" to
use a more technical term. The loop works as follows: read the input
(sensor) data, compute the "state change" (decoupled from the environment),
write the output (actuator) data. The rationale is to obtain deterministic
behaviour of course depending on the input. Since input is somewhat "fuzzy",
in particular for autonomous robots with all kinds of sensors involved, one
at least wants to understand what the software does. In particular one wants
control behaviour to be reproducible. I believe that complex threading does
not necessarily contribute to these goals. To be explicit: I have seen a
couple of robocup robots just doing nothing because of a deadlock with
regard to threading.

Without wanting to raise a flame, I believe that ocaml is not particular
well suited to generate code of the characteristics described above.
Further, much of the power of ocaml is in the sophisticated structuring
mechanisms for data - that are quite useless in robotics where most data are
elementary, and must be: anything with a touch of recursion is devasting for
real-time applications, deadlines then depend on size of data.


Axel Poigne

PS. Though subsumption was an advancement more recent approaches try to fuse
behaviours in a more sophisticated way.

PPS This may considered as a reaction to the recent mail of A Joseph Koshy
as well

------------------------------------------------------------------------
Dipl.Ing. Dr.rer.nat. Axel Poigné       http://www.ais.fraunhofer.de/~ap
                                        mailto:poigne@ais.fraunhofer.de
Fraunhofer AiS                          Tel: (+) 2241 142440
Schloss Birlinghoven                    Fax: (+) 2241 142324
D-53754 Sankt Augustin
Germany 

------------------------------------------------------------------------
Have a look at our new language for designing Embedded Software

sE = Java + synchronous Languages  (http://www.ais.fraunhofer.de/~ap/sE)





-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr


  reply	other threads:[~2001-11-08  8:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-29 17:39 Kai Kaminski
2001-10-29 18:20 ` Alan Schmitt
2001-10-30 12:17 ` Xavier Leroy
2001-10-31  2:01 ` Rafael 'Dido' Sevilla
2001-11-08  8:31   ` Axel Poigné [this message]
2001-11-07 16:11 Damien Doligez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B810017A.3AFB%poigne@gmd.de \
    --to=poigne@gmd.de \
    --cc=caml-list@pauillac.inria.fr \
    --cc=sevillar@team.ph.inter.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).