Skip Navigation
Send E-MailCompany Information tribotix.com | Newcastle, Australia | +61 2 49578255

Information on Robot Dog & Robot Bear

On 7th July 2007 Tribotix, NUBots and Cyberbotics submitted a proposal to supply a Standard Robotic Platform for future RoboCup competitions. The RoboCup Federation plan to replace the current 4-Legged League with a new league based around the winning tenderers proposal.

The information contained within this page introduces or robot designs and discusses their technical merits and specifications. Our proposal was based around 2 robots:

  1. A 16DOF Robot Dog, and
  2. A 21DOF Robot Bear.

If you have any questions regarding our proposal or our robots then please contact us and we'd be more than happy to supply you with any additional information you may require.

The information is available in the 'accordion' below, please select the required heading and the information you require will be displayed.

This is a collaborative project from a very successful RoboCup 4 Legged League team; together with leading robotics supplier Tribotix and leading robotic simulation software (Webots 5) supplier Cyberbotics. The aim of this project is to develop two different kit based robots, to meet RoboCup Federation Call for Tenders: A Standard Robot Platform for Robot Soccer issued in November 2006.

In our tender proposal we proposed two different robotic kits, these being:

  1. Robot Dog: Quadruped with 16DOF, and
  2. Robot Bear: Quadruped with 21DOF capable of both Quadrupedal and Bipedal motion.

We proposed two different styles of robotic kits as this allows the RoboCup Executive committee to decide:

  1. if they would like the Four Legged League to continue with a Robotic Dog. This would be similar to the Sony Aibo but with significant advantages in processing power, actuator intelligence, actuator durability and additional sensors.
  2. if they would like a new style of standard hardware platform, a quadruped capable of some bipedal motion. This would open up a new field of research whilst also allowing for new game strategies, the most obvious being the ability of the Robot Bear to 'stand', increasing it's viewing field thus giving the robot an increased perception of the playing field.

Although both proposals have significantly different mechanical and physical attributes, they share the same advanced sensing and actuation capabilities. The kit style for both proposals is based heavily around an 'open source' style of hardware/software design, with the aim of permitting low cost upgrades as technology improves.

One of the key aspects in our proposals is that they both be extremely durable. To achieve this we have based our proposal around Robotis's Dynamixel range of serially controlled, smart servo motors which are:

  • based around quality Swiss Maxon motors,
  • contain all metal gears to ensure durability, and
  • use a bearing at the final axis to ensure that there is no efficiency degradation with high external loads on the output shaft.

The remainder of this article is to provide interested parties with an incite into the project's development - from conception to demonstration at RoboCup 2007 in Atlanta, USA .

Tribotix Pty Ltd

  • Peter Turner
  • Steve Mitchell

University of Newcastle , Australia

School of Electrical Engineering and Computer Science
Newcastle
Robotics Laboratory
  • Prof. Rick Middleton
  • Dr. Stephan Chalup
  • Dr Michael Quinlan
  • Robin Fisher

Discipline of Electrical and Computer Engineering

All members of the Technical Support team (too numerous to mention) contributed to this project in some way, those whose work on this project was their primary role where:

  • Paul Baker
  • Jerry Zhou
  • Ken Sayce

School of Design , Communication, and Information Technology

  • Michael Dickinson
  • Daniel Sneddon

Cyberbotics

  • Olivier Michel
  • Yvan Bourquin
  • Jean-Christophe Fillion-Robin

NB. Pierre Bureau (formerly with K-Team) contributed to our Open Call for Standard Platform tender document.

The robots which we have developed came about as a response to the call for tender by the RoboCup Federation for a Standard Robotic Platform to replace the current 4-Legged League. There are several elements underlying our philosophy of how a standardised hardware platform can best meet the needs of the RoboCup federation.

A new approach based on the Four Legged League

The four legged league has proven very popular and has some unique features within RoboCup Soccer. Some of these features are:

  • Standardised Hardware (the only soccer league with this feature)
  • Requirement for Active Perception (the only soccer league with this feature)
  • Legged Locomotion (one of only two leagues with this feature)

The four legged locomotion to date has advanced substantially as machine learning and other techniques used by a number of teams have developed walking gaits that are probably at the limit of the current Aibo hardware. Our perception of the current bipedal gaits is that this is a very challenging task, and with the limited hardware capabilities in the humanoids at present, the walking gaits are also in need of further development.

A Four Legged League

We believe that substantial insights and advances to RoboCup Soccer can be achieved by a league that will permit more sophisticated quadruped motions. We should be working towards not just walking, but trotting, and even galloping gaits for quadrupeds. Our proposal for the four legged league has an extra DOF to simulate the twisting motion of a 'backbone', this would allow new gaits to be developed as well as increasing the robots ability to turn quickly. Also, the increase in torque provided by the motors we propose to use, would increase the speed of the quadruped, allowing it to trot and possibly gallop.  

A Two/Four Legged League

We believe that substantial insights and advances to RoboCup Soccer can also be achieved by a league that will permit both sophisticated quadruped motions and bipedal gaits. As well as research into advanced quadruped gaits, this league would also stimulate research into basic biped gaits. This could mean a significant future transition from the four legged league teams to the two legged league.

Kit Style Hardware

Our approach is that the standard hardware should be supplied in kit form, with the option for teams who do not wish to do their own assembly to pay extra for pre-assembly of their robots. The kit would consist of a number of standard modules that can be relatively simply assembled and used. We believe this approach offers several advantages:

  • Cost reduction: This should result in a slight reduction in overall cost compared to supplying fully assembled units.
  • Simplified Maintenance and Repair: Rather than returning an entire robot for repair or maintenance, only the faulty unit needs to be returned. In addition, it should be easily possible for teams to keep some spare units, and use this in case of faults.
  • Simplified and Reduced Cost Upgrade Path: As the competition develops, and new hardware becomes available (for example, faster processor boards; additional sensors; more powerful motors; improved cameras) these can easily be incorporated incrementally into the system, without the need to replace entire robots.

Open Architecture Philosophy

The philosophy behind the kits is open architecture in both the hardware and software, which we believe is an important advantage for this proposal.

This means that for the hardware, teams would be provided with (at the minimum) detailed hardware block diagrams and component information. Open hardware interfaces, in terms of communication buses and hardware connections, will enable users to interface their own components with the system without reverse engineering. It is also means components can be replaced and upgraded (see section "Kit Style Hardware") without replacing the entire system.

Note that whilst this kind of information is not needed directly for the league since hardware modification is not permitted, it is crucial for correct modeling of the robot, and also permits teams to rewrite low level software components (for example, device drivers) if they wish.

Open source software, both at Operating System level and application level, will enable contributions from the community and is a major benefit for the long term quality of the software provided to all users.

This project began in early 2006, just after Sony announced it was ceasing production of their much loved Sony Aibos. At a meeting in early April 206 we (Prof. Rick Middleton, Dr. Stephan Chalup, Dr. Michael Quinlan & Peter Turner) decided to investigate the feasibility of designing a possible replacement for the Sony Aibo. The NUBot team hierarchy were concerned that the 'death' of the Sony Aibo may result in RoboCup's 4-Legged League becoming disbanded. The NUBot team considered the 4-Legged League to be a league that contributed significantly to research, even though the hardware had reached a plateau in terms of motion development, teams had just started using strategies (e.g. passing, collision detection) which the current bred of bipeds could not perform.

So within a fortnight we had designed our first prototype, which was then built and is shown in the image below, along with the Sony Aibo we hope it may one day replace.

 

 

Notice that our first prototype had a 'cardboard' body on which motors and standard frames where attached (it was also held together by 'bits of wire' for stability). We also decided to include an extra DOF in the robot dog's spine to give the rear legs the ability to rotate about the body - this was included so that more sophisticated gaits could be developed for the quadruped.

Our initial electronic design consisted of:

  • 2 x 400MHz ARM mcu's (one purely for vision and one for motion, WLAN, etc.)
  • DX-113 (Robot Dog) or DX-117 (Robot Bear) serially controlled servo motors.
  • 3 axis tilt compensated Digital compass.
  • 2 x gyroscopes (one for the body, one for the head).
  • 2 x 3 axis accelerometers (one for the body, one for the head).
  • 802.11b WLAN (CF card).
  • High resolution USB camera (640x480 pixels, 30fps).

A block diagram is shown below, it was initially intended to have the 2 Korebot's talk via USB, we later decided that this should be done via Ethernet to increase the dataflow between processors. We also change the serial to RS485 circuitry to a USB to RS485 circuitry - this was done because the Linux kernel didn't easily allow us to set the data direction on the RS485 bus, this was done more efficiently by using a dedicated USB to RS485 ic.

This lead to our next problem, we where using Linux 2.4 and needed to get a hold of a Linux 2.6 kernal to access the USB drivers. When we where unable to get the Linux kernel for the KoreBot LT we decided to change our hardware platform - this was done at a very late stage. A single AMD Geode mcu running at 500MHz with floating point capabilities gave us more MIP's than our initial dual KoreBot design for approximately the same power consumption.

Michael Dickinson joined the project a very early stage, and using our initial prototype was able to give us some indication of what our final robot dog may look like (as shown below).

Our original prototype was then mechanically modified slightly to be 1.3 times the size of the Sony Aibo, a picture of this robot is shown below. This robot was taken to RoboCup 2006 in Bremen , Germany and afterward to the Systems: Perception, Behaviors, Learning, and Action. Dagstuhl Seminar where a paper titled Development of a New Standard Platform for The Four-Legged League of RoboCup was presented by Stephan Chalup.

During or after the Dagstuhl Seminar Stephan Chalup proposed that we investigate using a different quadruped to the standard robot dog. This was when the concept for a robot bear was conceived, a robot that had the ability and speed to maneuver as a quadruped but with the ability to stand (and possibly walk) as a biped. This concept was also identified as unique because it would introduce new gaits and challenges should it be adopted as the standard platform for RoboCup.

A paper titled Proposal of a Kit-Style Robot as the New Standard Platform for the Four-Legged League was presented at ACRA2006 in Auckland New Zealand . This paper detailed our concept of a proposed kit-style robot, as well as the development of our robot dog and our proposal for a robot bear.

Our original robot dog was built around the Robotis Dynamixel DX series. We where advised by Robotis that any new robots should be designed around their new RX series of Dynamixels (as the DX series may become obsolete in the future), so we decided to continue development of the robot dog and wait until the RX series was available before starting development of a robot bear. Below are three phases of this development:

  1. a robot dog built from the Bioloid Kit to determine if this would be a feasible option,
  2. the 3 rd incarnation of our robot dog where the bottom part of the legs where metal rods - this allowed us to have a leg where no wires passed through the knee joint, and
  3. a clay model built to scale, based on (2), to give the design team so idea of the range of motion our final robot would require.

The design team also investigated various options to replace the metal rods used in the lower part of the legs. Some of the options investigate where:

  1. using a spring arrangement to give the leg some natural 'bounce', and
  2. a design for the foot, similar to that of a prosthetic limb used at the Paralympics, where a natural 'bounce' was part of the design and a characteristic of the selected material.

Delays in the release date of the RX series forced us to change our decision to wait for this series of modules (it had already cost us 6 week!), so we decided to build the bear prototype from DX-117's and some RX-64's we had been able to source.

We did a lot of research into the physical anatomy of a bear, we also watched a lot of 'bear' videos to study their gaits and general movement characteristics. We found that all bears have a similarly proportioned anatomy, it's only the 'size' of the bear that is different. Below shows how translated a bears anatomy to a robot whilst keeping as many DOF's as possible.

Because the bear has a big stomach and rear quarters, there is plenty of room for electronics and batteries in a robot bear. This is in direct comparison to the robot dog whose slender body made fitting components a very frustrating job. Also, placing the majority of the weight in the robot bears hind quarters also makes it easier to make the robot bear sit and stand.

Michael Dickinson took our mechanical design for the robot bears body and generate some initial sketches for us so that we could determine if it was feasible to build a 'body' for the robot bear as well as give us some ideas of what it might look like. Michael's first sketches are shown below:

And that's pretty much how we got to where we are for the demonstration of our robots at RoboCup 2007 ( Atlanta , USA ).

Our Robot Dog [1,2] is conceptually similar to the Sony ERS-7 Aibo.

The major differences between our Robot Dog and the Sony Aibo are:

  1. Our Robot Dog is slightly bigger, being approximately 1.3 times bigger.
  2. Our Robot Dog is designed around a Bull Terrier, it's legs are wider and the front and its body tapers away from the chest to the hind legs.
  3. Our Robot Dog has an additional DOF to allow for a 'rotational twist' in the backbone, as shown in the figure below.

To make our Robot Dog visually appealing we have designed a body that can be attached easily to the mechanical frame. The first of our robot dogs is shown below.

The robot dog and robot bear use the same electronic design and software:

  • for electronic specifications please see the Electronic Design section.
  • for a description of the software capabilities please see the Software section.

Physical characteristics (weight, dimensions, etc.) will be provided soon ..

 

The electronic design of both our robots is based on a modular concept, using open interfaces and communication buses. The electronic system is composed of motor modules, sensor modules, and main processing units. The key design features of our proposal(s) are:

  • Computer-on-module based around the AMD Geode LXMCU 500MHz
    • X86 architecture (no need for cross compilation when using Linux),
    • 256Mb DDR SRAM
    • 512Mb FLASH Disk
    • Used interfaces:
      • USB (host and slave)
      • 100Mb Ethernet
      • VGA
      • Mini PCI-bus
  • 802.11g WLAN (Mini PCI card).
  • Dynamixel RX serially controlled servo motors.
  • Slave mcu's to acquire and pre-process analog data.
  • 3 axis tilt compensated Digital compass.
  • 2 x gyroscopes (one for the body, one for the head).
  • 2 x 3 axis accelerometers (one for the body, one for the head).
  • 2 x IR distance sensors.
  • 2 OLED's for diagnostics (or aesthetic uses, e.g. 'eyes')
  • High resolution USB camera (640x480 pixels, 30fps).

NB. The operating system which our robots can operate with include Linux, Windows CE 5 and Windows XP.

A block diagram of our prototype system is shown in the diagram below:

The computer-on-module board is connected to the system using an open interface which allows the user to replace and upgrade the CPU motherboard for future expansion.

Sensors are interfaced with the processing units with a dedicated fast serial bus. The data acquisition (i.e. AD conversion) is performed by remote micro controller units, and can be read at any time by the application. Such design will provide two main benefits:

  • additional sensor modules can be easily interfaced, and
  • the main processing unit does not need to perform real-time acquisition.

