From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA07404; Thu, 8 Nov 2001 09:32:02 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA07649 for ; Thu, 8 Nov 2001 09:32:01 +0100 (MET) Received: from mail.gmd.de (mail.gmd.de [129.26.8.90]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id fA88W0X05237 for ; Thu, 8 Nov 2001 09:32:00 +0100 (MET) Received: from [129.26.11.172] (gemma [129.26.11.172]) by mail.gmd.de (8.9.3/8.9.3) with ESMTP id JAA01916; Thu, 8 Nov 2001 09:31:35 +0100 (MET) User-Agent: Microsoft-Entourage/9.0.1.3108 Date: Thu, 08 Nov 2001 09:31:39 +0100 Subject: Re: [Caml-list] Playing Soccer with OCaml From: Axel Poign=?ISO-8859-1?B?6Q==?= To: "Rafael 'Dido' Sevilla" CC: Caml List Message-ID: In-Reply-To: <20011031100150.A28924@team.ph.inter.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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 embedde= d 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 want= s 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 ar= e elementary, and must be: anything with a touch of recursion is devasting fo= r real-time applications, deadlines then depend on size of data. Axel Poigne PS. Though subsumption was an advancement more recent approaches try to fus= e 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=E9 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=20 ------------------------------------------------------------------------ Have a look at our new language for designing Embedded Software sE =3D 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