Mouser examines the droids from “a galaxy far, far away” to gain some insight into how robots will help humanity realize our future.
In this issue of the Empowering Innovation Together ebook, Mouser takes an in-depth look at Collaborative Robotics. We examine “cobots” in industrial environments, motor control in complex robotics and design considerations. We also look at how robots and humans interact and coexist with each other as they work.
Robots may be as disruptive as the automobile, causing us to rethink how we live and work. In Mouser’s 5-part Empowering Innovation Together™ video series, Grant Imahara departs on another technical journey to explore the frontier of robotics, meeting with researchers, engineers and visionaries shaping the robotic future.
Machine chine vision is a field of electrical engineering that’s changing how we interact with our environment, as well as the ways by which machines communicate with each other. Circuit Cellar has been publishing articles on the subject since the mid-1990s. The technology has come a long way since then. But it’s important (and exciting) to regularly review past projects to learn from the engineers who paved the way for today’s ground-breaking innovations.
In Circuit Cellar 92, a team of engineers (Bill Bailey, Jon Reese, Randy Sargent, Carl Witty, and Anne Wright) from Newton Labs, a pioneer in robot engineering, introduced readers to the M1 color-sensitive robot. The robot’s main functions were to locate and carry tennis balls. But as you can imagine, the underlying technology was also used to do much more.
The engineering team writes:
Machine vision has been a challenge for AI researchers for decades. Many tasks that are simple for humans can only be accomplished by computers in carefully controlled laboratory environments, if at all. Still, robotics is benefiting today from some simple vision strategies that are achievable with commercially available systems.
In this article, we fill you in on some of the technical details of the Cognachrome vision system and show its application to a challenging and exciting task—the 1996 International AAAI Mobile Robot Competition in Portland, Oregon… In 1996, the contest was for an autonomous robot to collect 10 tennis balls and 2 quickly and randomly moving, self-powered squiggle balls and deliver them to a holding pen within 15 min.
At the time of the conference, we had already been manufacturing the Cognachrome for a while and saw this contest as an excellent way to put our ideas (and our board) to the test. We outfitted a general-purpose robot called M1 with a Cognachrome and a gripper and wrote software for it to catch and carry tennis balls… M1 follows the wall using an infrared obstacle detector. The code drives two banks of four infrared LEDs one at a time, each modulated at 40 kHz.
Two standard Sharp GP1U52X infrared remote-control reception modules detect reflections. The 74HC163/74HC238 combination fires each LED in turn, and the ’HC259 latches detected reflections. This system provides reliable obstacle detection in the 8–12″ range.
The figure above shows the schematic. The photo shows the IR sensors.
The system provides only yes/no information about obstacles in the eight directions around the front half of the robot. However, M1 can crudely estimate distance to large obstacles (e.g., walls) via patterns in the reflections. The more adjacent directions with detected reflections, the closer the obstacle probably is.
Download the Entire Article
Franklin Robotics has launched a Kickstarter to build Tertill: a solar-powered and weatherproof robot that weeds your garden every day. With Tertill, gardeners can now enjoy weed-free vegetable and flower gardens, without the monotony and frustration of weeding. Organic gardeners can breathe easy and enjoy a weed-free, chemical-free garden all season long. Created by roboticist Joe Jones – inventor of the Roomba – Franklin Robotics’ Tertill is designed to live in your garden and take care of the weeding, come rain or shine.
Tertill lives in your garden and prevents weeds from becoming established. Using unique design elements and a variety of sensors, Tertill patrols the garden daily, avoiding plants and obstacles while looking for weeds to eliminate. Tertill has a very simple method of distinguishing weeds from plants: weeds are short, plants are tall. A plant tall enough to touch the front of Tertill’s shell activates a sensor that makes the robot turn away. A plant short enough to pass under Tertill’s shell, though, activates a different sensor that turns on the weed cutter.
Tertill gets its power from the sun. When there is sunlight—even on cloudy days—Tertill’s solar cell converts the light into electricity. The robot stores the energy in a battery. You don’t need to charge or replace Tertill’s battery. Tertill uses its stored power smartly—during cloudy stretches, when less power is available, it patrols for weeds less often. Tertill is more aggressive during periods with more sun. Fortunately, weeds grow more slowly when they have less light.
Parallax’s Scribbler 3 (S3) is a fully-assembled, preprogrammed, reprogrammable, and hackable robot that’s well suited for students and electronics enthusiasts. You can program the S3 in Parallax’s Graphical User Interface (GUI) software or its BlocklyProp tool. The visual programming support in Google’s Blockly makes learning to program easier than ever.
The S3’s improvements over its predecessor include:
- Rechargeable lithium ion battery pack
- Exposed Hacker Port with access to I/O and high-current power connections
- XBee socket inside for RF networking and future wireless programming
- Line sensor improvement: easy to follow lines of all types with Blockly
- Up to 25% faster
The Scribbler 3 robot costs $179.
NAN: Tell us about your start-up company, Narobo.
ERIC: Narobo is essentially the company through which I do all my consulting work. I’ve built everything from dancing robots to cellular field equipment. Most recently I’ve been working with some farmers in the Midwest on remote monitoring. We monitor a lot of different things remotely, and I’ve helped develop an online portal and an app. The most interesting feature of our system is that we have a custom tablet rig that can interface directly to the electronics over just the USB connection. We use Google’s Android software development kit to pull that off.
ERIC: The DroneCell was my second official product released, the first being the Roboduino. The Roboduino was relatively simple; it was just a modified Arduino that made building robots easy. We used to sell it online at CuriousInventor.com for a little while, and there was always a trickle of sales, but it was never a huge success. I still get a kick out of seeing Roboduino in projects online, it’s always nice to see people appreciating my work.
The DroneCell is the other product of mine, and my personal favorite. It’s a cellular module board geared toward the hobbyist. A few years ago, if you wanted to add cellular functionality to your system you had to do a custom PCB for it. You had to deal with really low voltage levels, very high peak power draws, and hard-to-read pins. DroneCell solved the problem and made it very easy to interface to hobbyist systems such as the Arduino. Putting on proper power regulation was easy, but my biggest design challenge was how to handle the very low voltage levels. In the end, I put together a very clever voltage shifter that worked with 3V3 and 5 V, with some calculated diodes and resistors.
NAN: Tell us about your first project. Where were you at the time and what did you learn from the experience?
ERIC: The Butler robot was my first real electronics project. I started building it in ninth grade, and for a really stupid reason. I just wanted to build a personal robot, like on TV. My first version of the Butler robot was cobbled together using an old laptop, a USB-to-I/O converter called Phidgets, and old wheelchair motors I bought on eBay.
I didn’t use anything fancy for this robot, all the software was written in Visual Basic and ran on Windows XP. For motor controllers, I used some old DPDT automotive relays I had lying around. They did the job but obviously I wasn’t able to PWM them for speed control.
My second version came about two years later, and was built with the intention of winning the Instructables Robot contest. I didn’t win first place, but my tutorial “How to Build a Butler Robot” placed in the top 10 and was mentioned in The Instructables Book in print. This version was a cleaner version of everything I had done before. I built a sleek black robot body (at least it was sleek back then!) and fabricated an upside-down bowl-shaped head that housed the webcam. The electronics were basically the same. The main new features were a basic robot arm that poured you a drink (two servos and a large DC motor) and a built-in mini fridge. I also got voice command to work really well by hooking up my Visual Basic software with Dragon’s speech-to-text converter.
The Butler robot was a great project and I learned a lot about electronics and software from doing it. If I were to build a Butler robot right now, I’d do it completely differently. But I think it was an important to my engineering career and it taught me that anything is possible with some hacking and hard work.
At the same time as I was doing my Butler robot (probably around 2008), I lucked out and was hired by an entertainer in Hong Kong. He saw my Butler robot online and hired me to build him a dancing robot that was synced to music. We solved the issue of syncing to music by putting dual-tone multi-frequency (DTMF) tones on the left channel audio and music on the right channel. The right channel went to speakers and the left channel went to a decoder that translated DTMF tone sequences to robot movement. This was good because all the data and dance moves were part of the same audio file. All we had to do was prepare special audio files and the robot would work with any music player (e.g., iPod, laptop, CD, etc.). The robot is used in shows to this day, and my performer client even hired a professional cartoon voice actor to give the robot a personality.
NAN: You were an adjunct professor at the Cooper Union for the Advancement of Science and Art in New York City. What types of courses did you teach and what did you enjoy most about teaching?
ERIC: I will be entering my senior year at Cooper Union in the Fall 2014. Two years ago, I took a year off from school to pursue my work. This past year I completed my junior year. I taught a semester of “Microcontroller Projects” at Cooper Union during my year off from being a student. We built a lot of really great projects using Arduino. One final project that really impressed me was a small robot car that parallel parked itself. Another project was a family of spider robots that were remotely controlled and could shrink up into a ball.
Cooper Union is filled with really bright students and teaching exposed me to the different thought processes people have when trying to build a solution. I think teaching helped me grow as a person and helped me understand that in engineering—and possibly in life—there is no one right answer. There are different paths to the same destination. I really enjoyed teaching because it made me evaluate my understanding about electronics, software, and robotics. It forced me to make sure I really understood what was going on in intricate detail.
NAN: You have competed in robotics competitions including RoboCup in Austria. Tell us about these experiences—what types of robots did you build for the competitions?
ERIC: In high school I was the robotics team captain and we built a line-following robot and a soccer robot to compete in RoboCup Junior in the US. We won first place in the RoboCup Junior Northeast Regional and were invited to compete in Austria for the International RoboCup Junior games. So we traveled as a team to Austria to compete and we got to see a lot of interesting projects and many other soccer teams compete. I remember the Iranian RoboCup Junior team had a crazy robot that competed against us; it was built out of steel and looked like a miniature tank.
My best memory from Austria was when our robot broke and I had to fix it. Our robot was omnidirectional with four omni wheels in each corner that let it drive at any angle or orientation it wanted. It could zigzag across the field without a problem. At our first match, I put the robot down on the little soccer field to compete… and it wouldn’t move. During transportation, one of the motors broke. Disappointed, we had to forfeit that match. But I didn’t give up. I removed one of the wheels and rewrote the code to operate with only three motors functional. Again we tried to compete, and again another motor appeared to be broken. I removed yet another wheel and stuck a bottle cap as a caster wheel on the back. I rewrote the code, which was running on a little Microchip Technology PIC microcontroller, and programmed the robot to operate with only two wheels working. The crippled robot put up a good fight, but unfortunately it wasn’t enough. I think we scored one goal total, and that was when the robot had just two wheels working.
After the competition, during an interview with the judges, we had a laugh comparing our disabled robot to the videos we took back home with the robot scoring goal after goal. I learned from that incident to always be prepared for the worst, do your best, and sometimes stuff just happens. I’m happy I tried and did my best to fix it, I have no regrets. I have a some of the gears from that robot at home on display as a reminder to always prepare for emergencies and to always try my best.
NAN: What was the last electronics-design related product you purchased and what type of project did you use it with?
ERIC: The last product would be an op-amp I bought, probably the 411 chip. For a current project, I had to generate a –5-to-5-V analog signal from a microcontroller. My temporary solution was to RC filter the PWM output from the op-amp and then use an amplifier with a
gain of 2 and a 2.5-V “virtual ground.” The result is that 2.5 V is the new “zero” voltage. You can achieve –5 V by giving the op-amp 0 V, a –2.5-V difference that is amplified by 2 to yield 5 V. Similarly, 5 V is a 2.5-V difference from the virtual ground, amplified by 2 it provides a 5-V output.
NAN: What do you consider to be the “next big thing” in the industry?
ERIC: I think the next big thing will be personalized health care via smartphones. There are already some insulin pumps and heart monitors that communicate with special smartphone apps via Bluetooth. I think that’s excellent. We have all this computing power in our pockets, we should put it to good use. It would be nice to see these apps educating smartphone users—the patients themselves— about their current health condition. It might inspire patients/users to live healthier lifestyles and take care of themselves. I don’t think the FDA is completely there yet, but I’m excited to see what the future will bring. Remember, the future is what you build it to be.
Growing up in the 1970s, the first robot I remember was Rosie from The Jetsons. In the 1980s, I discovered Transformers, which were touted as “robots in disguise,” I imitated Michael Jackson’s version of “the robot,” and (unbeknownst to me) the Arthrobot surgical robot was first developed. This was years before Honda debuted ASIMO, the first humanoid robot, in 2004.
“In the 1970s, microprocessors gave me hope that real robots would eventually become part of our future,” RobotBASIC codeveloper John Blankenship told me in a 2013 interview. It appears that the “future” may already be here.
Welcome to the 21st century. Technology is becoming “smarter,“ as evidenced at the Consumer Electronics Show (CES) 2014, which took place in January. The show unveiled a variety of smartphone-controlled robots and drones as well as wireless tracking devices.
Circuit Cellar’s columnists and contributors have been busy with their own developments. Steve Lubbers wondered if robots could be programmed to influence each other’s behavior. He used Texas Instruments’s LaunchPad hardware and a low-cost radio link to build a group of robots to test his theory. The results are on p. 18.
RobotBASIC’s Blankenship wanted to program robots more quickly. His article explains how he uses robot simulation to decrease development time (p. 30).
The Internet of Things (IoT), which relies on embedded technology for communication, is also making advancements. According to information technology research and advisory company Gartner, by 2020, there will be close to 26 billion devices on the IoT.
With the IoT, nothing is out of the realm of a designer’s imagination. For instance, if you’re not at home, you can use IoT-based platforms (such as the one columnist Jeff Bachiochi writes about on p. 58) to preheat your oven or turn off your sprinklers when it starts to rain.
Meanwhile, I will program my crockpot and try to explain to my 8-year-old how I survived childhood without the Internet.
“Steve Ciarcia had a ‘Circuit Cellar.’ I have a ‘Design Dungeon,’” Steve Lubbers says about his Dayton, OH-based workspace.
“An understanding wife and a spare room in the house allocated a nice place for a workshop. Too bad the engineer doesn’t keep it nice and tidy! I am amazed by the nice clean workspaces that have previously been published! So for those of you who need a visit from FEMA, don’t feel bad. Take a look at my mess.”
The workspace is a creative mess that has produced dozens of projects for Circuit Cellar contests. From the desk to the floor to the closet, the space is stocked with equipment and projects in various stages.
The doorway is marked “The Dungeon.” The first iteration of The Dungeon was in my parents’ basement. When I bought a house, the workshop and the sign moved to my new home.
The door is a requirement when company comes to visit. Once you step inside, you will see why. The organizational plan seems to be a pile for everything, and everything in a pile. Each new project seems to reduce the amount of available floor space.
“High-tech computing” is accomplished on a PDP-11/23. This boat anchor still runs to heat the room, but my iPod has more computing abilities! My nieces and nephews don’t really believe in 8” disks, but I have proof.
The desk (messy of course) holds a laptop computer and a ham radio transceiver. Several of my Circuit Cellar projects have been related to amateur radio. A short list of my ham projects includes a CW keyer, an antenna controller, and a PSK-31 (digital communications) interface.
My workbench has a bit of clear space for my latest project and fragments of previous projects are in attendance. The skull in the back right is wearing the prototype for my Honorable Mention in the Texas Instruments Design Stellaris 2010 contest. It’s a hands-free USB mouse. The red tube was the fourth-place winner in the microMedic 2013 National Contest.
Front and center is the prototype for my March 2014 Circuit Cellar article on robotics. Test equipment is a mix of old and new. Most of the newer equipment has been funded by past Circuit Cellar contests and articles.
The closet is a “graveyard” for all of the contest kits I have received, models I would like to build, and other contraptions the wife doesn’t allow to invade the rest of the house. (She is pretty considerate because you will find my Hero Jr. robot in the living room.)
At one time, The Dungeon served as my home office. For about five years I had the ideal “down the hall” commute. A stocked lab helped justify my ability to work from home.
When management pulled the plug on working remotely, the lab got put to work developing about a dozen projects for Circuit Cellar contests. There has been a dry spell since my last contest entry, so these days I am helping develop the software for the ham radio Satellite FOX-1. My little “CubeSat” will operate as a ham radio transponder and a platform for university experiments when it launches in late 2014. Since I will probably never go to space myself, the next best thing is launching my code into orbit. It’s a good thing that FOX-1 is smaller than a basketball. If it was bigger, it might not fit on my workbench!
Lubbers’s article about building a swarm of robots will appear in Circuit Cellar’s March issue. To learn more about Lubbers, read our 2013 interview.
NAN: You have been posting a weekly project on your website, Hack A Week, for almost three years. Why did you decide to create the website?
DINO: One day on the Hack A Day website I saw a post that caught my attention. It was seeking a person to fill a potential position as a weekly project builder and video blogger. It was offering a salary of $35,000 a year, which was pretty slim considering you had to live in Santa Monica, CA. I thought, “I could do that, but not for $35,000 a year.”
That day I decided I was going to challenge myself to come up with a project and video each week and see if I could do it for at least one year. I came up with a simple domain name, www.hackaweek.com, bought it, and put up a website within 24 h.
My first project was a 555 timer-based project that I posted on April 1, 2011, on my YouTube channel, “Hack A Week TV.” I made it through the first year and just kept going. I currently have more than 3.2 million video views and more than 19,000 subscribers from all over the world.
NAN: Hack A Week features quite a few robotics projects. How are the robots built? Do you have a favorite?
DINO: I usually use an Arduino as the robot’s controller and Roomba gear motors for locomotion. I have built a few others based on existing wheeled motorized toys and I’ve made a few with the Parallax Propeller chip.
My “go-to” sensor is usually the Parallax PING))) ultrasonic sensor. It’s easy to connect and work with and the code is straightforward. I also use bump sensors, which are just simple contact switches, because they mimic the way some insects navigate.
Nature is a great designer and much can be learned from observing it. I like to keep my engineering simple because it’s robust and easy to repair. The more you complicate a design, the more it can do. But it also becomes more likely that something will fail. Failure is not a bad thing if it leads to a better design that overcomes the failure. Good design is a balance of these things. This is why I leave my failures and mistakes in my videos to show how I arrive at the end result through some trial and error.
My favorite robot would be “Photon: The Video and Photo Robot” that I built for the 2013 North Carolina Maker Faire. It’s my masterpiece robot…so far.
NAN: Tell us a little more about Photon. Did you encounter any challenges while developing the robot?
DINO: The idea for Photon first came to me in February 2013. I had been playing with the Emic 2 text-to-speech module from Parallax and I thought it would be fun to use it to give a robot speech capability. From there the idea grew to include cameras that would record and stream to the Internet what the robot saw and then give the robot the ability to navigate through the crowd at Maker Faire.
I got a late start on the project and ended up burning the midnight oil to get it finished in time. One of the bigger challenges was in designing a motorized base that would reliably move Photon across a cement floor.
The problem was in dealing with elevation changes on the floor covering. What if Photon encountered a rug or an extension cord?
I wanted to drive it with two gear motors salvaged from a Roomba 4000 vacuum robot to enable tank-style steering. A large round base with a caster at the front and rear worked well, but it would only enable a small change in surface elevation. I ended up using that design and made sure that it stayed away from anything that might get it in trouble.
The next challenge was giving Photon some sensors so it could navigate and stay away from obstacles. I used one PING))) sensor mounted on its head and turned the entire torso into a four-zone bump sensor, as was a ring around the base. The ring pushed on a series of 42 momentary contact switches connected together in four zones. All these sensors were connected to an Arduino running some simple code that turned Photon away from obstacles it encountered. Power was supplied by a motorcycle battery mounted on the base inside the torso.
The head held two video cameras, two smartphones in camera mode, and one GoPro camera. One video camera and the GoPro were recording in HD; the other video camera was recording in time-lapse mode. The two smartphones streamed live video, one via 4G to a Ustream channel and the other via Wi-Fi. The Ustream worked great, but the Wi-Fi failed due to interference.
Photon’s voice came from the Emic 2 connected to another Arduino sending it lines of text to speak. The audio was amplified by a small 0.5-W LM386 amplifier driving a 4” speaker. An array of blue LEDs mounted on the head illuminated with the brightness modulated by the audio signal when Photon spoke. The speech was just a lot of lines of text running in a timed loop.
Connecting all of these things together was very challenging. Each component needed a regulated power supply, which I built using LM317T voltage regulators. The entire current draw with motors running was about 1.5 A. The battery lasted about 1.5 h before needing a recharge. I had an extra battery so I could just swap them out during the quick charge cycle and keep downtime to a minimum.
I finished the robot around 11:00 PM the night before the event. It was a hit! The videos Photon recorded are fascinating to watch. The look of wonder on people’s faces, the kids jumping up to see themselves in the monitors, the smiles, and the interaction are all very interesting.
NAN: Many of your Hack A Week projects include Parallax products. Why Parallax?
DINO: Parallax is a great electronics company that caters to the DIY hobbyist. It has a large knowledge base on its website as well as a great forum with lots of people willing to help and share their projects.
About a year ago Parallax approached me with an offer to supply me with a product in exchange for featuring it in my video projects on Hack A Week. Since I already used and liked the product, it was a perfect offer. I’ll be posting more Parallax-based projects throughout the year and showcasing a few of them on the ELEV-8 quadcopter as a test platform.
NAN: Let’s change topics. You built an Electronic Fuel Injector Tester, which is featured on HomemadeTools.net. Can you explain how the 555 timer chips are used in the tester?
DINO: 555 timers are great! They can be used in so many projects in so many ways. They’re easy to understand and use and require only a minimum of external components to operate and configure.
The 555 can run in two basic modes: monostable and astable.
An astable circuit produces a square wave. This is a digital waveform with sharp transitions between low (0 V) and high (+ V). The durations of the low and high states may be different. The circuit is called astable because it is not stable in any state: the output is continually changing between “low” and “high.”
A monostable circuit produces a single output pulse when triggered. It is called a monostable because it is stable in just one state: “output low.” The “output high” state is temporary.
The injector tester, which is a monostable circuit, is triggered by pressing the momentary contact switch. The single-output pulse turns on an astable circuit that outputs a square-wave pulse train that is routed to an N-channel MOSFET. The MOSFET turns on and off and outputs 12 V to the injector. A flyback diode protects the MOSFET from the electrical pulse that comes from the injector coil when the power is turned off and the field collapses. It’s a simple circuit that can drive any injector up to 5 A.
NAN: You’ve been “DIYing” for quite some time. How and when did your interest begin?
DINO: It all started in 1973 when I was 13 years old. I used to watch a TV show on PBS called ZOOM, which was produced by WGBH in Boston. Each week they had a DIY project they called a “Zoom-Do,” and one week the project was a crystal radio. I ordered the Zoom-Do instruction card and set out to build one. I got everything put together but it didn’t work! I checked and rechecked everything, but it just wouldn’t work.
I later realized why. The instructions said to use a “cat’s whisker,” which I later found out was a thin piece of wire. I used a real cat’s whisker clipped from my cat! Anyway, that project sparked something inside me (pun intended). I was hooked! I started going house to house asking people if they had any broken or unwanted radios and or TVs I could have so I could learn about electronics and I got tons of free stuff to mess with.
My mom and dad were pretty cool about letting me experiment with it all. I was taking apart TV sets, radios, and tape recorders in my room and actually fixing a few of them. I was in love with electronics. I had an intuition for understanding it. I eventually found some ham radio guys who were great mentors and I learned a lot of good basic electronics from them.
NAN: Is there a particular electronics engineer, programmer, or designer who has inspired the work you do today?
DINO: Forrest Mims was a great inspiration in my early 20s. I got a big boost from his “Engineer’s Notebooks.” The simple way he explained things and his use of graph paper to draw circuit designs really made learning about electronics easy and fun. I still use graph paper to draw my schematics during the design phase and for planning when building a prototype on perf board. I’m not interested in any of the software schematic programs because most of my projects are simple and easy to draw. I like my pencil-and-paper approach.
NAN: What was the last electronics-design related product you purchased and what type of project did you use it with?
DINO: An Arduino Uno. I used two of these in the Photon robot.
NAN: What new technologies excite you and why?
DINO: Organic light-emitting diodes (OLEDs). They’ll totally change the way we manufacture and use digital displays.
I envision a day when you can go buy your big-screen TV that you’ll bring home in a cardboard tube, unroll it, and place it on the wall. The processor and power supply will reside on the floor, out of the way, and a single cable will go to the panel. The power consumption will be a fraction of today’s LCD or plasma displays and they’ll be featherweight by comparison. They’ll be used to display advertising on curved surfaces anywhere you like. Cell phone displays will be curved and flexible.
How about a panoramic set of virtual reality goggles or a curved display in a flight simulator? Once the technology gets out of the “early adopter” phase, prices will come down and you’ll own that huge TV for a fraction of what you pay now. One day we might even go to a movie and view it on a super-huge OLED panorama screen.
NAN: Final question. If you had a full year and a good budget to work on any design project you wanted, what would you build?
DINO: There’s a project I’ve wanted to build for some time now: A flight simulator based on the one used in Google Earth. I would use a PC to run the simulator and build a full-on seat-inside enclosure with all the controls you would have in a jet airplane. There are a lot of keyboard shortcuts for a Google flight simulator that could be triggered by switches connected to various controls (e.g., rudder pedals, flaps, landing gear, trim tabs, throttle, etc.). I would use the Arduino Leonardo as the controller for the peripheral switches because it can emulate a USB keyboard. Just program it, plug it into a USB port along with a joystick, build a multi-panel display (or use that OLED display I dream of), and go fly!
Google Earth’s flight simulator also lets you fly over the surface of Mars! Not only would this be fun to build and fly, it would also be a great educational tool. It’s definitely on the Hack A Week project list!
Editor’s Note: This article also appears in the Circuit Cellar’s upcoming March issue, which focuses on robotics. The March issue will soon be available for membership download or single-issue purchase.
RobotBASIC co-developer John Blankenship accomplishes a lot in his “cluttered” Vero Beach, FL-based workspace.
He develops software, designs hardware, packages robot parts for sale, and write books and magazine articles. Thus, his workspace isn’t always neat and tidy, he explained.
“The walls are covered with shelves filled with numerous books, a wide variety of parts, miscellaneous tools, several pieces of test equipment, and many robot prototypes,” he noted.
“Most people would probably find my space cluttered and confining, but for me it comforting knowing everything I might need is close at hand.”
Blankenship co-developed RobotBASIC with Samuel Mishal, a friend and talented programmer. The introductory programming language is geared toward high school-level students.
You can read Blankenship’s article, “Using a Simulated Robot to Decrease Development Time,” in the March 2014 edition of Circuit Cellar. He details how implementing a robotic simulation can reduce development time. Here’s an excerpt:
If you have ever built a robot, you know the physical construction and electronic aspects are only the first step. The real work begins when you start programming your creation.
A typical starting point is to develop a library of subroutines that implement basic behaviors. Later, the routines can be combined to create more complex behaviors and eventually full-blown applications. For example, navigational skills (e.g., hugging a wall, following a line, or finding a beacon) can serve as basic building blocks for tasks such as mowing a yard, finding a charging station, or delivering drinks to guests at a party. Developing basic behaviors can be difficult though, especially if they must work for a variety of situations. For instance, a behavior that enables a robot to transverse a hallway to find a specified doorway and pass through it should work properly with different-width hallways and doorways. Furthermore, the robot should at least attempt to autonomously contend with problems arising from the imprecise movements associated with most hobby robots.
Such problems can generally be solved with a closed-loop control system that continually modifies the robot’s movements based on sensor readings. Unfortunately, sensor readings in a real-world environment are often just as flawed as the robot’s movements. For example, tray reflections from ultrasonic or infrared sensors can produce erroneous sensor readings. Even when the sensors are reading correctly, faulty data can be obtained due to unexpected environmental conditions. These types of problems are generally random and are therefore difficult to detect and identify because the offending situations cannot easily be duplicated. A robot simulator can be a valuable tool in such situations.
Do you want to share images of your workspace, hackspace, or “circuit cellar”? Send your images and space info to firstname.lastname@example.org.
If you missed the World Maker Faire in New York City, you can pick up Circuit Cellar’s February issue for highlights of the innovative projects and hackers represented there.Veteran electronics DIYer and magazine columnist Jeff Bachiochi is the perfect guide.
“The World Maker Faire is part science fair and part country fair,” Bachiochi says. “Makers are DIYers. The maker movement empowers everyone to build, repair, remake, hack, and adapt all things. The Maker Faire shares the experiences of makers who have been involved in this important process… Social media keeps us in constant contact and can educate, but it can’t replace the feeling you can get from hands-on live interaction with people and the things they have created.
“It should be noted that not all Maker Faire exhibitors are directly involved with technology. Some non-technological projects on display included the ‘Art Car’ from Pittsburgh, which is an annual revival of an old clunker turned into a drivable art show on wheels. There was also the life-size ‘Mouse Trap’ game, which was quite the contraption and just plain fun, especially if you grew up playing the original game.”
Bachiochi’s article introduces you to a wide variety of innovators, hackers, and hackerspaces.
“The 721st Mechanized Contest Battalion (MCB) is an amateur radio club from Warren County, NJ, that combines amateur (ham) radio with electronics, engineering, mechanics, building, and making,” Bachiochi says. “The club came to the Maker Faire to demonstrate its Emergency Antenna Platform System (E-APS) robot. The robot, which is designed for First Responder Organizations, will turn any parking lot lamppost into an instant antenna tower (see Photo 1).”
The keen and growing interest in 3-D printing as a design tool was evident at the Maker Faire.
“Working by day as an analog/mixed-signal IC design engineer for Cortina Systems in Canada, Andrew Plumb needed a distraction. In the evenings, Plumb uses a MakerBot 3-D printer to create 3-D designs of plastic, like thousands of others experimenting with 3-D printing,” Bachiochi says. “Plumb was not satisfied with simply printing plastic widgets. In fact, he showed me a few of his projects, which include printing plastic onto paper and cloth (see Photo 2).”
Also in the 3-D arena, Bachiochi encountered some innovative new products.
“It was just a matter of time until someone introduced a personal scanner to create digital files of 3-D objects. The MakerBot Digitizer Desktop 3-D Scanner is the first I’ve seen (see Photo 3),” Bachiochi says. “It uses a laser, a turntable, and a CMOS camera to pick off 3-D points and output a STL file. The scanner will create a 3-D image from an object up to 8″ in height and width. There is no third axis scanning, so you must plan your model’s orientation to achieve the best results. Priced less than most 3-D printers, this will be a hot item for 3-D printing enthusiasts.”
Bachiochi’s article includes a lengthy section about “other interesting stuff” and people at the Maker Faire, including the Public Laboratory for Open Technology and Science (Public Lab), a community that uses inexpensive DIY techniques to investigate environmental concerns.
“For instance, the New York chapter featured two spectrometers, a you-fold-it cardboard version and a near-infrared USB camera-based kit,” Bachiochi says. “This community of educators, technologists, scientists, and community organizers believes they can promote action, intervention, and awareness through a participatory research model in which you can play a part.”
At this family-friendly event, Bachiochi met a family that “creates” together.
“Asheville, NC-based Beatty Robotics is not your average robotics company,” Bachiochi says. “The Beatty team is a family that likes to share fun robotic projects with friends, family, and other roboticists around the world. The team consists of Dad (Robert) and daughters Camille ‘Lunamoth’ and Genevieve ‘Julajay.’ The girls have been mentored in electronics, software programming, and workshop machining. They do some unbelievable work (see Photo 4). Everyone has a hand in designing, building, and programming their fleet of robots. The Hall of Science is home to one of their robots, the Mars Rover.”
There is much more in Bachiochi’s five-page look at the Maker Faire, including resources for finding and participating in a hackerspace community. The February issue including Bachiochi’s articles is available for membership download or single-issue purchase.
Contact: Elizabeth Presson
Featured Product: The XBee product family (www.digi.com/xbee) is a series of modular products that make adding wireless technology easy and cost-effective. Whether you need a ZigBee module or a fast multipoint solution, 2.4 GHz or long-range 900 MHz—there’s an XBee to meet your specific requirements.
Product information: Digi now offers the XBee Wi-Fi Cloud Kit (www.digi.com/xbeewificloudkit) for those who want to try the XBee Wi-Fi (XB2B-WFUT-001) with seamless cloud connectivity. The Cloud Kit brings the Internet of Things (IoT) to the popular XBee platform. Built around Digi’s new XBee Wi-Fi module, which fully integrates into the Device Cloud by Etherios, the kit is a simple way for anyone with an interest in M2M and the IoT to build a hardware prototype and integrate it into an Internet-based application. This kit is suitable for electronics engineers, software designers, educators, and innovators.
Exclusive Offer: The XBee Wi-Fi Cloud Kit includes an XBee Wi-Fi module; a development board with a variety of sensors and actuators; loose electronic prototyping parts to make circuits of your own; a free subscription to Device Cloud; fully customizable widgets to monitor and control connected devices; an open-source application that enables two-way communication and control with the development board over the Internet; and cables, accessories, and everything needed to connect to the web. The Cloud Kit costs $149.
John Blankenship has spent decades teaching robotics—and written many books on the subject. His love of teaching inspired him to co-develop the RobotBASIC robot programming language. I recently caught up with John to discuss some highlights from his teaching career and what’s next for RobotBASIC—Nan Price, Associate Editor
NAN: How did you become interested in robotics?
JOHN: As a child, I often saw robots on television but was fully aware that there were no computers capable of making such fictional creations a reality. In the 1970s, microprocessors such as Intel’s 8080 and MOS Technology’s 6502 gave me hope that real robots would eventually become part of our future.
I found I could motivate my students by linking lab projects to robotic topics. For example, instead of just graphing the output from an active filter, I had my students use op-amps to detect an ultrasonic wave so they could later build a ranging sensor. I firmly believe that if you want to motivate students, you must give them projects with a purpose.
NAN: You spent more than 30 years teaching programming, electronics, and robotics. What did you gain from that experience?
JOHN: I enjoyed teaching electronics, but I loved teaching programming. Nothing else even comes close to develop critical thinking skills in students. Watching those skills develop was the reason I taught.
After seeing how my hardware robotic projects motivated students, I knew I wanted something similar for my programming classes. Eventually I developed a library of C routines that simulated a simple on-screen robot. What made the simulated robot special is that it supported numerous sensors (an electronic compass, two levels of proximity sensors, a ranging sensor, line detection, beacon detection, color tracking, and more) that enabled students to solve relatively complex, real-world robotics problems without building any hardware.
This structure made programming fun because it gave programming assignments a purpose. Students no longer had to be convinced that it was important to learn the syntax for a loop or how “if” statements controlled flow to make decisions—they wanted to learn details so they could use them to solve the exciting problems being proposed for them. Which would you find more exciting: writing a program to count the number of words in a string or teaching a robot to follow a line? Better yet, imagine motivating students by having a contest to see whose robot could follow a line the fastest.
NAN: How and why did you develop the RobotBASIC programming language?
JOHN: When I retired from teaching I wanted a way for other teachers to utilize a simulated robot to motivate their students. I could have just published my C libraries, but that generally would have limited their use to college classes where C is usually taught. I felt strongly that much younger students needed to be introduced to programming so they could develop not just logical thought, but also an appreciation for math and engineering.
I love the C language (RobotBASIC is written in C), but in my opinion, it is far too cryptic to be used as a first language. I wanted to encase my routines in a BASIC-like language that would enable nearly anyone to program a simulated robot.
I began writing my own language and was reasonably pleased with the initial efforts. I demonstrated the program to a good friend of mine, Samuel Mishal, who is easily the greatest programmer I have ever known. After politely applauding my efforts, he showed me an interpreter he had been working on to help him with a DSP project. His language was very polished and far superior to my work. He integrated my simulator with his interpreter and we named it RobotBASIC.
Even though we planned from start to freely distribute RobotBASIC, we knew teachers could not devote time to learning a language that was just a robot simulator. We began adding new features and capabilities. The more we added, the more excited we became. We started testing the new language by developing robotic behaviors and writing simple video games. Every time we needed something special, we added it to the language.
RobotBASIC currently has nearly 900 commands and functions—far more than most languages. More importantly though, since there are built-in functions to handle many things programmers normally have to do themselves, the language is very fast for an interpreter.
We felt RobotBASIC was an ideal language for introducing high school students to programming, but we wanted more. We added hardware I/O capabilities and created a wireless protocol that enabled RobotBASIC to control real robots with the same programs that control the simulation. At that point, the language could easily handle college-level projects but we knew the BASIC stigma would be a problem. To help with this, we added the option to use a modified C-style syntax, making it easier for students to transition to C or even Java.
We also decided to address some backward capability by adding legacy-style I/O commands, making it easy to teach basic programming skills to even fifth graders. This enables school systems to utilize RobotBASIC from lower grades through high school without having to teach a new environment when new capabilities are needed. And if the C-style syntax is introduced in the upper grades, students will be better prepared for college programming courses.
NAN: What are some uses for RobotBASIC?
JOHN: Even though students’ needs were a driving force in our development process, RobotBASIC’s I/O capabilities make it a great language for hobbyists involved with robotics or other electronic-oriented projects. For example, it only takes a few lines of code to gather data from a remote temperature sensor using a wireless link and to transmit that information to another user over the Internet.
RobotBASIC also has many commands that facilitate flicker-free animation and simulation. This means teachers have the option of motivating students by teaching how to write simple video games.
As much as I love the robot simulator, I have to admit that many students get even more excited about animation than they do about robots. The point is that RobotBASIC provides many options.
NAN: You offer several types of RobotBASIC seminars geared toward children, university students, and robot clubs. You also lead seminars introducing programming and robotics. What do you enjoy most about teaching? What do attendees gain from your seminars?
JOHN: I love teaching and I especially love showing teachers new ways to motivate their students. I understand that every school and teacher is different and I make sure I satisfy their goals by customizing each and every presentation based on their individual needs. I am always amazed that schools can’t believe that RobotBASIC is totally free. There are no acquisition costs, no upgrade fees, and no licenses—ever! RobotBASIC is free for hobbyists too. Circuit Cellar readers can download a copy from RobotBASIC.org.
NAN: Are you currently working on or planning any robotics-related projects?
JOHN: Many RobotBASIC users have been asking for a more advanced book on animation and video games. Unfortunately, my work on our new RobotBASIC Robot Operating System (On a Chip) has been monopolizing all my time for the last couple of years. Now that it is finally finished, I have started writing again. I think the new book will be worth the wait because it also discusses how RobotBASIC can interact with the new Windows 8 sensors (e.g., cameras, compass, accelerometer, touchscreen, etc.) The chapter I am currently working on enables darts to be thrown using finger movements on a tablet’s touchscreen.
NAN: Do you have any advice for Circuit Cellar readers who are considering building their own autonomous robots?
JOHN: I think the biggest mistake most robot hobbyists make is they spend far too much time constructing a robot before having a detailed understanding of its sensory needs and the algorithms necessary to accomplish their goals. If they would test their ideas first with our simulator, they would have the information necessary to build a platform that can actually meet their needs. Furthermore, they could control their real robot with the very same programs they developed on the simulator.
For my entire life, my mother has been a technology trainer for various educational institutions, so it’s probably no surprise that I ended up as an engineer with a passion for STEM education. When I heard about the Raspberry Pi, a diminutive $25 computer, my thoughts immediately turned to creating low-cost mobile computing labs. These labs could be easily and quickly loaded with a variety of programming environments, walking students through a step-by-step curriculum to teach them about computer hardware and software.
However, my time in the robotics field has made me realize that this endeavor could be so much more than a traditional computer lab. By adding actuators and sensors, these low-cost SBCs could become fully fledged robotic platforms. Leveraging the common I2C protocol, adding chains of these sensors would be incredibly easy. The SBCs could even be paired with microcontrollers to add more functionality and introduce students to embedded design.
There are many ways to introduce students to programming robot-computers, but I believe that a web-based interface is ideal. By setting up each computer as a web server, students can easily access the interface for their robot directly though the computer itself, or remotely from any web-enabled device (e.g., a smartphone or tablet). Through a web browser, these devices provide a uniform interface for remote control and even programming robotic platforms.
A server-side language (e.g., Python or PHP) can handle direct serial/I2C communications with actuators and sensors. It can also wrap more complicated robotic concepts into easily accessible functions. For example, the server-side language could handle PID and odometry control for a small rover, then provide the user functions such as “right, “left,“ and “forward“ to move the robot. These functions could be accessed through an AJAX interface directly controlled through a web browser, enabling the robot to perform simple tasks.
This web-based approach is great for an educational environment, as students can systematically pull back programming layers to learn more. Beginning students would be able to string preprogrammed movements together to make the robot perform simple tasks. Each movement could then be dissected into more basic commands, teaching students how to make their own movements by combining, rearranging, and altering these commands.
By adding more complex commands, students can even introduce autonomous behaviors into their robotic platforms. Eventually, students can be given access to the HTML user interfaces and begin to alter and customize the user interface. This small superficial step can give students insight into what they can do, spurring them ahead into the next phase.
Students can start as end users of this robotic framework, but can eventually graduate to become its developers. By mapping different commands to different functions in the server side code, students can begin to understand the links between the web interface and the code that runs it.
Students will delve deeper into the server-side code, eventually directly controlling actuators and sensors. Once students begin to understand the electronics at a much more basic level, they will be able to improve this robotic infrastructure by adding more features and languages. While the Raspberry Pi is one of today’s more popular SBCs, a variety of SBCs (e.g., the BeagleBone and the pcDuino) lend themselves nicely to building educational robotic platforms. As the cost of these platforms decreases, it becomes even more feasible for advanced students to recreate the experience on many platforms.
We’re already seeing web-based interfaces (e.g., ArduinoPi and WebIOPi) lay down the beginnings of a web-based framework to interact with hardware on SBCs. As these frameworks evolve, and as the costs of hardware drops even further, I’m confident we’ll see educational robotic platforms built by the open-source community.