From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7d3530220610271019k5d94854cpdb3a0f2de7bb3328@mail.gmail.com> Date: Fri, 27 Oct 2006 13:19:44 -0400 From: "John Floren" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [9fans] Plan 9 Robotics Article Topicbox-Message-UUID: d7a07588-ead1-11e9-9d60-3106f5b1d025 I've just finished writing an article for a small robotics weblog (http://gameboysandrobots.com); I'm sending it here so anyone interested in using Plan 9 in robotics can read it, and so people can point out glaring errors before I post it. (I'm not too terribly familiar with all the workings of Plan 9, so if you see something I've got really wrong, please let me know). Article follows: Plan 9 (http://9fans.net) is an experimental operating system from Bell Labs. It hasn't seen very much use outside of a few government and university research areas, but it presents promising possibilities for robotics. The Plan 9 O.S. is based on the idea that *everything* should be a regular file somewhere. When a user wants to connect to an ftp server, he uses "ftpfs", which connects to the server and then makes it look like it was part of the local filesystem, allowing the user to utilize the regular Plan 9 commands on the files instead of having to download them through an ftp client. Network connections are created and maintained by reading and writing to one file, /net/tcp/15/ctl for instance; data is sent and received on that connection by reading and writing /net/tcp/15/data. Plan 9 is also a highly network-oriented OS--it is common and even expected that the Plan 9 machine will be on a network, so the system is built from the ground up with networking in mind. As a result, a lot of work went in to making Plan 9 transparent over a network. It is possible to import parts of another machine's filesystem, easily pipe output between programs on various computers, and more. This idea in particular was used in the Styx-on-a-Brick project; using Plan 9 protocols, developers wrote code that allowed them to directly access devices connected to a LEGO Mindstorms RCX brick. They were able to simply import the brick's filesystem, where they saw the motors and sensors represented as normal files. By reading from and writing to these files using basic UNIX operators (echo and cat), they were able to use the devices without the usual tedious work of writing an entire Not-Quite-C or LEGO code program, compiling it, and uploading it. You've probably already seen some of the potential of Plan 9. It is a rather simple system, designed to be clean and functional. Its extensive integration of networking makes it ideal for a robot involving more than one computer. As the Styx-on-a-Brick project shows, it is easy to make drivers to directly interface with hardware; other software exists that provides a similar interface (text files) for serial GPS units. Let's imagine, if you will, a possible robot designed using Plan 9: We'll keep it simple, so this little autonomous robot will have only two computers in it: one small, low-powered one to interface with a LIDAR unit, and one more powerful machine to handle the motors and a GPS device. These computers are connected to each other via an ordinary ethernet connection. Now, using code that you've written, the LIDAR processor will read in data sent by the LIDAR unit and present it as a series of distances in a file somewhere. Other code then regularly grabs the data from that file and converts it to a simple image, using colors to represent distances. Your central computer, in the meantime, is using gpsfs to keep track of its current position and is controlling the motors through an interface like that of Styx-on-a-Brick (you could even use another little computer to just handle the motors, if you want). The central computer imports that part of the LIDAR computer's filesystem that stores the distance image and grabs it every second or so. The central computer then processes the LIDAR and GPS data and decides where to go next, then simply writes the correct speeds and directions to the motor control files. The idea here is to use the code already written into Plan 9, so you can spend more time developing algorithms. All you would need to write is a LIDAR driver and a motor driver, both of which would need to be written on any software platform. In conclusion, Plan 9 offers a possible way to cut down on the frustration and time involved in coming up with fancy ways of making your separate computers and devices talk--the idea is to make everything a file, and be able to import all of those files over the network. Although it is currently very sparsely used in robotics, Plan 9 has a knowledgeable and helpful community ready to support any such projects. ****ARTICLE ENDS**** Well, looking forward to any feedback, positive or negative. I'd like to get this posted ASAP, so if I've screwed up terribly, please let me know. John -- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn