Skip to main content

The Autonomous Roboticist

Since September 2016 I've been competing in the NASA Space Robotics Centennial Challenge (SRC). The challenge had a qualifying period and the final competition. I was one of the twenty teams from an international pool who qualified for the final competition. In mid-June the competitors ran their entries on a simulation in the cloud. The last few days, June 28 -30th capped the competition with a celebration at Space Center Houston, an education and entertainment facility next to the NASA Johnson Space Center.

On Thursday, the 29th, teams were invited to give presentations to the other teams, the NASA people who organized the challenge, and others. I used the opportunity to speak about my approach to the competition but also to raise the question of how an amateur roboticist, like myself, can make a meaningful contribution to robotics. 

Two ways are through competitions like this and by contributing software to the Robot Operating System (ROS). There aren't always competitions to work and ROS contributions don't fulfill my desire. In part, ROS misses the mark because before adding a new, usable package, I need to develop something new and useful. Now perhaps there are existing topics that need software and ROS packaging but how do I learn about them? 

And underlying issue for the amateur is knowing the state of the art in academia and industry. Often current academic material is behind paywalls. The amateur is also lacking in the background that lead to the current work. 

One of the reasons for this entry, and a possible new blog with the title, is to see if a third way can be found or created.

Why Autonomous?

Why the title "Autonomous Roboticist"? I started with "Amateur Roboticist" but wanted to add the term autonomous for clarity. I'm not interested in remote control 'robots' or combat 'robots', which are not robots, in my humble opinion. 

The SRC was about a humanoid robot on Mars tasked with maintaining the equipment and habitat NASA had landed there. This might be before astronauts landed or after they left but prior to another teams arrival. With the time lag between the planets and the narrow bandwidth available the robot needed to be autonomous. Human direction would take a long time and might even be overrun by events. If communication were even possible. One of the scenarios in the SRC was to realign the high-speed communications dish that was disturbed by a storm. 

The title "Amateur Autonomous Roboticist" or the permutation "Autonomous Amateur Roboticist" didn't really make sense. I then realized the two words, as used here, are close to being synonyms. An amateur is separate from established venues, i.e. is autonomous. I amateur from the title resulting in a play on the word autonomous. I want to work autonomously on autonomous robots.


I don't know.

One possible means is through affiliation with an academic group. Industry is usually precluded because of legal issues of employment, labor laws, and intellectual property ownership. They may exist with academia but there is more flexibility.

Define the Problem

If you're addressing a problem, it's useful to define the problem. Here's a list of the barrier items:

  1. What is the state of the art (SOTA)?
  2. What is needed to advance the SOTA?
  3. How can the necessary research material be obtained?
  4. How can it be translated into non-academic language, if necessary? 
About #4, an example is the use of AI in games versus robots. A specific example is the use of Behavior Trees, which I used in the competition. The academic material is dense and loaded with math which the gaming version is not. How does something similar happen to other material? 

There are other issues, I'm sure. This is just a start. 

Where can we go from here? 


Popular posts from this blog

Sensor - Accelerometer & Magnetics

Just as I was finishing my first look at the accelerometer and magnetic field sensors a couple of threads cropped up on the Android Developer's group:

I had the basic code working so dug a little deeper into the rotation routines and the timing. I posted responses on the threads but want here to dig into the details more.

First some observations applicable to my G1:

The sensors report approximetly every 20, 40 and 220 msec for FAST, GAME, and NORMAL.
A sample may be missed for a specific sensor but usually one of them will be generated - but sometimes all can be missed.
The magnetic field sensor is most reliable with only a few drops. The other sensors are dropped considerably more often.

A caveat in all this is the way I setup the sensor handling may make a difference. I have a singl…

Team Waterloo Research Paper on SRR

Team Waterloo published about their work on a robot for the 2012 and 2013 NASA Sample Return Robot Centennial Challenges.
Mapping, Planning, and Sample Detection Strategies for Autonomous Exploration This paper presents algorithmic advances and field trial results for autonomous exploration and proposes a solution to perform simultaneous localization and mapping (SLAM), complete coverage, and object detection without relying on GPS or magnetometer data. We demonstrate an integrated approach to the exploration problem, and we make specific contributions in terms of mapping, planning, and sample detection strategies that run in real-time on our custom platform. Field tests demonstrate reliable performance for each of these three main components of the system individually, and high-fidelity simulation based on recorded data playback demonstrates the viability of the complete solution as applied to the 2013 NASA Sample Return Robot Challenge.  It is the Journal of Field Robotics in the Wil…

Android Activity Analysis

I have been looking at the details of the life cycle of an Android Activity. There are many web sites that discuss this and many examples. But none of the example addressed all the onXXX() methods of Activity. I also found problems with some of the examples. In one case, the GUI update thread could be left running after the Activity supposedly was stopped.

I was trying to determine when the GUI update thread should be created, stopped, paused, etc that initiated this effort. I have a game underway (doesn't everyone?) and figuring out all the Activity infrastructure was giving me fits. Each example did it in a different manner and while there may be no one correct manner most of them seemed a little off. Usually they seemed to omit some of the steps needed to pause, stop, or destroy everything properly.

A number of discussions presented the life cycle as a state machine, as an alternative to the Google flow chart (or here). [I don't mean to single out Eric Burke of StuffThatHappe…