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.

Wireless Controlled Robot Concept

January 30, 2007 Robotics in general and consumer robotics in particular seem to be making massive headway, and a development certain to draw a lot of attention in the next month is a wireless concept robot created by industrial robotics manufacturer KUKA Robotics Corporation. The new robot will be shown for the first time at ATX West Expo in Anaheim, February 13-15, 2007. The company will be showcasing an application using a KR16 robot and KRC 2 Controller being controlled by individuals utilizing a Wii controller & Bluetooth http://en.wikipedia.org/wiki/Bluetooth technology (video here). This concept cell was designed to show the next step in the trickle down of robotic technology to consumers from the industrial robot market.

“KUKA http://en.wikipedia.org/wiki/KUKA is committed to the advancement of robotic technology in both the industrial and consumer arenas. The development of more intelligent and easy to operate robots will begin to drive the development of more capable service robots for applications such as medical and ultimately for consumer use in individuals’ homes," said Kevin Kozuszek, director of marketing for KUKA Robotics Corporation. “This concept cell is an example of the next step forward towards improved control and interface capabilities between humans and robots.”

As the consumer and service robotic sector continues to expand new technologies will be vital in the development of products designed specifically with the consumer in mind. This concept cell, developed by KUKA System Partner SEIS Group, Inc. of Huntington Beach, California, using the KUKA KR 16 robot with a Wii controller is one such example. Attendees to the company’s booth will be able to personally experience the cell’s easy to use wireless robot control capabilities.

A Different Approach to Service Robotics

1. Introduction

Service robotics, as it is widely performed today, usually assumes a given service to be carried out by a single robot or, at most, by a small group of them working together. In any case, though, the concept of cooperation is intended more in the sense of a relay race, than in the sense of an actual team effort for achieving each single task. Each robot, in other words, is assumed to be able to cope with the basic problems of autonomy alone, i.e. locating itself, navigating within its environment, and in case also planning its own future actions.

A new and totally different way is the so-called swarm robotics that, as opposed to the more traditional approach, does not necessarily assume each robot as a stand alone independent unit. On the contrary, swarm robotics assumes that a given mission is the result of a joint action of a swarm of simple units. Such units, in theory, might even be unable to perform the bare locomotion without the aid of others of their kind.

This approach finds its theoretical roots in recent studies on swarm intelligence [1], i.e., in studies of selfassembling and self-organising capabilities shown by animals such as social insects [2]. With this sort of approach, cooperation becomes of capital importance for the success of an overall mission. Indeed, since there is no predefined role, an artificial swarm (which we label swarm-bot) can be, as its counterpart in Nature, extremely robust: the function initially endorsed by a failing unit would simply be replaced by a reorganization of the whole group. Clearly, such a characteristic implies a swarm to show an overall behaviour which is both adaptive and emergent. Adaptive because it needs to change itself opportunely in order to cope with the surrounding world, and emergent because each unit (which we label s-bot) has no global cognition of an assigned mission: they simply respond to the external stimuli with specific local predefined behaviours.

In this respect, exactly as simple behaviours interacting with each other would let a more complex one emerge, a group of s-bots acting on their own locality, would be able to perform an assigned task as the result of their team effort.

It is important to notice that physical reconfiguration, though, is not the only characteristic distinguishing a swarm-bot from a more traditional service robot. Selfassembly is the other important feature. Once a task is requested, in fact, a swarm-bot not only needs to evolve constantly its physical shape until the completion of the assignment is reached (final goal), but it also needs at the beginning physically to assemble its components (s-bots) from scratch. Moreover, once the goal is achieved, the bindings holding the swarm-bot structure together would simply be released and the whole group would disaggregate and eventually reform into a different shape when a new mission is reassigned.

The aim of this paper is twofold: first introducing our project and second discussing how to apply the key characteristics of our swarm-bot, i.e., , team work, limited global knowledge, and emerging common goal, in order to achieve a service. The work is organized in the following sections: an introduction of the research context within which our research fits in (section 2), a brief introduction of our project (section 3), a more detailed description of our s-bots (section 4), a brief presentation of the 3D swarm-bot simulator developed (section 5), and a discussion of how a swarm-bot might be employed in order to carry out a specific service (section 6). Conclusions are drawn in section 7.

2 RELATED WORK

Considering the characteristics of a swarm-bot outlined above in the introduction, we could identify three research areas into which locating our concept: selfreconfiguration, self-assembly, and robot mobility.

In the first area, i.e., that of physical selfreconfiguration, researchers have put great emphasis essentially on the task of dynamical reshaping of physical structures by means of simple units [3, 4, 5].

Because the research focus in this topic has mainly been the reconfiguration itself, the aforementioned