Serially controlled servo motors (Dynamixel's) are independent units with an embedded controller. Commands are received from the application using a dedicated fast serial bus.

Such design will provide two main benefits:

  • additional motor modules can be easily interfaced, and
  • the main processing unit does not need to perform real-time motor control.

The main Features of the Robotis Dynamixel RX modules are:

  • Strong, durable motors with reasonable holding torque.
  • Inbuilt mcu which allows:
    • Distributed control (no CPU load for low level control)
    • Change operational parameters, e.g. compliance.
    • Get sensor information, e.g. current ! torque
  • Fault detection & max, min angles
  • Turn motor torque on/off
  • Send angle (0 - 300° ; 0.35° steps) and K speed ( ± 400°/sec range; 0.4°/sec steps)
  • RS 485 multi drop, serial communication
  • Half duplex asynchronous serial communication (8 bit, 1 stop, no parity)
  • Speed 7343bps ~ 1 Mbps

The Camera used is a simple web camera (Logitech Pro5000). There are several advantages to using an 'off the shelf' web camera, the main is that it greatly reduces the current problems associated with light calibration. A web camera can be plugged into a laptop at any time (i.e. whilst games are on adjacent fields) and calibration can be conducted without disrupting other games.

Energy is provided to all the system components from the main LiPo battery pack which will give 45 minutes to 1 hour of operation. A standard external battery charger is provided, the system does not embed a battery charger.

The robot will be distributed with a stripped version of linux with a proposed kernel version of 2.6. The OS will ship with gcc (version 4) installed, it is expected that the majority of the teams will build their code using this compiler. GCC 4 provides users with a large library of code, not only robot specific libraries (see section below) but also a vast collection of algorithms and support code.

In addition GCC is required to install/support other languages that are becoming more common in the RoboCup environment. In particular Python, which is used by many current 4-Legged league teams (and teams in other leagues). Since NUbots rely heavily on Python it can expected that a Python distribution can be made available with the robot.

Supplied with the robot will be all the drivers required to interact with the physical hardware. It is unclear if source for all these drivers will be made available, but the linux/gcc combination allows teams to re-create drivers if they feel the urge. In terms of provided sample code or `default robot code', this tender plans on supplying a few simple examples. For example - taking an image from the camera, sending and receiving from the motors and all sensors, etc. . It is expected that other teams can port previous soccer code to the new platform.

It should also be noted that images for Windows CE and Windows XP are available for our hardware platform.

Frequently asked questions

Q. What is the intended RRP for the Robot Dog?
A. This really depends on whether the Robot Dog is selected as the new standard robotic platform for RoboCup. If the Robot dog is accepted then we will be able to manufacture many robots, the more we produce the cheaper they will be. At this stage, should we win the tender, we have set our RRP as $US4990 for the kit form and $US5590 for a fully assembled Robot Dog.

Q. When will the Robot Dog be available for purchase?
A. Again, this depends on whether our tender proposal is successful. The winning tender will be announced on 31st July, 2007. We have set ourselves the goal of being able to supply these in quantity 3 months after the successful tender is announced. So, all going to plan these should be ready early November 2007.

Our Robot Bear differs significantly to Sony ERS-7 Aibo. Instead of modeling our robot on a quadruped, we have chosen a Bear - an animal capable of both bipedal and quadruped motion.

We consider the main advantages with our Robot Bear are:

  1. Our Robot Bear would open a new field of research into gaits of bears, both bipedal and quadruped.
  2. Our Robot Bear would be able to stand, giving the bear a better perspective of the playing field. This would lead to more advanced team strategies.
  3. Our Robot Bear is mechanically more sophisticated than conventional quadruped.

To make our Robot Dog visually appealing we have designed a body that can be attached easily to the mechanical frame. The first of our robot dogs is shown below.

NB. The Robot Bear shown above doesn't have it's body-suit completed yet, this will be completed in the near future.

The robot dog and robot bear use the same electronic design and software:

  • for electronic specifications please see the Electronic Design section.
  • for a description of the software capabilities please see the Software section.

Physical characteristics (weight, dimensions, etc.) will be provided soon ..

The electronic design of both our robots is based on a modular concept, using open interfaces and communication buses. The electronic system is composed of motor modules, sensor modules, and main processing units. The key design features of our proposal(s) are:

  • Computer-on-module based around the AMD Geode LXMCU 500MHz
    • X86 architecture (no need for cross compilation when using Linux),
    • 256Mb DDR SRAM
    • 512Mb FLASH Disk
    • Used interfaces:
      • USB (host and slave)
      • 100Mb Ethernet
      • VGA
      • Mini PCI-bus
  • 802.11g WLAN (Mini PCI card).
  • Dynamixel RX serially controlled servo motors.
  • Slave mcu's to acquire and pre-process analog data.
  • 3 axis tilt compensated Digital compass.
  • 2 x gyroscopes (one for the body, one for the head).
  • 2 x 3 axis accelerometers (one for the body, one for the head).
  • 2 x IR distance sensors.
  • 2 OLED's for diagnostics (or aesthetic uses, e.g. 'eyes')
  • High resolution USB camera (640x480 pixels, 30fps).

NB. The operating system which our robots can operate with include Linux, Windows CE 5 and Windows XP.

A block diagram of our prototype system is shown in the diagram below:

The computer-on-module board is connected to the system using an open interface which allows the user to replace and upgrade the CPU motherboard for future expansion.

Sensors are interfaced with the processing units with a dedicated fast serial bus. The data acquisition (i.e. AD conversion) is performed by remote micro controller units, and can be read at any time by the application. Such design will provide two main benefits:

  • additional sensor modules can be easily interfaced, and
  • the main processing unit does not need to perform real-time acquisition.

Serially controlled servo motors (Dynamixel's) are independent units with an embedded controller. Commands are received from the application using a dedicated fast serial bus.

Such design will provide two main benefits:

  • additional motor modules can be easily interfaced, and
  • the main processing unit does not need to perform real-time motor control.

The main Features of the Robotis Dynamixel RX modules are:

  • Strong, durable motors with reasonable holding torque.
  • Inbuilt mcu which allows:
    • Distributed control (no CPU load for low level control)
    • Change operational parameters, e.g. compliance.
    • Get sensor information, e.g. current ! torque
  • Fault detection & max, min angles
  • Turn motor torque on/off
  • Send angle (0 - 300° ; 0.35° steps) and K speed ( ± 400°/sec range; 0.4°/sec steps)
  • RS 485 multi drop, serial communication
  • Half duplex asynchronous serial communication (8 bit, 1 stop, no parity)
  • Speed 7343bps ~ 1 Mbps

The Camera used is a simple web camera (Logitech Pro5000). There are several advantages to using an 'off the shelf' web camera, the main is that it greatly reduces the current problems associated with light calibration. A web camera can be plugged into a laptop at any time (i.e. whilst games are on adjacent fields) and calibration can be conducted without disrupting other games.

Energy is provided to all the system components from the main LiPo battery pack which will give 45 minutes to 1 hour of operation. A standard external battery charger is provided, the system does not embed a battery charger.

The robot will be distributed with a stripped version of linux with a proposed kernel version of 2.6. The OS will ship with gcc (version 4) installed, it is expected that the majority of the teams will build their code using this compiler. GCC 4 provides users with a large library of code, not only robot specific libraries (see section below) but also a vast collection of algorithms and support code.

In addition GCC is required to install/support other languages that are becoming more common in the RoboCup environment. In particular Python, which is used by many current 4-Legged league teams (and teams in other leagues). Since NUbots rely heavily on Python it can expected that a Python distribution can be made available with the robot.

Supplied with the robot will be all the drivers required to interact with the physical hardware. It is unclear if source for all these drivers will be made available, but the linux/gcc combination allows teams to re-create drivers if they feel the urge. In terms of provided sample code or `default robot code', this tender plans on supplying a few simple examples. For example - taking an image from the camera, sending and receiving from the motors and all sensors, etc. . It is expected that other teams can port previous soccer code to the new platform.

It should also be noted that images for Windows CE and Windows XP are available for our hardware platform.

Frequently asked questions

Q. What is the intended RRP for the Robot Bear?
A. This really depends on whether the Robot Bear is selected as the new standard robotic platform for RoboCup. If the Robot Bear is accepted then we will be able to manufacture many robots, the more we produce the cheaper they will be. At this stage, should we win the tender, we have set our RRP as $US6990 for the kit form and $US7590 for a fully assembled Robot Bear.

Q. When will the Robot Dog be available for purchase?
A. Again, this depends on whether our tender proposal is successful. The winning tender will be announced on 31st July, 2007. We have set ourselves the goal of being able to supply these in quantity 3 months after the successful tender is announced. So, all going to plan these should be ready early November 2007.

 

 

 

Join us at: