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.

Overview Fish Robot

Underwater robots are widely used in the fields of ocean development, ocean investigation, and marine environmental protection. Requests for underwater operations to be carried out more efficiently have become pressing. In response, autonomous underwater robots have been planed. In fact several test robots have already been developed. The need for higher efficiency and propulsive performance essentially requires fish-like performance.

We have long been interested in the highly efficient propulsion of fish. We have attempted to apply it to underwater robots for fish-like swimming mechanisms such as the one pictured. In order to develop high-performance, intelligent underwater robots, a fish robotics study was undertaken in 1999 at the Ship Research Institute, part of the Japan Ministry of Transportation in Tokyo Japan.

Swimming methods of fish are various and interesting; they have many specialized modes of movement. For example, an eel swims waving the whole of its body and is highly adapted to an enclosed environment. A flat fish, on the other hand, swims by waving long fins in special patterns, allowing it to hover, backup or turn quickly in any direction.

In our study, we focus the focus on fish such as the pike or tuna --- fast and efficient swimmers. These fish accelerate with amazing quickness, turn easily, and attain dizzying speed all while expending very little energy. These kinds of fish move by coordinated side-to-side motion of their tail fin and tail peduncle, the part of the body just forward of the tail fin.

Robot that runs over water

Discovery news has a story about robot that runs over water. From the article:
em>A robot that can speed across the surface of water like a lizard could open the door for multi-legged amphibious robots.

The Water Runner, being developed by assistant professor Metin Sitti at Carnegie Mellon University in Pittsburgh, could search for victims in flooded disaster areas, be equipped with biochemical sensors to monitor water quality, or use tiny cameras to survey coastline security zones or ports.

Robot Intelligence

The robotic projects outlined in this book make extensive use of the PIC series of microcontroller from Microchip T echnology Inc. In addition to its ability to run programs, the microcontroller has input and output lines (pins) that are used to control motor drive systems, read sensors, and communicate. W e demand a lot from our microcontroller(s), so it’s important to have a good idea of what a microcontroller is right from the start.

What Is a Microcontroller?

A microcontroller is essentially an inexpensive singlechip computer . Single chip means the entire computer system lies within the confines of a sliver of silicon encapsulated inside the plastic housing of an integrated circuit. The microcontroller has features similar to those of a standard personal computer. The microcontroller contains a CPU (central processing unit), RAM (random access memory), ROM (readonly memory), I/O (input/output) lines, serial and parallel ports, timers, and sometimes other builtin peripherals such as ana logtodigital (A/D) and digitaltoanalog (D/A) converters. The key feature, however, is the microcontroller’s capability of uploading, storing, and running a program.

Why Use a Microcontroller?

Being inexpensive singlechip computers, microcontrollers are easy to embed into larger electronic circuit designs. Their ability to store and run unique programs makes them extremely versatile. For instance, one can program a microcontroller to make decisions and perform functions based on situations (I/O line logic) and events. The math and logic functions allow the microcontroller to mimic sophisticated logic and electronic circuits.

Programs can also make the microcontroller behave as a neural network and/or a fuzzy logic controller . Microcontrollers are incorporated in consumer electronics and are responsible for the “intelligence” in these smart electronic devices.

Designer Computers—So Many Microcontrollers

There are a large variety of microcontrollers on the market. W e will use the versatile microcontroller chips called PIC chips (or PICmicro chips) from Microchip Technology Inc.

The Compiler

There are a number of compilers on the market that allow users to write programs (code) in different highlevel languages. Highlevel language frees the programmer from wrestling with and controlling the microcontroller ’s registers when writing code and accessing the different aspects of the microcontroller’s

features and memory.

The highlevel language I use is a derivative of the Basic language. It is called PicBasic. (The PicBasic and PicBasic Pro compilers used to write PicBasic programs are products and trademarks of microEngineering Labs, Inc.) PicBasic is similar to the PBasic language used in programming the Basic Stamp series. Programming microcontrollers directly using the PicBasic (or PicBasic Pro) compiler offer two major advantages over the Basic Stamp series of microcontrollers which use external serial EEPROM for memory storage, faster program execution speed (20to 100fold increase), and reduced cost.

PIC Programming Overview

Programming PIC microcontrollers is a simple threestep process: W rite the code, compile the code, and upload the code into a microcontroller . Following is an overview of the process; stepbystep instructions will be provided in the following chapters.

Software and Hardware

You will need two items to begin programming and building microcontroller based projects and robotics. First is the compiler , either the PicBasic Pro or PicBasic compiler (see Fig. 1.1). The PicBasic Pro compiler from microEngineering Labs, Inc. has a suggested retail price of $249.95. The PicBasic compiler from microEngineering Labs, Inc. has a suggested retail price of $99.95. In addition to a compiler you need the EPIC programming board and software; this package sells for $59.95 (see Fig. 1.2). (EPIC is a product and trademark of microEngineering Labs, Inc.)

