How To Get Started in Robotics

Overview
There is no one right way to get started in robotics. Here are a few things to keep in mind as well as pointers to some potential starting places.
Robots can do all sorts of things. What is it about robots that interests you? Once you have an idea of what you want to do in robotics, or what sort of robot you want to create, break your large goal down in to smaller steps. Before you can make a robot waiter that is able to navigate a crowded party, converse with people, and serve your guests drinks, you will need to make a robot that can move.
A lot of beginner robotics kits are small. Small robots are less expensive, easier to work with, and less likely to roll over your cat.
When most people think of robots, they think of mobile robots. Mobile robots are a great place to start because they are fun and many kits exist to help you get started. However robots can also be stationary such as robotic artworks and sculptures or robotic devices that accomplish a task for you. Keep an open mind and don’t limit your creativity.
Robotics combines computer science, mechanics, and electronics (just to name a few).
Because there are such a variety of fields that make up robotics, you have different options of where to begin. Many kits and robotics programs focus on the mechanical design of the robot. However if you are more interested in designing control programs
and behaviors for your robot, you might consider purchasing an assembled robot or a very simple kit. The suggested starting places described below are grouped based on your area of interest. You can also see a larger and more detailed list of robotics references under the resources section.

The Lego Mindstorm platform is commonly used in middle school, high school, and college level robotics education. One easy way to introduce robotics to your school is to join an existing competition such as Botball or FIRST LEGO League for middle school;
FIRST Robotics Competition or FIRST Tech Challenge for high school; or RoboCup for
college. Some of these competitions use Lego and some use other platforms.
I want to invent new robots.
Web sites such as Lynxmotion, Acroname, and the Robot Store offer a wide variety of
robot parts as well as kits and instructional materials.
I want to build a robot kit.
There are many robot kits available for varying prices and skill levels. Here are just a few
sites where you can purchase kits:
http://www.robotstore.com
http://www.hobbytron.com/RobotKits.html
http://www.superdroidrobots.com/shop

I want to buy a programmable robot.
The Create and Garcia robots come fully assembled and include various sensors. The
Create with command module is programmable in C. Garcia is programmable in C, C++,
or Java.
The TeRK robot platform offers programming at the iconic scripting, beginning Java
programmer, or advanced programmer level. You can build your own robot or follow
step-by-step instructions to make a simple robot. CMUcam3 is a programmable embedded vision platform which can be used to create simple robots.
Microsoft Robotics Studio can be used to program simulated or real robots.
I want to compete in a robot competition.
Botball or FIRST LEGO League for middle school; FIRST Robotics Competition or
FIRST Tech Challenge for high school; or RoboCup for college. There are also various
mini-sumo competitions.


Robots & Robot Kits
There are various robot kits on the market. These kits are a good first step for someone with no robotics experience. They can give you experience building and/or programmingsimple robots.
CMUcam3 http://www.cmucam.org
CMUcam3 is a programmable embedded vision platform that can be used to create simple robots.
Garcia http://www.acroname.com/technology/104/abstract.html
The Garcia robot comes assembled and ready to program in C, C++, or Java.
iRobot Create with Command Module
http://store.irobot.com/family/index.jsp?categoryId=2591511&cp=2600059

Kits
Many simple robot building kits are available on the market. A few of these kits also
allow you to program the completed robot. Here are just a few sources:
http://www.robotstore.com
http://www.hobbytron.com/RobotKits.html
http://www.superdroidrobots.com/shop

Robotic Documents

Handout 1 Robotics Toolbox for MATLAB rel3 (pdf) Robotics Toolbox for MATLAB rel6 (pdf)	Handout 2 Robot Manipulator Prototyping Complete Design (pdf)
Handout 3 Robotica User Manual (pdf)	Handout 4 Three Link Robot Manipulator (pdf)
Handout 5 MathTools on the Net (pdf)	Handout 6 Types of Robotic Simulators (pdf)
Handout 7 Nonlinear Adaptive Control (pdf)	Handout 8 Designing & Building a Robot Manipulator
Handout 9 Competition Challenge & Motivation (pdf) Resons to include Robotics (pdf) Robots in Curriculum (pdf)	Handout 10 Baps lives in Delft (pdf) Life might be better (pdf)
Handout 11 An Article from Express (pdf) Makeover in Robotics (pdf)	Handout 12 SW package for RRR Robot (pdf) Vector Analysis (pdf)
Handout 13 A Robotics Toolbox (pdf)	Handout 14 Nonlinear Control of Manipulator (pdf) Trajectory Generation (pdf)
Handout 15 SIR-1 User Manual (pdf)	Handout 16 Robo Ware Manual (pdf)

