earlier sessions was now at the start; everyone was learning
some of the basics about mobile robots and what they
could do. Going forward, we could explain the concepts
behind autonomous robots like the robotic explorers
currently on Mars. By the end of the session, everyone had
created a simple autonomous program to avoid obstacles
that was similar to what Curiosity would run on Mars.
The workshop and classroom sessions were very
successful, but had their own problems in terms of the
logistics behind providing and installing PCs in different
venues (with loading development tools being a major work
item). What the attendees took away from these sessions
was much more substantial (they were walking out with the
knowledge of how to create an autonomous program for a
robot), but the amount of work that was required for set-up and tear-down wasn’t any less than what it was before
and, just as importantly, few users could continue the
experience once they left the workshops.
This may seem like a surprising comment to many
readers, but loading development tools along with
communications device drivers (many robots require a USB-to-serial connection) is beyond the capabilities of most
users. We were amazed when we sent a sample robot and
its associated paraphernalia to the science head for a major
school board (after he attended one of our sessions and
asked us to learn more about what we were doing), and he
returned everything because they would have to install
device drivers on a PC. So, not only did the need for PCs
mean significant work for us to prepare for workshop
sessions, but it was something that prevented many
interested individuals from going forward in learning about
robotics.
The obvious solution was to eliminate the PC for
beginning builders, and to simplify its use for folks that
wanted to learn how to develop their own applications. To
be fair, there are a number of educational robots on the
market that provide the user with the ability to create
simple programs, but their user interfaces typically are
based on simple LEDs and text LCDs. These approaches
leave a lot to be desired as they do not allow the user to
create applications without instructions or be able to review
and edit them. What I wanted to have was a GUI interface
(Figure 7) that allowed users to not only select which
programs to run, but allow them to configure the operation
of the robot, as well as create their own programs without
the need of a PC. This solution solves a major problem in
working with the robot but it had major ramifications as to
how the robot would be architected.
The vast majority of today’s low cost robots are based
on eight-bit processors. These processors are fairly cheap,
have excellent peripheral functions, and there are a lot of
development tools available for creating applications on
them. Unfortunately, they don’t have the horse power to
manage multiple functions on a robot, along with a user
interface (UI) and the memory requirements that go along
with it.
Another issue that has always frustrated me with
eight-bit processors is the speed decrease that occurs
when you work with integer variables that are
greater than eight bits in size; this can be a problem
when you are working with sensor data. Typical
hardware ADCs and PWMs use data sizes of 12 to 16
bits, necessitating use of larger integers which results
in larger slower programs on eight-bit processors. It
was clear that to come up with a next-generation
robot, a next-generation processor was called for.
I found that the next generation of 32-bit ARM
Cortex processors were just what the doctor ordered.
As well as executing significantly faster than their
eight-bit predecessors, they generally have
significantly more memory and I/O functions while
48 SERVO 12.2014
Figure 6. The successful end to a workshop. Even astronauts
get excited about robots!
Figure 7. The Jade robot's main screen. Users can select from any of
the eight pre-loaded applications or access the tools for configuring
the robot.