Robot Intelligence

The robotic projects outlined in this book make extensive use of the PIC series of microcontroller from Microchip T echnology Inc. In addition to its ability to run programs, the microcontroller has input and output lines (pins) that are used to control motor drive systems, read sensors, and communicate. W e demand a lot from our microcontroller(s), so it’s important to have a good idea of what a microcontroller is right from the start.

What Is a Microcontroller?

A microcontroller is essentially an inexpensive singlechip computer . Single chip means the entire computer system lies within the confines of a sliver of silicon encapsulated inside the plastic housing of an integrated circuit. The microcontroller has features similar to those of a standard personal computer. The microcontroller contains a CPU (central processing unit), RAM (random access memory), ROM (readonly memory), I/O (input/output) lines, serial and parallel ports, timers, and sometimes other builtin peripherals such as ana logtodigital (A/D) and digitaltoanalog (D/A) converters. The key feature, however, is the microcontroller’s capability of uploading, storing, and running a program.

Why Use a Microcontroller?

Being inexpensive singlechip computers, microcontrollers are easy to embed into larger electronic circuit designs. Their ability to store and run unique programs makes them extremely versatile. For instance, one can program a microcontroller to make decisions and perform functions based on situations (I/O line logic) and events. The math and logic functions allow the microcontroller to mimic sophisticated logic and electronic circuits.

Programs can also make the microcontroller behave as a neural network and/or a fuzzy logic controller . Microcontrollers are incorporated in consumer electronics and are responsible for the “intelligence” in these smart electronic devices.

Designer Computers—So Many Microcontrollers

There are a large variety of microcontrollers on the market. W e will use the versatile microcontroller chips called PIC chips (or PICmicro chips) from Microchip Technology Inc.

The Compiler

There are a number of compilers on the market that allow users to write programs (code) in different highlevel languages. Highlevel language frees the programmer from wrestling with and controlling the microcontroller ’s registers when writing code and accessing the different aspects of the microcontroller’s

features and memory.

The highlevel language I use is a derivative of the Basic language. It is called PicBasic. (The PicBasic and PicBasic Pro compilers used to write PicBasic programs are products and trademarks of microEngineering Labs, Inc.) PicBasic is similar to the PBasic language used in programming the Basic Stamp series. Programming microcontrollers directly using the PicBasic (or PicBasic Pro) compiler offer two major advantages over the Basic Stamp series of microcontrollers which use external serial EEPROM for memory storage, faster program execution speed (20to 100fold increase), and reduced cost.

PIC Programming Overview

Programming PIC microcontrollers is a simple threestep process: W rite the code, compile the code, and upload the code into a microcontroller . Following is an overview of the process; stepbystep instructions will be provided in the following chapters.

Software and Hardware

You will need two items to begin programming and building microcontroller based projects and robotics. First is the compiler , either the PicBasic Pro or PicBasic compiler (see Fig. 1.1). The PicBasic Pro compiler from microEngineering Labs, Inc. has a suggested retail price of $249.95. The PicBasic compiler from microEngineering Labs, Inc. has a suggested retail price of $99.95. In addition to a compiler you need the EPIC programming board and software; this package sells for $59.95 (see Fig. 1.2). (EPIC is a product and trademark of microEngineering Labs, Inc.)

Technology Concept Submissions to the Technical Advisory Board

Background

The Technical Advisory Board (TAB) of the Joint Ground Robotics Enterprise (JGRE) within the Office of the Secretary of Defense (OSD) is tasked with evaluating ground robotics technologies that are important to the military's mission. JGRE plans to use the Government Fiscal Year (“GFY”) 2008 TAB recommendations as guidance in forming Requests for Proposals (RFPs) to be issued for funding in GFY 2009 and beyond.

This year, for the first time, direct input will be solicited from private industry, academic institutions, and non-profit organizations for the ground robotic TAB process. The mechanism for this input will be the newly formed Robotics Technology Consortium (RTC). Members of the RTC will be able to make "Technology Concept Submissions" to the TAB.

RTC members will also be able to elect individuals from RTC member companies and organizations to serve as Industry representatives on the TAB (until now, only representatives from Government laboratories have served on the TAB). The Industry representatives will help facilitate the presentation and review of the RTC members’ Technology Concept Submissions and, together with their Government counter-parts, evaluate all such submissions, including those separately submitted by the Government laboratories. Please note that the role of the TAB is not to make decisions regarding which technologies to invest in, but rather to assess each proposed technology individually in terms of its maturity, readiness and applicability for Government purposes. All decisions about which concepts are selected as the basis for RFP's are subsequently made by JGRE based on the TAB assessments and inputs from other Government departments and agencies.