Human-Robot Interaction

The field of Human-Robot Interaction is extremely diverse: researchers from Engineering, Computer Science, and Psychology must all work together to produce strong research.

This diversity produces difficulties, as researchers struggle to find common ground for methods and language, often prompting the question of whether the field of HRI is a “field” at all, and whether there is enough commonality to hold together the research community.

We argue here that HRI is a field, but without a universal set of common characteristics. Instead HRI should be viewed in terms of three major areas which contribute strongly to the research and methods used.

RESEARCH AREAS

HRI can be viewed as the intersection of Engineering, Computer Science, and Psychology1. What makes HRI distinct is that all HRI research involves at least two of these general fields. The development of complete systems requires integration of work from each of the fields, but most work occurs within specific intersections.

a) Embodied Cognition (Computer Science & Psychology): One major area of HRI focuses on building computational systems which mimic the cognitive and affective facilities of people. Examples include the intelligence in affective robots which are capable of showing emotion and social robots which are capable of recognizing the emotions and mental states of the people they interact with. Research in this area uses results from Psychology regarding how people understand one another, and also on computational methods for modeling these cognitive facilities. It uses many tools from artificial intelligence and machine learning, but with a stronger emphasis on the embodied nature of the systems (which provides stronger constraints on the inputs of the system, as well as appropriate failure modes and other issues).

An example of work in embodied cognition is that of El Kaliouby [3] and also Rani [8] in estimating cognitive and affective mental states. Another example is that of Gold and Scassellati [6] in developing a robot which recognizes its own body motion.

b) Human-Robot Factors (Psychology & Engineering): The Human-Robot Factors area of HRI focuses on designing robotic systems and understanding how people respond to them. This includes the physical design of robots (such as humanoid vs. non-humanoid designs) as well as the design of control software for robots (as in interfaces for search and rescue robots or military robots). This area may make heavy use of methods from Communications and Human-Computer Interaction studies. One key application in Human-Robot Factors is Urban Search & Rescue [2]. Much of USAR research aims to develop better interfaces for controlling robots. Also in Human-Robot Factors are human response studies such as those of Broadbent et. al. [1]. Human-response studies look to discover what types of robot behavior and design elicit the most desirable social responses from people.

c) Robotics (Engineering & Computer Science): The final area is traditional Robotics, focusing on developing new tools for robot platforms, including both hardware and software capabilities. There is clearly less emphasis on the human (though many robot designs are inspired by people), as the focus is on building the robot and the control software which researchers in other areas of HRI can use. Some common types of Robotics research involve the design of controllers for complex motion (such as walking for legged robots or control of robotic appendages) and development of localization and mapping algorithms.

d) Integrated Systems: There is a fourth area of intersection, where all three areas come together. The goal for HRI is ultimately to develop complete cognitive robotic systems, informed by the principles of Human-Robot Factors, from the ground up. To build these systems requires co-operation between all areas of HRI.

Robot Constructor

Choose a zone for which you'd like to build the optimal robot. We suggest you start with one of the pre-set zones.

Study the hazards and obstacles in the zone to see what your robot will have to deal with. Now, construct a robot capable of collecting all the gold cubes without running out of energy or suffering too much damage. You should choose sensors to enable the robot to detect hazards and energy sources, a means of powering the robot, a form of mobility appropriate to the zone surface and finally, choose a construction material to minimise damage to the robot or make it more energy efficient.Click to find out more about sensors, POWER, MOBILITY and MATERIALS.

Try your robot in the Test Zone. If you haven't designed your robot with the right components, it may run out of energy, sustain too much damage or run out of time in which case you can return to the Robot Constructor to change the design and try again.

When you've mastered all of the pre-set zones, you can build new zones or edit existing ones from within the Zones screen. New zones can be saved to your own computer, or if you decide to publish your zone it could be made available for others around the world to download.

Robot Programming

The greatest force of robots is their flexibility, their ability to rearrange for new production and their large movement range. Utilization of the robot's flexibility presupposes effective programming. The robot programming can take place in two principally different ways: on-line or off-line. In On-line programming the use of the robot and equipment is required, whereas off-line programming is based on computer models of the production equipment. Both these methods have advantages and disadvantages. In this section we will take a look at how the two methods can be combined.

On-line programming

