Robotics & Intelligent Gaming

When Alessandro Giacomel discovered Arduino in 2009, he quickly became hooked. Since then, he’s been designing “little robots” around Ardunio and blogging about his work and findings. In this interview, Alessandro tells us about his most interesting projects and shares his thoughts on the future of robotics, 3-D printing, and more.

CIRCUIT CELLAR: How long have you been designing embedded systems and what sparked your interest

ALESSANDRO: I have been designing embedded systems for about five years. My interest arose from the possibility of building robots. When I was a kid, I found robots extremely fascinating. The ability to force matter to do something we decided always seemed to be one of the main goals conceded to man.

CIRCUIT CELLAR: Tell us about your first design.

ALESSANDRO: My first embedded system was an Arduino 2009. The availability of a huge shield, sensors, and actuators has enabled me to design many applications at an acceptable price for an amateur like me.

DIYrobot

Alessandro’s first robot

I started like many people, with a robot on wheels moving around avoiding obstacles. It’s a standard robot that almost all beginners build. It’s simple because it is built with only a few components and a standard Arduino 2009. The design included modified servomotors that can rotate 360° moving the robot and connected to the wheels and a servomotor to move a little head where there is an ultrasonic distance sensor. The distance sensor lets you know when the robot is in front of an obstacle and helps you decide the most convenient way for the robot to escape.

In its simplicity, this robot enables one to understand the basics for the development of a microcontroller-based robot: the need to have separate power supplies for the motors’ power circuits and for the microcontroller’s logic, the need to have precise sensor reading timing, and the importance of having efficient algorithms to ensure that the robot moves in the desired mode.

My first robot took me a long time to build. But all the elements of the robot (hardware and software) were developed by me and this was important because it let me begin to face the real problems that arise when you are building a robot. Today there are many resources on the Internet that enable one to build a robot simply replicating a set of steps anyone has described. These guides should be used as a source of inspiration, never followed exactly step-by-step, otherwise—while in the end it is true that you can build a robot—you don’t own the knowledge of what has been done.

My robot evolved with the ability to speak, thanks to a sound module. When I build a robot the goal is always to experiment with a technology and to have fun. My friends have enjoyed seeing the robot turning around, speaking, and telling funny stories.

CIRCUIT CELLAR: Your blog, Robottini (http://robottini.altervista.org), is described as “little robots with Arduino.” What inspired you to begin the blog

ALESSANDRO: I strongly believe in sharing knowledge and open-source hardware and software. I thought it was normal to try to share what I was designing when I started to build robots. When I started, I had the benefit of what others had made and published on the Internet. I thought about writing a blog in my language, Italian, but I thought also it would be a good exercise for me to try to write in English and, most importantly, this enabled me to reach a much wider audience.

The site description includes the philosophy at the basis of the blog: small robots built using Arduino. I build small robots because I’m an amateur and my house isn’t very big, so I only build robots that I can put in an armoire. I use Arduino because it is a microcontroller developed in Italy, it was obvious for me to use it, and it is really a great board for a beginner—inexpensive and robust.

ArduinoRobot

Alessandro’s first robot at the Arduino Day 2011 event

The community has developed thousands of applications that can be reused. When I started the blog in 2011, I was building small robots for a few years. In the beginning, finding information was much more complicated and there were few shields that were not cheap. So, I always tried to use “poor” materials (e.g., recovered or recycled). Decreasing the cost of implementation and reusing and imagining new purposes for the things already available in a normal house seemed like a good way to work.

My achievements documented in the blog are never step-by-step guides to build the robot. I include a list of components to buy, the source code, and sometimes the wiring diagram. But I never provide a complete guide, since I think everyone should try to build their own robot because, once built, the satisfaction is enormous.

Through my blog I am available to help with problems people encounter when they are building robots, but I think it is important to give people the tools to build, rather than providing detailed explanations. Everyone can learn only by fighting the difficulties, without having someone preparing everything perfectly.

CIRCUIT CELLAR: Robottini obviously includes quite a few robotics projects. Why did you build them? Do you have a favorite?

ALESSANDRO: Many times people ask me what is the meaning of the robots I build. The answer that I give them leaves people puzzled. The answer is this: My robots are useless. They are useful only as fun—as a passion. I’m happy when I see my little son, Stefano, who is three years old, watching and laughing at a robot turning around in our house. But this does not mean I don’t follow a branch of research when I build robots.

Initially, I built robots to understand how the driver for the motors works, the sensors, and the problems related to the logic of the robot. Afterward, the first branch of research was the issue of control, how to set the proportional, integral, derivative (PID) control to follow a line or make a robot that is in balance. This has enabled me to address the management of complex sensors, such as the inertial measurement unit (IMU).

To have a robot balance on two wheels it is important to measure how much the robot is tilting from the vertical. To do this, typically a cluster of sensors is used, called IMU, which are based on multi-axes combinations of precision gyroscopes, accelerometers, magnetometers, and pressure sensors. In a more simple version, the IMU uses an accelerometer and a gyroscope, and it is mandatory to use both signals to obtain a correct value of the tilt angle from the vertical (it is called fusion of signals).

The most common method used is based on the Kalman filter, which is a mathematical tool that enables you to combine two or more signals to obtain the value of the angle. But it is a highly sophisticated and difficult for an amateur to understand, and it requires fairly advanced knowledge of mathematics. A new method that is rather simple has been proposed in the last years. It is called the “complementary filter.“

One of the studies I performed and posted on my blog compares in practice the signals of the two filters to verify if the complementary filter is able to approximate the Kalman filter in typical situations coming up in robotics. This post has had a great following, and I’ve been surprised to see that several university-level scientific publications have linked to it. I only wrote the post because I was curious to see a simple and almost trivial method that has become helpful to researchers and hobbyists. It has been a pleasure for me.

In the last year, I have followed the trend of art and interaction (i.e., the possibility of building something that can somehow marry art with technology). It was the theme of the stall I had at Maker Faire Europe in Rome, Italy, in October 2013. Arduino is an electronic circuit without a heart and without a soul. Can an Arduino be an artist? I’m trying to do something with Arduino that could be “art.” The arts include painting, poetry, music, sculpture, and so on. I’m trying to do something in different fields of art.

My first experiment is the Dadaist Poetry Box, which is a box capable of composing and printing Dadaist poems. It’s made with an Arduino and uses a printer for receipts to write poems. The box uses an algorithm to compose the poems in autonomy. You push the button and here is your Dadaist poem.

PoetryRobot

Dadaist poetry box design

Normally, the poem is a valuable asset, the result of an intimate moment when the poet transposes on paper the emotions of his soul. It is an inspired act, an act of concentration and transport. It’s not immediate. The poem box instead is trivial, it seems almost “anti-poem.” But it’s not; it’s a Dadaist poem. A user can push the button and have an original poem. I like the machine because it gives everyone something material to take home. In this way, the experience of interaction with the machine goes beyond the moment.

Another of my favorite robots is one that is capable of drawing portraits. I’ve never been good at drawing, and I’ve always been envious of those who can easily use a pencil to make a portrait. So I tried using my technical skills to fill this gap.

DrawingRobot

Portrait-drawing robot

The search of the algorithm that—starting from a picture—is able to detect the most important lines of the face has been particularly long and difficult. I used the OpenCV open-source libraries for computer vision and image processing, which are very powerful, but hard to handle. Installing the libraries is not a simple undertaking and using them is even more complicated. I used the OpenCV for Processing. Processing is an open-source programming language and integrated development environment (IDE) built for the electronic arts, new media art, and visual design communities with the purpose of teaching the fundamentals of computer programming in a visual context.

The algorithm initially found facial lines using the algorithms for calculation of edges of a picture. So I used the Canny edge detector, the Sobel edge detector, and all the other main edge detection algorithms, but none of these proved to be adequate to draw a face. Then I changed the course and used the Laplacian filter with threshold. I think I reached a good result because it takes less than 10 minutes to draw a portrait, which enables me to take pictures of people and make their portrait before they lose their patience.

CIRCUIT CELLAR: What new technologies excite you and why?

ALESSANDRO: I work almost strictly with Arduino microcontrollers. I was excited with the arrival of Linux-embedded mini-PCs (e.g., the Raspberry PI, the pcDuino, and BeagleBoard.org’s BeagleBone Black). Forcibly, I’m very intrigued by the new Arduino Tre, which is a mini-PC with Linux joined with an Arduino Leonardo. Combining a PC’s processing power of with Linux with the real-time management of the sensors and actuators made by an Arduino is an interesting road. It offers the possibility to manage the real-time processing of video streams through, for example, the OpenCV libraries, with the option of acquiring signals from analog sensors and the possibility of drive motors. For example, this enables one to have a completely autonomous 3-D printer and to perform the slicing and management of the 3-D printer. It also opens up new perspectives in the robotics and computer vision. The main limitation, which is now present in embedded systems, is the limited processing capacity. The ability to have in the same card a Linux system—with the world of applications and drivers already available—linked to the ability to manage physical devices brings a revolution. And I’m already excited to see the next results.

Read the complete interview in Circuit Cellar 292 November 2014.

Electrostatic Cleaning Robot Project

How do you clean a clean-energy generating system? With a microcontroller (and a few other parts, of course). An excellent example is US designer Scott Potter’s award-winning, Renesas RL78 microcontroller-based Electrostatic Cleaning Robot system that cleans heliostats (i.e., solar-tracking mirrors) used in solar energy-harvesting systems. Renesas and Circuit Cellar magazine announced this week at DevCon 2012 in Garden Grove, CA, that Potter’s design won First Prize in the RL78 Green Energy Challenge.

This image depicts two Electrostatic Cleaning Robots set up on two heliostats. (Source: S. Potter)

The nearby image depicts two Electrostatic Cleaning Robots set up vertically in order to clean the two heliostats in a horizontal left-to-right (and vice versa) fashion.

The Electrostatic Cleaning Robot in place to clean

Potter’s design can quickly clean heliostats in Concentrating Solar Power (CSP) plants. The heliostats must be clean in order to maximize steam production, which generates power.

The robot cleaner prototype

Built around an RL78 microcontroller, the Electrostatic Cleaning Robot provides a reliable cleaning solution that’s powered entirely by photovoltaic cells. The robot traverses the surface of the mirror and uses a high-voltage AC electric field to sweep away dust and debris.

Parts and circuitry inside the robot cleaner

Object oriented C++ software, developed with the IAR Embedded Workbench and the RL78 Demonstration Kit, controls the device.

IAR Embedded Workbench IDE

The RL78 microcontroller uses the following for system control:

• 20 Digital I/Os used as system control lines

• 1 ADC monitors solar cell voltage

• 1 Interval timer provides controller time tick

• Timer array unit: 4 timers capture the width of sensor pulses

• Watchdog timer for system reliability

• Low voltage detection for reliable operation in intermittent solar conditions

• RTC used in diagnostic logs

• 1 UART used for diagnostics

• Flash memory for storing diagnostic logs

The complete project (description, schematics, diagrams, and code) is now available on the Challenge website.

 

Game On with the Arduino Esplora

Every time the Arduino team is about to release a new board, we expect something great in terms of better specs, more I/Os, a faster processor, more memory—or, well, just something to “fill the gap,” such as small-scale versions. With “Esplora” the Arduino team pleasantly surprises us again!

Arduino Esplora

The brand new Esplora is targeted toward gaming applications. It consists of a gamepad-shaped development board that includes an Arduino-compatible Atmel ATmega32U4, a light sensor, a temperature sensor, an accelerometer, a joystick, push buttons, a slider, an RGB LED, and a buzzer.

The Esplora is as a ready-to-use solution for designers who don’t want to deal with soldering or prototyping by means of discrete components. In fact, it comes preprogrammed with a controller script, so you only have to connect it to a PC, download the free game “Super Tux Cart,” and have fun.

An additional color LCD will be released soon in order to create a portable console. The only drawback is you can’t directly connect standard Arduino shields to it , mainly because of space limitations. Nevertheless, the board itself includes enough features to make it interesting.

The Esplora should enable you to implement a controller for almost any application you dream up. In our case, we’re sure it will bring back nice memories of the time when we were too young for soldering irons but already pros with gamepads!—Jaime González Arintero Berciano, Elektor International Media

 

Propeller Games (P2): Game Logic

In the first part of this article series on Parallax Propeller-based gaming projects, I hooked up the hardware for the Hi/Lo game on a breadboard. Now I’ll write the game logic. The finished code is available here.

The power of the Propeller chip is in its multiple CPU cores. But you can do just fine with one processor, especially for a simple game like Hi/Lo. You program each of the processors in assembly or in the Parallax-invented SPIN high-level language. Assembly programs run blazingly fast directly in the CPU core. SPIN compiles to a binary format that is interpreted by the SPIN interpreter (written in assembly). The interpreter runs in the CPU core.

The CPU core is designed for speed, but it only has room for 512 instructions. The SPIN interpreter fetches your program byte by byte from shared RAM. Your code runs more slowly, but you have 32K of space to work with. I’ll use assembly in future projects, but SPIN is perfect for Hi/Lo.

A SPIN file is a collection of functions and data (shared by all functions in the file). The functions use local variables kept on a call stack. You break up your programming task into smaller functions that build on one another and call each other. You pass parameters to the functions and use the return values. It is all very similar to C programming though the syntax is different. The interpreter begins with the first function in your file no matter what you name it.

I started the project with a test “main” and the functions to control the Hi/Lo speaker, LEDs, and switches. 

This function plays a tone on the speaker (Source: C. Cantrell)

The “playTone” function generates a square wave on the speaker pin. The “cnt” register is a built-in 32-bit value that increments with every system clock. I run the prop stick full out with an 80-MHz clock configuration (5M-Hz crystal with a *16 internal multiplier). The “waitcnt” instruction puts the CPU to sleep until the system clock reaches the requested value. There are two waits in the loop that generates one clock cycle. Thus the generated frequency is roughly 40 MHz/freq. I say “roughly” because each instruction takes a little time to execute. The actual generated frequency is slightly less. There are much better ways to generate a precise square wave with the propeller hardware, but this is function is easy to understand, and it works fine for the simple Hi/Lo game.

The LED display is a collection of 14 segments and two dots that are turned on or off by writing a 1 or 0 to the Propeller port pins. The program use a look-up table that defines the various segment patterns to be shown.

The output pin bit patterns for numeric digits (Source: C. Cantrell)

The look-up table is defined in a data (DAT) section in the program. The SPIN language allows you to define binary constants with a “%” prefix. You can use the underscore (“_”) anywhere in any numeric constant to make it easier to read. The comment line just above the table shows how the segments map to bit positions in the propeller’s output register.

The “drawNumber” function displays a two digit value on the display. The function first divides the value by 10. The whole part (value/10) is the digit in the 10s place. The remainder (value//10) is the digit in the 1s place. The function looks up the separate patterns, ORs them together, and writes to the “outa” output register to toggle the lights.

I wrote LED functions to “drawBlank” (blank the display) and “drawHi” (show “Hi”) and “drawLo” (show “Lo”). These one-line functions are easy enough to code inline where they are used. But having the functions in distinct blocks makes the using code easier to understand and modify.

The functions to read the buttons return Boolean values: true if the switch is pressed or false if it is not. When a button is pressed, the corresponding input bit in “ina” goes to “1.” There are five buttons and five functions—one for each. There is also an “isAny” function to detect if any button is pressed.

The function returns "true" if a button is pressed. (Source: C. Cantrell)

The game itself has two distinct modes. The “splash” mode flashes “Hi/Lo” and waits for a player to press a button. This is an “attract” mode that draws players to the game. The “splash” function returns when a button has been pressed. The “playGame” function is the game logic. The function returns when the game is over. Thus the main loop simply calls the two functions in an infinite loop.

???????????. (Source: C. Cantrell)

The “splash” function calls “drawHi” and “drawLo” with a pause between.

The function attracts a player to the game. (Source: C. Cantrell)

The “pauseStopOnAnyButton” function counts up the delay and watches for “isAny”. It aborts the pause and returns true if a button is pressed. The “SPLASH_DELAY” is defined in the constant (“CON”) area of the program. I keep all “magic numbers” like delay counts and tone values in the CON area for easy tweaking.

The “playGame” function uses three helper functions: “getPlayerGuess,” “showWin,” and “showHint.” The “showWin” and “showHint” functions are just a couple of lines each and could be coded inline. Having them separate allows you to enhance the visual effects without changing the game logic code.

The “getPlayerGuess” does the real work of the game. It watches the buttons and changes the displayed number accordingly.

The function takes the player input. (Source: C. Cantrell)

The “getPlayerGuess” function is an infinite loop with five IF checks for each button. When the middle button is pressed the function returns with the global “playerGuess” variable holding the input value. The other buttons increment or decrement the digits on the display. Each IF block checks for overflow and plays a feedback tone.

There you have it: a simple Hi Lo game. The visual and input effects are in separate functions ready to be spruced up. I bet your solution has many more bells and whistles! I look forward to reading your ideas in the comments of this blog.

Next time I’ll wrap up the Hi Lo game with a little multitasking. I’ll write parallel programs to run in two new CPU cogs to manage sound effects and the LED display.

Chris Cantrell earned an MSEE from the University of Alabama. He writes Java and Flex for Emerson Network Power in Huntsville, Alabama. Circuit Cellar published 10 of his articles between 2002 and 2012: Issue 145, Issue 152, Issue 161, Issue 184, Issue 187, Issue 193, Issue 205, Issue 209, Issue 139, and Issue 260.

Propeller Games (P1): Hi Lo

Welcome to the Propeller Games! In a few installments, I’ll present several gaming projects that use the Parallax Propeller chip. The Propeller is perfect for gaming with its multiple CPU cores to handle simultaneous gaming activities and its on-board video generation circuitry.

My first game project is the classic “higher/lower” game, where the computer thinks of a number between 0 and 99 and you guess it. You have probably seen this played as the “Clock Game” on The Price is Right TV show, though some contestants struggle with a basic binary search algorithm. (You can watch videos of the game at YouTube.com.)

This entire project is built on a solderless breadboard. If you are new to the Propeller, this is the perfect project to get acquainted with the hardware and programming. If you are a Propeller guru, you will enjoy the nostalgia of gaming on LEDs and push buttons. Grab your breadboard and follow along.

Parts

What you’ll need:

  • Breadboard and wire
  • 9-VDC wall transformer
  • Parallax PropStick USB
  • Two-digit 7-segment LED display
  • Five SPST pushbuttons
  • Audio speaker
  • Sixteen 200-Ω resistors
  • Five 10-kΩ resistors

The board and basic parts

The Parallax Propeller chip requires a few external components. You need a 3.3-VDC power regulator, a crystal, and a USB-to-serial converter. You also need a serial EEPROM if you want the Propeller to run your program at power up. You can buy all these separately and wire them up on the breadboard. Or you can save time and space with the Parallax PropStick USB. It combines all these external parts on the same footprint as the 40-pin Propeller chip.

I bought the LED display for this project from Mouser Electronics (part number 630-HDSP-521E). The large red segments are common anode (common ground). You supply positive voltage from a propeller port pin through a 220-Ω resistor to light the segments.

I bought the push buttons from Pololu Robotics & Electronics (part number 1400). They are specially designed for mounting on a breadboard. One side of each switch is connected to 3.3 V and the other is connected to a propeller port pin and pulled to ground with a 10-kΩ resistor.

I bought the speaker from Digi-Key (part number 668-1140-ND). The negative terminal of the speaker hooks to the breadboard’s ground. The positive terminal hooks directly to a Propeller port pin.

A speaker, one LED segment, and one switch wired to the Propeller

I placed four of the switches on the corners of the display. These switches are used as up/down inputs for each digit allowing the player to select a number from 00 to 99. The fifth button to the right of the display is the “Enter” button.

The photo above shows the speaker, one LED segment, and one switch wired to the Propeller. I tested the hardware and software incrementally as I hooked it up instead of trying to debug the final system as a whole.

The Parallax Propeller Tool is the free graphical Integrated Development Environment (IDE) you use to develop code for the Propeller. The code editor colors and highlights your work making it easy to see functions and keywords. It also manages indentation. The SPIN programming language uses indentation to identify code blocks much as Python does.

Basic hardware test

The code above is my basic hardware test. The CON (constants) section at the top configures the clock speed of the chip: 5 MHz × 16 = 80 MHz. The OBJ (object) section pulls in the serial terminal driver library. This library object allows you to use the USB cable for both programming and an input/output terminal. The one second pause on line 12 gives you time to switch from the IDE program to the terminal program on your PC once the code is downloaded. The Propeller tool download includes the parallax serial terminal for your PC.

Line 10 sets general I/O pin 0 (P0) as an output (they are inputs by default). Line 17 reads the switch connected to P11 and turns the LED segment on or off accordingly. Line 18 prints the state of the input pins to the PC terminal in an infinite loop.

Parallax serial terminal

It took me a while to warm up to the SPIN programming language. It is syntactically very different from C and its derivatives. But conceptually it is familiar: you break your software up into functions and local/global variables. In the end the simplicity of the syntax and the friendliness of the IDE won me over!

I really like the “Propeller font” used in the Propeller Tool IDE. It includes special symbols you can use to draw circuits and timing diagrams in your code comments. For instance:

Check out the font

Now to wire up the rest of the LEDs and switches. I thought about wiring the left digit to the first port byte and the right digit to the second port byte so that the segments are laid out the same way in each byte. This would make the software easier to write. But the pins for the segments on the display are kind of scattered around at random. The wiring is easier and neater if you wire the segments from the bottom of the display to the bottom of the propeller and from the top of the display to the top of the propeller. You can make up for the scattered pattern with software.

Two tips: Wire the segments from the bottom of the display to the bottom of the Propeller. Wire from the top of the display to the top of the Propeller.

Hi/Lo breadboard layout

That’s it for this installment. Now I’ll clean up all the little wire stripping sprinkles I left around my workbench. In Part 2 of this series, I’ll switch modes from hardware to software and write the Hi/Lo game. Hopefully you are following along. Until next time, may the COGs be ever in your favor.

Chris Cantrell earned an MSEE from the University of Alabama. He writes Java and Flex for Emerson Network Power in Huntsville, Alabama. Circuit Cellar published 10 of his articles between 2002 and 2012: Issue 145, Issue 152, Issue 161, Issue 184, Issue 187, Issue 193, Issue 205, Issue 209, Issue 139, and Issue 260.