The Technology Concept Submission process and TAB review are highly compressed this year. The schedule compression is required in order to accommodate the government's timeline and the schedule needed to establish the RTC. In Fiscal Year 2009 and beyond, the election of RTC Technology Committee members and the solicitation of Technology Concept Submissions will happen at a much more deliberate pace.

Government's TAB Process

The government's TAB process for ground robotics is organized around four Joint Capability Areas (JCA's):

Force Application

Battle Space Awareness

Force Protection

Logistics

More detail on these JCA's is provided in the Technology Concept Submission form. The JCA structure reflects how the military thinks about its mission. The JCA structure also reflect how DoD funding is organized to procure new hardware and software.

It is very important to realize that the military user community does not care about "how many degrees of freedom a robotic manipulator arm" might have -- their concern is "does it help me do my mission better?" The biggest challenge for most companies that are new to working with the military will be to avoid the trap of promoting a new technical capability for its own sake. Technology Concept Submissions must instead make it clear to the military how a new technology concept can help the military perform its mission better.

Goal of Technology Concept Submission

It is also important to realize that the purpose of the Technology Concept Submission is not to promote a proprietary solution. In fact, no proprietary information can be contained in the Technology Concept Submission at all. This submission will not be kept confidential. Any information you put in the submission will be available to other members of the RTC.

The purpose of the Technology Concept Submission is to address a mission need of the military, and to show how a new technology could improve the military's mission performance in specific capability areas. The result of a successful Technology Concept Submission will be a JGRE RFP issued to the RTC that specifies the need to be met, not the specific technology for meeting it. Any and all members of the RTC can submit proposals in response to the RFP. The JGRE will select the proposal that provides the best value to the government and is most likely to meet the need identified in the RFP.

How Technology Concept Submissions Are Evaluated

Successful submissions will be technology concepts that satisfy multiple capabilities. The more generally useful and widely applicable a technology concept is, the higher it will be rated. Military users do not want to carry lots of unique tools for specific jobs. They want a few really great tools that do many jobs. The more JCA subcategories that can be (honestly) checked off as benefitting from the technology concept, then the stronger the submission.

Submissions will also be judged on how critical the technology concept would be in improving the mission performance in the indicated capability areas. Please note that it is not the criticality of the mission that is being evaluated, but rather how important the technology would be in making the JCA capability stronger. The government evaluators will look at the submission and ask, "How will this technology make me better off than I am today?"

The technology concepts must also be very specific to ground robotics. JGRE has limited resources and cannot fund all the good robotics ideas. There is definitely not enough funding within JGRE to spend resources on general applications technology. There are other funding mechanisms for that work.

JGRE is limited by its role to funding development for concepts that are between TRL 3 and TRL 6.

http://en.wikipedia.org/wiki/Technology_Readiness_Level

Development work that has not yet reached TRL 3 is funded through other mechanisms. After TRL 7 is reached, funding for further development must transition to one of the Services' Programs of Record.

A Technology Concept Submission will be evaluated higher if its technology can reach TRL 6 within three years. Because the purpose of JGRE funding is research and development, the end result of any contractual work can only be a prototype. JGRE funding cannot be used for System Design & Development (SDD), procurement, or operations and maintenance.

All Technology Concept Submissions must include a Rough Order of Magnitude (ROM) estimate of costs. In general, project awards run the range from less than one million dollars to several million dollars. Given the total level of JGRE funding in any one year, and the number of good projects to fund, it would be rare that a project that costs over $10 million would be funded.

Presenting Ideas to the TAB

During the week of May 19, the TAB will review all of the RTC Technology Concept Submissions. This review will take place on a single day, probably Wednesday, May 21. Submitters will have the option of discussing their submission with the TAB for five minutes. This interaction is intended to be a back and forth discussion, rather than a PowerPoint-style presentation.

The only presentation tool that can be used are hardcopies of a one page hand-out. No projected images, video, or flipcharts can be used. Submitters should expect to answer questions about how their technology concept applies to the capability areas that they checked off, as well as discuss what substantiates their estimate of TRL, criticality, and ROM cost.

Submitters can travel to Washington DC at their own expense in order to address the TAB directly. Otherwise, submitters may use the telephone conference call to discuss their technology concept with the TAB.

It is not necessary for the submitter to discuss the technology concept with the TAB. All submissions will be evaluated, whether or not the submitter chooses to talk with the TAB in person or on the telephone.

TAB Evaluation, RPF, and Award

Following the TAB meetings during the week of May 19, JGRE will meet separately and determine which technology concepts should be used as the basis for any RFP’s to be issued to the RTC. All such RFP's will be subject to open and fair competition amongst the members of the RTC.

The proposals that members submit will be considered propriety and will be safeguarded. Any award will be handled as a separate task order within the overall contract that the government has with the RTC.

Further Information

To ask questions and get further information, the RTC will create and publicize a Question & Answer web page, where all of the members' questions will be posted, along with answers from the RTC and/or government, as appropriate.