On-line programming takes place at the site of production itself and involves the workcell. The robot is programmed with a teach box. On-line programming has the following advantages and disadvantages compared to off-line programming:

Advantages Easily accessible.

Disadvantages Slow movement of the robot while programming. Program logic and calculations are hard to program. Suspension of production while programming. Cost equivalent to production value. Poorly documented.

The most significant advantage of on-line programming is that the robot is programmed in concordance with the actual position of equipment and pieces. Contrary, the most significant disadvantage is that it occupies valuable production equipment.

Off-line programming

Off-line programming takes place on a computer and models of the workcell with robot, pieces and surroundings are used. The robot programs can in most cases be created by the reuse of existing CAD data so that the programming will be quick and effective. The robot programs are verified in simulation and any errors are corrected.

Off-line programmering in Ropsim.

Advantages Effective programming of program logics and calculations with state-of-the -art debugging facilities. Locations are built according to models and this can mean that programmers will have to fine tune programs on-line or utilize sensors. Effective programming of locations. Verification of program through simulation and visualization. Well documented through simulation model with appropriate programs. Reuse of existing CAD data. Cost independent of production. Production can continue while programming. Process support tools for instance selection of welding parameters.

Disadvantages Demands investing in an off-line programming system.

The biggest advantage of Off-line programming is that it does not occupy production equipment, and in this manner production can continue during the programming process. By far the largest proportion of robots are today being programmed on-line. This is mainly due to the fact that off-line programming has had a very high burden rate and demanded the need of expert users.

Advanced off-line programming tools contain facilities for debugging and these assist effective programming. The programming tools support utilization of supporting tools for the programming process, for instance optimization of the welding process.

The robot off-line programming and simulation system Ropsim takes costs to an attractive level and runs under Microsoft Windows with well-known present-day user interface.

Hybrid programming

By utilizing the advantages of both of these methods the programming technique can be optimized. This is generally referred to as hybrid programming. A robot program consists mainly of two parts: locations (position and alignment) and program logics (controller structures, communication, calculations).

The program logics can effectively be developed off-line as effective debugging and simulation facilities are available here. The major part of movement commands can be created off-line by the reuse of CAD data and by interaction of the programmer.

Movement commands to locating the placement of the piece in the robot's workcell can be programmed on-line if need be. In this manner both method's advantages can be utilized. By using both of these programming methods an increased flexibility can be achieved in production.

If we let the constructor off-line program the robot's working of the piece the constructor's knowledge of the product properties can be utilized. Often, however, the constructor has no knowledge to the actual placement of the piece in the production cell.

If we let the robot operator on-line program the precise placement of the piece a faster rearrangement is achieved. The on-line programmed points are used for adjusting the program that the constructor made and in this way the robot can work the piece.

The usage of hybrid programming is a very practical way of increasing flexibility in production and thereby increasing the effect of robot manufacturing. In the same manner rearrangement time can be substantially reduced, allowing for cost effectiveness in production of even small batches.

Example of hybrid programming

The following is an example of a typical welding task in which the product is placed at an appropriate location in the workcell and the robot carries out a number of weldings. The flow of work for the programming is according to the open system model ^[1], illustrated in figure 1.

Design Planning Production

The product has been constructed in a CAD system Off-line programming in Ropsim Welding by Robot.

Figure 1. Open system model

The product model including support positions for programming is created in the Cad system and imported in Ropsim. The Off-line programming part consists of the following activities:

Placement of locations (position and alignment) that the robot shall move according to. The movements of the robot are determined by the process and the limitations of the robots movement range together. Determination of movements and sequence.

Program code generation for robot specific languages such as Reis robot language.

Program verification and debugging. In this part simulation, 3D visualization and other tools are used. The simulation runs through the determined movement sequences after which any errors are corrected.

After the verification of the robot program in the simulation the program is downloaded to the robot. On-line programming is used to adjust an appropriate number of locations. These adjustments can be avoided if the piece has not been relocated further than the sensors can handle.

The robot program then uses the adjusted locations and moves the off-line programmed task to it's correct place.

Screenshot from Ropsim

[1] Trostman E., Conrad F., Trostman S., Nielsen L.F. (1992) Robot Off-line programming and simulation as a true CIME subsystem. IEEE International Conference on Robotics and Automation.

Conclusion

The right combination of programming methods allow for a very effective programming and a quick rearrangements of production. An up-to-date developers environment such as Ropsim supports the usage of a combination of on-line and off-line programming techniques.

The cost of on-line programming is equivalent to the production value, whereas off-line programming has no expenses other than that of a programmer and the off-line programming tool. As production value is likely to be somewhat higher than that of off-line programming more time can be used in planning supported by off-line programming than is possible with on-line programming.

In most cases off-line programming is much faster than on-line programming, leading to substantial cost reductions by using off-line programming.

The correct combination of on-line and off-line programming therefore leads to cost reductions in production adjustments. This implies that the limit of when a production adjustment is remunerative is moved considerably. Or, to put it in other words, production simply becomes much more flexible.

Programming for Robot Controller

A robot controller consist in a set of functions that are compiled and linked with the rest of the simulator objects. The most important of these functions is the usr_step that, when the robot is running, is called at each time slice. This function should implement the control rule for the robot, or what is the same, give a set of low level commands to be executed next. Observe that the effects of these low level commands are not observable until they are actually executed and this happens just after the usr_step routine concludes.

Each robot controller is contained in a private directory. This directory must contain a header file (user.h), a program file (user.c), and a compilation rule file named dependencies that enumerates the modules used by user.c. The program file user.c must define at least the following set of functions:

• usr_init: Called when the simulator is started.
• usr_reset: Called each time the simulator is reset.
• usr_step: Called once at each time slice if the user controller is enabled.
• usr_close: Called when the simulator is closed.

All these function receive as a parameter a robot object (the one to be controlled) and a user definable type t_user that can be useful to store parameters or the state of the controller in a given time slice. This type is defined in user.h and the functions to manipulate it should be provided by the user in the program file user.c. The functions to manipulate the robot object are detailed in section 3.2.

The user_skel directory provides an empty controller that can be useful as a base to fill in when a new controller wants to be defined.

To compile a new controller you can use:

compile directory_name

where directory_name is the name of the directory containing the controller to be compiled.

To run the simulator with the currently included controller just type

The Object

A legged robot has a body and four or more legs. The body shape can be described as a polygon in the X-Y plane of the robot's reference frame sweeped along an interval in the Z axis. In our simulator each leg has three degrees of freedom (dof) and the same structure for all robots. However, some parameters of the leg structure (size, joint bounds, ...) can be instantiated for each robot. Each one of leg degrees of freedom is controlled by an independent motor. The most elementary method to move a leg is to command an angle directly to one of these motors. If this angle is inside the user provided bounds, the motor instantaneously moves to the desired angle (we assume that motors can move at any speed). However, the angular form of control is not intuitive (for instances, to move a leg along a straight line at least two motors have to be properly coordinated). For this reason, we provide functions to command each leg in two Cartesian frames of references (see figure 3.1): the leg one (particular for each leg) and the robot one (common for all legs). Additionally, methods are provided to get leg positions in another two frame of references: the world one and the reference one (defined from the reference positions).

The reference position of a leg is the preferred position for that leg. This position normally correspond to the central position of the leg workspace (i.e. when all angles are set to zero) but the user can choose it to be a different one. The reference frame or reference is a Cartesian frame of reference placed in the center of gravity of the polygon conformed by reference positions (see figure 3.2). This frame of reference is only used to evaluate tensions (see section 2.1.6).

To easy even more the leg movement control, we have included two high level methods to move a leg. The first one moves a set of legs in a coordinated way (applying to all of them the same transformation expressed in the robot's reference frame). This coordinated movement of legs is what we called a gesture [4]. The other high level function to move legs allows to move a leg to a given position in a given time (expressed as a number of time slices to achieve the final position).

All robot models are equipped with touch sensors at feet (that detect contact with the ground in any direction) and two inclinometers (one aligned with the X axis of the robot and the second aligned with the Y axis). Optionally, a robot can be provided with a camera. If this is the case, the simulator shows and additional window displaying the images provided by the camera. The pan and tilt of the camera can be queried and modified with the appropriate functions described below.

Robot Operating System

What is DROS?
DROS stands for Dave's Robotic Operating System and it is basic software modules needed for robotics. At the moment, the framework consists mainly of support functions for modular programming and modules for mobile robots. However, in the future the scope should expand and, of course, contributions are most welcome. DROS is open source and is distributed under the GNU Public License. This license was chosen because we want to advance the progress of robotics research and would like people all to contribute to the science of robotics by releasing their code.

June 25, 2007: DROS-0.98 released

Latest DROS release at http://www.dros.org/download/DROS-0.98.tgz. Added more vision routines. Added some old vision and localisation research. Added more hardware interfaces to HAL. Added more interfaces to robots. Changed some directory/file locations. Fixed many compling errors/warnings and bugs. DROS-0.98 has 358,344 lines of code, according to sloccount.

April 6, 2007: DROS-0.96 released

Latest DROS release at http://www.dros.org/download/DROS-0.96.tgz. Added Monte Carlo Localisation algorithms. Added ServoToGo driver. Added USB Missile Launcher and USB Circus Cannon drivers. Added USB joystick command line program to control one, two or four motors, locally or over the network using UDP packets, via the parallel port PWM and encoder kernel driver. Added parallel port PIC microcontroller programmer. Added PIC microcontroller library to control devices such as motors, servos, LCD (HD44780) and communicate via serial (RS232) and USB2.0 (ISP1581, currently still under development). Added (some) vision research work. Fixed some minor bugs. DROS-0.96 has 251,514 lines of code, according to sloccount.

February 18, 2005: DROS-0.94 released

Latest DROS release at http://www.dros.org/download/DROS-0.94.tgz. Added the DROSImage class and image processing library. Added characteristic polynomial calculation for matrices. Added polynomial functions and root finding functions (general and for polynomials). Added many matrix functions. Added (some) support for Darwin. Add VideoLogger for logging video streams. Improved support for Special Robotics Mode in the SICKLaserServer. Added parallel port PWM driver and encoder driver. These allow ('poor mans') control of robots using the parallel port.

April 23, 2004: DROS-0.90 released

Latest DROS release at http://www.dros.org/download/DROS-0.90.tgz. Changed GCEventLoop to use DROSPIHelper. Added per object debugging control. Significant improvements to how the SuperLocaliser deals with clients that want both world and robot pose data. Improved SuperLocaliser delivery of pose data. It now predicts forward in time a bit to keep clients informed (if the real data is not available). Huge improvements to the PathPlanner - now gives updated estimates of the plan in robot coordinates (I think that it wasn't before). Improved the transmission of the plan too, so that it is possible to get the start point. Updated DROSInterface to use this info. DROSInterface also now can draw the plan in robot coords. DROSInterface now draws the world circles (poles) from the map. Added video drivers for Firewire (Firewire appears pretty dodgy under Linux) and started Video4Linux drivers. Fixed/improved timestamping issues with odometry. Updated docs to indicate which programs/packages DROS requires for installation.

January 13, 2004: DROS-0.81 released

Latest DROS release at http://www.dros.org/download/DROS-0.81.tgz. Fixed running doco and made a mkrelease script to munge doco and GlobalConfig search paths. Should make releasing a more automated process and running less of a brain strain.

January 9, 2004: DROS-0.80 released

Latest DROS release at http://www.dros.org/download/DROS-0.80.tgz. This is a significant step forward in usability for DROS. Fixed hostname bug in TCPSocketServer. Fixed minor search path bug. Refactored MobileRobotMain, LaserServerMain, SuperLocaliser, LaserPoseTrackerPoly, PathPlanner and DWAPlanner to be more self-contained. Implemented Monolith - a single-process version of DROS. Started Bumper, IR and Sonar support for XR4000. Added CameraServer for serving images. Improved Packer for dealing with large payloads (without unnecessary copying). Fixed bugs in DROSServerClient. Changed NameServer and many processes to work better on a computer without a network. Updated running instructions.

November 22, 2003: DROS-0.50 released

Latest DROS release at http://www.dros.org/download/DROS-0.50.tgz. Added to SuperLocaliser ability for requests to wait for new data if the wait should only be short (pending requests). Fixed major timestamping bug in SuperLocaliser. Fixed another timestamping bug in LaserPoseTrackerPoly. Added timestamping test program. Added maxrange to LaserProxy (and support to LaserServer) so that one can tell if a reading is a valid reflection or not (use method ValidReading in LaserProxy). Note that this change means that old versions of LaserProxy will not work with new versions of the server. Added search path for files that are required by processes (currently there are a few processes that require files). Ideally, I'd prefer not to use files, but the use of files should be easy. Added C version of DROS debug macro. Prefer this over the C++ version in future. Made the simulated laser server more efficient. Added better timestamping to serial data from the real SICK laser scanner (not tested yet, should consider a variable formula, based on bytes before the last one and baud rate). Started Monolith - monolithic version of DROS.

October 26, 2003: DROS-0.45: released

Latest DROS release at http://www.dros.org/download/DROS-0.45.tgz. Added Analysis directory, at the moment, includes 2D line-fitting. The plan is for all non-specific data analysis to end up there. Changed laser server to use more efficient messages and to transmit max scan range (so that measurements with no reflection can be rejected). More documentation. Fixed bugs in SICKLaserServer when replaying recorded data. Added HAL object for replaying recorded laser scanner data. Made SocketChannel more tolerant to interruptions caused by signals.

May 21, 2003: DROS-0.41: released

Quick bugfix release of DROS at http://www.dros.org/download/DROS-0.41.tgz. My recently developed intensity code for the SICKLaserServer had bugs (features, limitations, etc..) for non-intensity mode. If a client asked for intensity data in non-intensity mode, it just got nothing. This has been fixed.

May 20, 2003: DROS-0.40: released

I'm pleased to announce a new release of DROS at http://www.dros.org/download/DROS-0.40.tgz. Added ability to control multiple localisers to SuperLocaliser, includes concept of getting lost and un-lost. Added support for reflectivity/intensity information to the SICKLaserServer and LaserProxy. Also displays intensity with DROSInterface. Discovered bug in the event loop/blocker interaction. Can be problems with using blockers when there are multiple events occurring at the same time and one of them calls a blocker. A major rewrite of the EventLoop is planned. In the meantime, need to be careful with Blockers, preferably avoid using them. The current implementation of SuperLocaliser chews CPU time after 24 hours of running and data.

March 31, 2003: DROS-0.30: released

After another long delay (Christmas, too many papers for IROS), I'm finally able to announce a new release of DROS at http://www.dros.org/download/DROS-0.30.tgz. Major changes to Blocker/GCEventLoop - tidied this all up and it now is much easier to understand (and more correct too :-)). Added reconnection to a number of proxies and processes. Fixed some bugs that had crept into the DWAPlanner, making robot motion broken. Fixed a number of memory leaks and uninitialised variables. Added BlackBox (i.e. flight recorder) for logging of events.

January 30, 2003: DROS-0.25: released

After a long delay (problems with hosting service), I'm finally able to update the web pages and announce new releases of DROS. Next release of DROS at http://www.dros.org/download/DROS-0.25.tgz. Major changes to NameServer, ComponentBase, DBManager, Executer and StateManager. MobileRobotServer can now reload the xrm module as a work-around for firmware bugs. Added non-blocking connection methods. Added reconnection to NameServerProxy, MobileRobotProxy and LaserProxy.

November 7, 2002: DROS-0.21: released

Next release of DROS at http://www.dros.org/download/DROS-0.21.tgz. Bug fixes in: NetTools (malloc'ed insufficient space), another problem of packing signed chars in Packer.pm, fixed SICKLaserServer bug.

October 17, 2002: DROS-0.20: released

Next release of DROS at http://www.dros.org/download/DROS-0.20.tgz. Added DROSPIHelper to help with ProgInterface command processing. Added examples of Packer usage to the documentation. Documentation of namespaces (under development). Bug fixes in: Packer (short and long ints). Added ability to mirror servers (in a rate-limited fashion) to LaserServer and SuperLocaliser.

September 23, 2002: DROS-0.19: released

Next release of DROS at http://www.dros.org/download/DROS-0.19.tgz. Fixed some bugs: packing signed chars in Packer.pm (perl 5.8.0 spews warnings, GCEventLoop mem leak, lots of work going on behind the scenes.

September 2, 2002: DROS-0.18: released

Next release of DROS at http://www.dros.org/download/DROS-0.18.tgz. Documentation update - included screenshots and goals of DROS. I've been working hard on a number of things that will eventually make it into DROS but are not quite ready yet.

August 2, 2002: DROS-0.17: released

Next release of DROS at http://www.dros.org/download/DROS-0.17.tgz. I've improved the NameServer, should now run better on machines which can't look up their hostname. Also fixed the position of the laser scanner relative to the robot. Pose tracking works much better now. DROS-0.16 had a bug in the DROSInterface (hardcoded my own IP address here! DOH!).

July 12, 2002: DROS-0.15: released

Next release of DROS at http://www.dros.org/download/DROS-0.15.tgz. This release dramatically improves DROSInterface. Also, running DROS should be easier.

June 13,2002: DROS-0.11: released

Next release of DROS at http://www.dros.org/download/DROS-0.11.tgz. This release fixes bugs in the makefile system. Hopefully things will compile better now.

June 11,2002: DROS-0.1: Initial release of DROS source code

The initial release of DROS source code is at http://www.dros.org/download/DROS-0.1.tgz. This release contains a modular programming environment as well as modules for mobile robot control.