simple units are not really entities independent from each other. As exemplified for instance in [6, 7, 8],

these units could start their evolution to a goal structure only from a physically pre-assembled configuration.

An implication, this, which implicitly pre-sets the number of structure components. A swarm-bot is, in

this respect, more powerful, since it neither assumes to start its evolution toward a goal from an already

pre-built configuration nor to have a pre-set limit of components.

As far as self-assembly is concerned, research in this area has basically just concentrated on the distributed

algorithms needed for assuming certain loose formation ([9]), or maintaining a certain loose planar geometrical shape ([10, 11]). Swarm-bots share with such a line of research the idea of exploiting local sensing in order to achieve the overall control of the group. However, the bindings among the different units within a group are in general rather loose as compared with those encountered in a swarm-bot. S-bots might, in fact, establish physical connections with each other in order to reach a target configuration. Such a characteristic allows them to extend formation geometries in theory also into the third dimension.

Concerning robot mobility, there is a great deal of research being pursued stretching from mechanics to autonomous control. Our involment with mobility, and hence autonomy, stems from the fact that our s-bot units need to gather in order to assume a certain shape. This means that they need to be capable of moving about independently when they are not joined together into a structure. The solution chosen for our s-bots has in a sense a conceptual similarity with that implemented for the wheeled JPL mars rover ([12]). The difference, however, lies in the fact that our s-bots’ locomotion subsystem is fixed to the main body, whereas that of the aforementioned rover has a variable geometry.

3 SWARM-BOT PROJECT

Having briefly introduced the context within which our research fits in, let us now present our project: the Swarm-Bot1. It is a three years pan-european research collaboration, currently in its first year, co-funded both by the Commission of the European Communities and by the Swiss National Science Foundation. Its main objective is to study a novel approach to the hardware design, implementation, and use of self-assembling, selforganising, and metamorphic robotic systems called swarm-bots. A large part of the research has so far consisted partly of feasibility studies and partly of physically implementing an initial design.

Since it is clear that hardware and control policies development go hand in hand, a 3D dynamic simulator has been under development since the beginning with the intent of using it both as a testing benchmark for the hardware design and as a tool for creating new group control algorithms. In this respect, although the project is currently still at its infancy, the particular phase we are in, here at IDSIA, is the completion of a first 3D simulator prototype which can already be used for hardware design testing and for developing distributed control policies with our s-bots. Notice that parallel phases of physical hardware construction and of definition of the controlling algorithms are also currently being carried out by the project partners at the Autonomous Systems Laboratory (LAS) of the EPFL in Lausanne and at the Institute of Interdisciplinary Research and Development in Artificial Intelligence (IRIDIA) of the University ´e Libre de Bruxelles, respectively. Concerning the other two partners, the Centre of Studies of Non-Linear Phenomena and of Complex Systems (CENOLI) of the Universit´e Libre de Bruxelles and the Institute of Cognitive Science and Technology of the Italian National Reseach Council, they are involved since the beginning in bio-inspired research experiments and in evolutionary robot control development, respectively.

Robotic Mobility Platform (RMP)

The Segway® Robotic Mobility Platform (RMP) takes the performance and engineering prowess demonstrated in the Segway® Personal Transporter (PT) and makes it available in a durable package for robotics applications. The Segway RMP is an extremely reliable and customizable transportation platform that is suitable for moving heavy payloads in tight spaces over a variety of terrain.

The Segway RMP product line uses the same components that enabled a Segway PT rider to travel more than 4,000 miles across the United States. These components were designed and tested to be highly reliable and durable, making the RMP ideal for service applications.

Each Segway RMP model is battery powered and emits only a slight harmonic hum when the drive motors are active. It also has an onboard charging system and is controlled via a simple USB or CAN serial bus interface. Custom interfaces are also available.

Human-sized performance
The Segway RMP base is well sized to augment or replace human power in a variety of applications. Its motors are capable of producing 2 HP continuously and can peak at 4-5 HP as needed—powerful enough to carry a human-sized payload. Segway RMP models are available in a variety or battery and tire/wheel combinations and offer a range of up to 15 miles / 24 km and payload capability of up to 400 lbs / 181 kg.

Flexible energy source
The Segway RMP runs on one to four NiMH or li-ion battery packs. Each Segway RMP can be powered by any electrical energy source provided it produces 52 volts. In fact, the Segway RMP may be outfitted with a compact gas generator to charge the batteries while in use.

Modular capability
Segway RMPs have a propulsion base that is found in other Segway products currently in the marketplace. Some models include support frames for custom sensing devices and computing hardware, casters for statically stable operation, or connection points for attaching one Segway RMP to another. Modular capability within the Segway RMP product line enables a small number of units to be reconfigured as needs change.