The Cricket is my re-invention of ground rovers, the first search and rescue robot designed for both walking and rolling. With the advantages of both movement modes, the Cricket can overcome large obstacles yet drive efficiently on flat terrain. To best utilize its extra mobility, the Cricket includes an autonomous onboard control system, that utilizes true 3D motion planning in confined unstructured environments. The result is a highly versatile ground robot that can autonomously maneuver through complex rough terrains to fulfill user commanded goals.

Key Features:
– Efficient yet versatile ground vehicle
– Operation in confined unstructured environments
– Simple and intuitive control interface

Project Overview

The Cricket project foreshadowed the DARPA robotics challenge with the goal of creating an independent ground rover capable of locating victims within a collapsed urban structure and providing limited aid. Heading the project from 2008-2011, I developed the Cricket’s autonomous motion planning control system, designed and constructed the Mk 1 prototype, and created support software as needed. Beyond research, I also directed and liased with outside support when specialists were appropriate.

Prototype Development

The robot that would become the Cricket was originally proposed as a tank-style rover whose tracks could change shape to overcome obstacles, like the VGTV-Xtreme. As an alternative, I proposed a legged robot with tracks on the outermost extremities – the same concept later demonstrated by CMU’s Chimp. With the advantages of both walking and tracked robots, the Cricket would be able to step around or over large obstacles stably and drive efficiently across the flat surfaces common in manmade structures. The Cricket might even be able to climb ladders, ascend inside piping or access shafts, and hang underneath supports or beams. Excited by the potential, I refined the initial concept into a Mk 1 prototype design iteratively in Solidworks, designing the skeleton and mechanics needed to actuate the robot and its electronics.

With the Mk 1 design complete, I engaged the University of Calgary‘s in-house machine shop to manufacture a first set of test parts. These first test parts formed a single knee joint, complete with all of the gearing and electronics, that was characteristic of the design of the Cricket’s other joint. As I had prioritized performance during the design of Mk 1, the parts proved complex to manufacture but achieved excellent strength-to-weight and torque-to-weight performance. Friction losses resulting from the worm gear selection was more significant than expected, but not critically so.

Satisfied with test performance, we contracted independent machine shops at SAIT and Mechatroniq to produce the remaining parts for the Mk 1 prototype. We also engaged an electrical undergraduate project team to design and manufacture electronics as intermediaries between the Cricket’s main computer and the motor/sensors.

During this second stage of manufacture, differing capabilities between the university’s machine shop and independent machine shops required a choice between manufacturing tolerances and budget overruns. We accepted lower tolerances with an eye towards producing a Mk 2 version, but this increased friction within the gearboxes and hampered the Mk 1’s mobility. Undeterred, I rewrote the software running on the undergraduate team’s Cricket electronics to drive the joint motors over-voltage in short bursts. Bursting allowed the Cricket to move without damaging the electrical components, but took an incredible amount of time and produced an effect similar to stop-motion cinematography. As a result, I was limited in what I could test on the Mk 1 prototype.

Testing Environment

I approached the issue of testing by creating a simulation environment called kSim instead of rushing the Mk 2 prototype. kSim is a customized physics package designed to: replicate the time-dynamics of the Cricket’s control system, allow greater control over the Cricket’s multi-body dynamics, and experiment with friction based collision physics. Utilizing OpenGL’s depth buffering data during 3D rendering, I was even able to replicate the 3D camera, ultrasonic and laser sensors being considered for use on the Cricket, complete with randomized error. At some cost to simulation speed, I achieved a very high level of physical realism, sufficient for testing the control system in place of the Mk1 prototype.

Control System Development

Alongside the Mk1 prototype, I also began to develop the Cricket’s control system in the summer of 2008. My intention was to create a control system that could be used on a tablet or smart phone with minimal training. That system would solicit camera point-of-view commands – look up, move camera forward, look left – then achieve goals via full-body 3D motion planning, similar to LittleDog. To provide the computational horsepower needed, the Cricket would require a set of 4 to 6 Gumstix micro computers running in parallel. Thus, I chose a modular distributed system architecture connected through message passing, the same concept as modern ROS, which could be connected to hardware or simulation interchangeably.

Within the control system, I first approached motion planning using systematic optimization of polynomial control signals, one for each actionable joint on the robot. Successful for a small number of degrees of freedom, polynomials scaled poorly past 3 or 4 degrees of freedom. For my next attempt, I invented a novel version of random restart hill-climbing (RRHC) that scaled efficiently up to 7 or 8 degrees of freedom. While RRHC still fell short of the Cricket’s 17 degrees of freedom, it could identify potential body motions connecting the camera’s initial and final states. After planning the camera motion, I could use RRHC again to generate an individual motion plan for each of the Cricket’s legs based on the body motion. This produced a tiered control structure that was computationally tractable, but presented a new challenge as decisions by one tier may induce failure in another tier.

Computationally tractable for simple environments, the tiered control system’s planning time rose drastically for complex environments due to the rarity of collision-free leg motions. To reduce the rate of backtracking from later tiers to earlier tiers, I restructured both tiers from optimization problems into more general model predictive control (MPC) problems. Restructuring separated the predictions and cost analyses so that I could include, in early tiers, abstract predictions of how complex the planning of later tiers would be. These abstract predictions reduced motion planning times to a usable range. As a final challenge, the control system successfully maneuvered the Cricket up an unstructured staircase after just minutes of planning time.

Moving Forward

Based on my experience with the Cricket Mk 1, the project is now well into the Mk 2 phase under the supervision of Jie Wang – a fellow ARRS researcher. To facilitate the project handoff, I designed the initial Mk 2 prototype (below) for manufacturability, ideally under 10 thousand dollars per unit. I also revised the control system for the Mk 2 to enhance planning performance. This new version of the control system will work alongside Mr. Wang’s rolling/walking locomotion transition system for responsive control in a search and rescue robot package.

Publications:
– A Reconfigurable USAR Robot Designed for Traversing Complex 3D Terrain (pdf)
– A Novel Control Architecture for Mapping and Motion Planning of Reconfigurable Robots in Highly Confined 3D Environments (pdf)