Oh_Oh Experiments With Robots

Robots are becoming a common educational resource. Together with other applied science fields like wearable computing, or music instrument design, robotics provides an alternative door into traditional fields like math and physics, as well as into more contemporary ones like computer science and complex systems.

Oh_Oh goes pacman
(cc) 2010, Yang-Cuartielles, Oh_Oh goes pacman

This is how I started the entry for the open source project that is going to be gathering the iformation about Oh_Oh the open hardware robot that MA. Student in Interaction Design Xun Yang and myself designed for the Spanish Cultural Center in Mexico City. All the work is being done at K3’s laboratory for prototyping during the first half of July. Later that month I conducted an eight-sessions-long workshop with kids and youngsters in the ages 10-18. This text is about the process, which is a continuation of the workshops in electronics for kids explained in this other article.

The Context

FARO is an art centre in the area of Iztapalapa, which happens to be one of the most populated municipalities in the world with over 3m inhabitants. At FARO it is possible to get an education in non-academic fields mostly related to arts and crafts. There is also a Computer Clubhouse donated by Intel as part of the Computer Clubhouse Village project initiated by MIT.

Participants in the Computer Clubhouse activities range from 10 to 18 years old. The CC is part of a world-wide network of centers that communicate over a network infrastructure called the Computer Clubhouse Village. This is a closed network reserved to the CC users that protects the privacy of the kids. In my opinion it also constrains the possibilities of conducting research about it to those directly involved like MIT, Intel, Adobe, Lego and the like; this is just a side note and should be researched further. Anyways the CCV offers a huge opportunity for researchers in the field of technology and education to test, evaluate, and iterate designs.

The technology is provided by partners like the ones previously mentioned. However the CC at FARO runs on computers and servers that are over 8 years old. There are two Lego Mindstorms kits, about 20 stationary computers, a (really old) server, a not-so-decent digital camera, and a small sound studio. On top of that there are 15 Arduino starter kits (donated by the Open Source project Arduino.cc directly), a semi-professional DV camera donated by the Spanish cultural association La Claqueta, and now 10 Open Source Oh_Oh robots designed by Xun and myself.

the painting robot
(cc) 2010, Yang-Cuartielles, the painting robot
initial Oh_Oh sketches
(cc) 2010, Yang-Cuartielles, initial Oh_Oh sketches

The CC space is run by one single person that is paid for a half-day work shift and ends up investing over 10 hours/day up to 6 days/week. This job is financed directly by the Spanish CCEMX, and not even by the FARO itself, since it doesn’t have that position reflected in the official list of duties. Obviously the ecology of the system is not the best, not in technical terms, not from the human resources perspective.

Among other duties, the CC manager has taken as a personal mission making sure the whole FARO is having a proper network infrastructure, and that all the computers within the CC work. Since the equipment’s average age is over 5 years old, the computer’s OS cannot be updated any longer. Therefore we decided to migrate to Ubuntu Linux, which allowed us reusing other computer equipment like old parallel port scanners, printers, etc.

The kids attending the activities are requested to fulfill a certain amount of hours at the CC in order to be eligible to bigger activities like excursions to conferences, or being part of workshops with external tutors. Usually they register at a computer station when they enter the room, in order to monitor how many hours/week they invest at the space. When there are no workshops, the kids can use the room for whatever they feel like. Some of them -usually the older ones- work in their projects like editing a movie, illustrating an image, or retouching a photograph; others play online or chat with their friends letting the music sound loudly in the room.

When workshops start, no one is allowed to play online, the music from the different terminals is shut down and kids group in teams. There are courses in learning about tools like Gimp, Inkscape, text editing, or browsing. There is an external teacher arranging stop motion animation workshops, and sometimes the guys journalism group (one of the workshops for older people) come in the room to learn about blogging as well. Since I have been involved with FARO for about a year now, they have started offering classes about the basics in electronics and robotics.

The Idea

After our first and second sessions working with electronics, the overall impression was that kids wanted to go into robotics. We studied the possibility of running a course using the existing equipment, but there were just two robots there and our decision of migrating to Linux made hard to run the existing software to program and command the robots. I made some quick research on the possibilities and realized it was possible to develop our own hardware with parts existing in Mexico. I didn’t want to create yet another piece of hardware that would find endless problems to be placed in people’s hands. After 5 years working with Arduino, I have learned quite a lot about what it means to import hardware to different countries. Latinamerica is like a bureaucratic maze where it is harder to get a 2USD microcontroller than a 30.000USD car. When designing something it is important to rely on parts existing on-site.

I found I could get processors as well as wheels and motors with gears that would make the robot move around. I also found that H-bridges, a component used to easily control motors, were cheaper than back in Sweden. I also figured out it was possible to get IR-remote-controls for less than 20SEK the piece (new!! and including batteries). I made a quick calculation and noticed that making a robot would cost as much as buying an Arduino board. The cost of an Arduino board in the EU or the USA is equivalent to one meal at a mid-priced restaurant, in Mexico is the equivalent to more or less two meals, something that is still within a reasonable price-range.

I made some sketches based on previous experiences with robots and in a bit less than a week I had a clear idea on how the robot should look like. I also noticed that I had a little less than a month to create the final hardware for the robot, create the software for it, and create a series of examples that could be meaningful. Therefore I made a call to some of the students that had manifested an interest in collaborating with K3’s lab over the summer. Since the call was made pretty late in the process there was only one that had the chance to join, this is when Xun Yang, MA. Student in Interaction Design, jumped in the process to take care of initial software design, as well as robot behavior definition (more on this later in the article).

Design Decisions, Prototype 1

If you are interested in the precedents that inspired us in the creation of the Oh_Oh robot, you should read this article, where I went through the two main designs influencing my way of thinking about cheap robot building: the Asuro Robot, and the Imori Kit basic robot. Based on the experiences I had with those, I thought that the main technical aspects behind the design should be:

  • an ATmega processor, the design should allow using the mega8 pinout to control the motors, which means being careful where to place the PWM enabled pins. The reason for this is that it is hard to find better microcontrollers in Mexico than the already-very-old ATmega8 from Atmel
  • an H-bridge L293N, to control both speed and direction on the two DC motors that would drive the robot
  • two DC motors with gear boxes, and wheels that could be found in Mexico
  • a ping pong ball as the back wheel
  • there will be no sensors on board, they will be placed on a daughter board situated in front of the robot that we decided to call nose in the same way Arduino has got shields
  • there should be the possibility to mount a shield for Arduino on top of the robot, allowing bringing extended functionality from community created designs over the 5 years of existence of the Arduino project
  • the possibility to be programmed from Arduino’s IDE (this affects the Software)
  • a button and some LEDs on board
  • a connection with the third PWM to allow easy connection of a servo motor
  • powered by 9V batteries
first iteration of the Oh_Oh robot
(cc) 2010, Yang-Cuartielles, Oh_Oh robot iteration #1

I created the design in one day of work using the freely available Eagle software from Cadsoft (recently acquired by the electronics distributor Farnell). There is a lot of Open Source Hardware being made using this package of software. Submitted it to a Swedish manufacturer and got boards 24 hours later. Xun assembled it from parts I had bought in Mexico and we got ready to test in less that two days. Xun had a week of experimentation to come up with ideas on which were the flaws in my design when trying to make a meaningful series of exercises out of the robot. At that point:

  • the robot had no name, it had no personality and we needed to create some kind of narrative around it
  • there was no initial set of sensors that the kids could play with
  • there was no on-off switch, we had to be pulling the battery connector the whole time in order to save batteries
  • the on-board LEDs were placed in a way that looked like eyes to the robot, however one of them was always lit on while the other one was programmable via software … this was misleading, both LEDs should be easy to program via software
  • the location of the batteries that I had envisioned initially was not the optimal one
  • the sensor connector was somehow ordered wrongly, from a point of view of the affordances it was more intuitive to invert the order of the pins on the nose connector
  • we were in the need of an on-board button that would allow for direct interaction with the robot

Design Revision, Prototype 2

Taking all of this into account, I started drafting the second version of the hardware. There was no time for a third iteration of the hardware, therefore I was extra careful in the choices I was making for parts. I realized I was in the need of having a proper finishing of the pcb, with silkprint and solder-layer. For those of you reading this not knowing what it means, the following picture shows iterations one and two of the design. The white PCB is the Oh_Oh robot design, the design we tested with the kids. The one in yellow is the initial design we made in 24 hours. Besides the design revisions, there is a difference in terms of manufacturing that is pretty apparent. The white PCB is having a solder mask that protects the copper from possible shortcircuits when manipulating the object. It also has a silkprint layer in blue that includes visual information about the different connectors, etc.

two iterations of the Oh_Oh design by X. Yang and D. Cuartielles
(cc) 2010, Yang-Cuartielles, Oh_Oh iterations #1 (bottom) and #2 (top)

For those interested in the technology, the 2nd iteration of Oh_Oh’s design brings in:

  • a power supply based in a 5V voltage regulator
  • room for a pin-compatible ATmega8/168/328 processor using an internal oscillator
  • two software programmable LEDs, one extra LED to show that the batteries are on
  • one on-board pushbutton
  • a connector for a servo motor
  • one H-bridge, type L293D to command the motors
  • two DC-motors with built in gears (but could be substituted by two servo motors easily)
  • a front connector for the nose connector where to plug different pre-built sensor boards with up to 6 analog/digital sensors each
  • the possibility of connecting many existing shields for Arduino
  • a 6-pins programming connector as used in many Arduino-compatible designs like Lilypad, Arduino Pro, etc. The reason to use this kind of connector is that it offered the possibility of using programming cables from different vendors, even a hacked Arduino board, what would make it very cheap to get a way to program the robot
Oh_Oh sensor nose
(cc) 2010, Yang-Cuartielles, Oh_Oh's sensor nose v0001

At this point we had already started to work in the creation of the robot’s narrative. It had to be a little nervous robot with predefined behaviors like running away from the light or getting crazy when sound was too loud. The idea was creating small blocks of software that would bring the kids to get some interest in the robot, before going deeper in how to get it to do “meaningful” operations. Therefore I created the robot’s first sensor nose as a small face where the sensors were arranged resembling the different parts: eyes (light sensors), nose (microphone), mouth (IR-remote-control receiver), and ears (soldering points for other sensors).

The idea of the nose allows creating a whole ecology of different sensor boards that can be attached to the robot for it to perform different operations. We created this first nose and named it v0001. Also this decision eases the way we have to lay out components on the main board. By reducing the amount of components on it, we make easier to connect things to it. The connector for the nose is a standard one with a pitch between pins of 2,54mm what allows using any type of prefab boards to create your own sensor boards to attach to the robot.

12 robots running around
(cc) 2010, Yang-Cuartielles, 12 handmade robots at FARO

The Software

From the moment we had prototype #1 it became easy to start working with the software. Xun took control over that part while I entered the process of looking for suppliers to manufacture 20 robots at once. We sat down a couple of sessions where we decided about the robot’s narrative and sketched a couple of ideas on which where the examples we wanted to display.

Xun had the mission of creating a library that would include both low- and high-level functions. The low level ones were responsible of commanding the motors or reading the analog pins where the sensors would be attached. The high level ones should be able of attaching a behavior to the robot like “run away from light”, or “read IR-remote-control signals”. In this way it would be fairly easy introducing the workshop participants to different techniques.

You shouldn’t forget that the age range of our target audience was 10-18 years old, what made really hard to have a coherent story for everyone. The same applied to the software, the more complex, the harder it would be to get everybody to understand things. Therefore we wanted commands like the low level myRobot.left() to make the robot turn to the left or the high level myRobot.followLight() to get Oh_Oh to follow a light source.

An example of a program to get the robot to follow the light would look like follows:

#include <Oh_Oh_Robot.h>
#include <Servo.h>
// instantiate the robot
 Oh_Oh_Robot myRobot;
 void setup() {
  // read the sensor information to set up a threshold
 void loop() {

If you are not familiar with the Processing/Wiring/Arduino syntax, let me explain how this program operates. It first checks the initial light conditions surrounding the robot via the method calibrateLight(). It will set up the robot until it is re-started by turning the power off and on again. From then and on, Oh_Oh will repeat whatever is written inside the loop() method. In this case it’s said to follow the light and so it will do.

Xun had then the double mission of creating the library to handle these special robot-oriented commands, but also to create the examples the kids would play with. One thing is to make a drawing of what you want to explain, a different thing is to make the code to get to explain the thing to the kids. Xun had to make the later by himself, since I was busy revising the hardware. My involvement in that part of the process was to assist him in the things that weren’t clear to him. The Arduino community has produced a lot of documentation on how to code libraries like the one he had to produce, so I didn’t need to concentrate on that.

To simplify our collaboration and maximize the dissemination of the software aspects of the project, we created an online repository for the source in the project, both the libraries and the design files. You can visit this website and you will find our code in there. There is still a lot to clean, now that we have ran our first test with users, we will have to replicate the experiment in Sweden, analyze the educational goals, and rewrite big blocks of the code to be even more user-friendly.

Also, as I mention in the article on the Google Code project, there are a series of software packages handling programming from a visual point of view, that we should analyze in order to make the whole programming process even more user-friendly.

There are some experiences in making possible to visually program Arduino:

  • the EU funded project EduWear created a layer on top of Arduino’s IDE that aimed creating code in a similar fashion as Scratch does, it is called Amici and can be found (for MAC only) here
  • MAX/MSP presented at the conference Sketching in Hardware 2009 a prototype of a patch that can send code to Arduino as mentioned here
  • ModKit is an online platform to program Arduino from a browser, again based on the Scratch paradigm
  • a combination of Scratch + Serial Server as explained here

    Considering the time constrains we have for the first phase of the Oh_Oh project (concept, prototype, first manufacturing run, and test with kids made in less than two months) we have decided that no matter how interesting VPUIs are, we are not going to even consider them. Moving into VP is a latter issue for us.

    As I write these lines, I am trying to get Amici, the first alternative mentioned here, to run on Linux. If I manage to do that, I will also build the blocks needed to program the robot and, in that way, simplify the programming of robots by means of using VP oriented IDEs. However I am not sure how much Amici is a dead end, since the development is on standby, it is not even compiling on the latest Arduino 0018 revision, and it hasn’t been ported in a clean way to the current way of packaging the software which uses ANT instead of the previous MAKEFILES.

    The Ecology of our Test

    Our tests consisted of a series of sessions, 10 in total, dedicated to the construction of shells for the robots, learning about programming their intelligence, and looking for the best alternatives to compete against the others in solving mazes, or driving the robot along a certain path. The agenda for the course looked as follows:

    • days 1-2: construct the shells for the robots. They are made of paper and take some time to dry, therefore they have to be made first. The kids spent time creating them, painting them, and constructing the narrative around them
    • days 3-4: basic electronics in parallel with finishing the shells. This would allow the older kids to get something to do while the younger ones were still working with the shells
    • day 5: introduction to robotics, basic motion test
    • day 6: the robot that follows light, using LDRs
    • day 7: the robot that responds to sound
    • day 8: painting on the floor
    • day 9: using the IR-remote-control
    • day 10: create your own behavior, add the shell to the robot

    I didn’t come in until day 5. As part of my general project with FARO, I am supposed to be doing knowledge dissemination, which means there are parts that I already delivered in the past, and the basic aspects of electronics is something the CC manager can already handle by himself. After that, the workshop was ran by me. As I will explain later, we followed the initial agenda pretty well, with some minor changes.

    All the sessions were 3 hours long (15 to 18), except for days 5 and 10, when we would spend the whole day with the kids between 12 and 17. The CC was opened anyway from 10AM and some kids would arrive early in the morning to spend time with their friends, play online, chat, or work in their other projects.

    The selection of participants was made by the CC manager, who chose 20 applicants among the kids that were more active and/or had been at one of the electronics workshops before. The kids were in the last days before summer vacation, but due to the broad age-range (10 to 18) not all of them had the same shifts, actually some were on vacation while others had to go to class in the mornings.

    In the class we were three people present running the show: the CC manager, a social worker (a volunteer that spends a certain amount of hours doing social work), and myself. The social worker’s role was mostly to film the course in order to put it online for the other Clubhouses around the world to get to know about this workshop. The CC manager and myself were running back and forth to the different stations to help the kids with their projects. In total we planned on having 10 groups, with the kids joining into couples. All the kids were familiar to the internet, to basic programming, and very basic Arduino. They could start the IDE by themselves, look for examples, understood basic commands like digitalWrite() to turn a pin on/off, and save their own examples to use them the day after.

    We worked preparing some group dynamics trying to integrate the different age groups that we would have to use later on. Most of the preparation time was spent mounting the wheels on the robots; I brought the robots from Sweden, but motors and wheels had been purchased by the CC manager and were waiting for me to arrive and glue them to the boards.

    The Test

    From idea to workshop in robotics we had just 45 days. This is not much time and we had to work about 6 days/week to get things done. Xun would code, I would design boards, we would meet and revise his code, sleep 4 hours and come back to the lab to run further tests. I would order materials and troubleshoot hardware problems Xun would find. In parallel I had other duties having to do with my normal assistant professor position, and Xun was finishing a project for an external contractor. I could estimate we spent 60% of our time working with this up to the last week, when we got the final boards from Italy and we had to solder all the components to get at least 10 functional robots for the workshop.

    Based on my expected death-by-accident ratio for the robots, I decided we had to put together 15 robots. I would like to leave 10 at FARO, donate 1 to CCEMX, since they were commissioning the whole project, and still have 4 for the eventual accidents that would happen with the kids. It might sound like having 50% more material as needed is a lot, but you should look at this from an industrial design perspective … we had 20 users to test one design and eventually all of them could break the device at once no matter how much we had tested it before. Therefore, in my eyes, having just 5 extra robots sounded like a risky thing to do, since there was no chance to make big changes to the design on-site … we were tens of thousands of kilometers away from the lab … and Xun wouldn’t join, so I had to be ready for the unexpected.

    hack to improve power issues with servo motors
    (cc) 2010, Yang-Cuartielles, hack to reduce glitches

    Once in Mexico, I had to introduce small improvements on the robots everyday. The course was in the afternoons, so I would wake up in the morning, drive down to the city center, where the electronics shops were located, buy components, drive back -it is over one hour taxi ride each way- solder components on the robots, or glue stuff on them, or whatever, revise the code to be working with the latest adjustments, and go into class. Many days I had no time to eat until the workshop was done and we had cleaned the lab at about 20.00.

    The main adjustments I had to do to get the robots to work properly were:

    • adding the on/off switch. While mounting the robots back in Europe, we couldn’t find the dip-switches we used on our design. We decided to bypass them, but that meant the kids had to unplug the battery connectors every time they wanted to reprogram the robot. This lead to broken battery connectors … if I recall right it was 4 the first day. So I went on buying new battery connectors as well as some kind of on/off switches that I hacked on the robots to avoid having to fix the battery connectors every occasion there was a robotics class
    • adding a capacitor to avoid glitches coming from the servo motor. Some of the servos would demand a lot of energy, forcing the robot to reset. This would be fixed by simply adding a capacitor that would store energy between the servo’s 5V and 0V pins
    • write a whole new library to control the robots via IR. Xun had made a library for the kind of remote control we had found in the first place. But once I made it to Mexico and I had to get 10 remote controls to run the course, I found a much cheaper alternative, what brought me to the situation when I had to rewrite the remote control library. I had no time to integrate it properly in the Oh_Oh library Xun wrote, so this still needs rewriting, but I think I figured out a way to make this in a very elegant way
    • write a series of simple examples for writing on the floor. When Xun and I imagined the exercise of painting on the floor, we didn’t think about how much would the kids know at that point about using external software. Our writing example included the use of a Processing and an Arduino sketch at the same time. No matter how handy this sounds in the first place, it is not trivial and I realized I had to make it differently
    • initially our robots were taking about 10 seconds to restart after reset, that was not very good considering the kids were used to Arduino, where the restart happens instantly (actually a few milliseconds), also I figured out there was a bug in the way Arduino’s IDE was forcing the robot to reset via the USB-serial programming cable. Nobody had noticed this before, because nobody had ever tried to program Arduino boards on Linux using the kind of cheap cables we purchased for this workshop. Summarizing, I had to recompile a specially patched version of Arduino’s IDE that would allow automatic reset of the robots, create a new bootloader for them that could restart immediately, and integrate all the new examples Xun had written. All these operations were just adding to the experience of programming, making the programming of the robots as easy as programming Arduino boards

    On top of all the technical issues we found and that we managed to solve during the development of the workshop, we had to cope with the fact the age-range was far too broad, and that the group was far too big for this kind of test. We realized that:

    • letting the kids that were friends to work together was leading to end up having those more shy than others to more or less work by themselves
    • kids would group up with others in the same age, what would lead to have groups going much faster  than others due to their ability to understand the exercises
    • boys would go with boys and girls with girls
    • internet is a powerful tool, but also a burden … the CC is run as a cybercafe 6 hours/day and it is hard to move people away from that thought that this space is more than just a computer room
    • not all the kids would attend at all times, furthermore, some dropped after the first week (3) because they had subscribed to other activities in parallel to this one that were also happening at FARO

    We coped with this issues by trial and error. After a first day of unsuccessful group dynamics, we decided to have the CC manager, who knows all the kids and their families, to form the groups attending the basic concept of mix, both in age, gender and familiarity. After a couple of sessions, we observed how the groups started to work better and how they would accept working in groups where  they would not necessarily collaborate with their best friends.

    We disconnected the internet randomly, making very clear that the workshop time was for working in projects, and we invited people not in a workshop to leave depending on how much they would disturb our activities (these solutions might seem obvious, but they were not in the way things are handled at FARO usually … and we are talking about changing a 10 years long way of proceeding).

    We introduced online collaboration tools like Etherpad to show the kids how they could actually work in a network, while chatting with the others also working in the same location. This tool proved to be really powerful to explain things having to do with coding for the robots. Specially because the syntax is not trivial and the younger kids don’t know English. Once we move into VP, we will need to figure out ways to make powerful online collaboration tools that would allow copying and pasting code that will not like code.

    The final day consisted in integrating the two halves of the workshop: the one about building shells and the one about coding for robots. We had little time before for doing this and we couldn’t let many of the kids using tools like a dremmel or a soldering iron at first. We arranged the kids in some sort of small sweatshop where we had the older ones to use the tools and the younger ones to glue parts, add tape on open wires, or cut wire. It took the whole session to get the final 8 robots to integrate small blinking lights on their shells. The final part in the process was testing, one of the kids was taking the robots one by one and made sure, using software, that the LEDs on the shell were blinking when sending the right commands from the IDE.

    final view of the robots made by the kids
    (cc) 2010, Yang-Cuartielles, final view robots by the kids

    In the meanwhile, I must mention we were lucky this time. Even if we were in the middle of the rain season, we had electricity during the whole workshop, what means we didn’t have to postpone any of the sessions. Mexico is pretty tricky when it comes to rain, and many roads get flooded what provokes unavoidable delays with transportation. Some days we had to start one hour delayed, but we were counting on having educational contents for only 2 hour-blocks of the three hours we had scheduled, counting on having a break in the middle, what actually saved the situation.


    If I try to group the main aspects of what I learned while developing this project, I should mention that:

    • it is possible to go from idea to prototype in a really short time period, and the development of this project is a proof of that. On top of that, a relatively small research group can generate tools in almost no time, and plan ahead in order to run tests with mid-sized user groups. This conclusion might seem trivial, but it isn’t. Xun and I worked part time with the project, we counted with some help in manufacturing, but we had no initial knowledge about robotics as such. We acquired all our knowledge based on information we found online and on books. We designed, built, tested, iterated, and deployed robots and a whole set of educational experiments around them. It is also not that expensive, relying on open source tools it is possible to deploy experiments like the one here explained for the cost of the parts and the men-hours
    • it is important to count with a series of group dynamic oriented tools to apply on-site when needed. It is not possible to foresee if things are going to work at a personal level, therefore it is important to have these tricks ready and be flexible breaking the agenda for letting people talk, and interact with each other
    • the age groups matter, ours was too broad, in the future I should cut the groups in two. No matter if the activities are the same, the kind of discourse needed to talk to the kids is completely different and it is important to keep the kids interested by talking to them with the right level of discourse
    • you have to be ready to implement changes on the fly. If the design decision you made was wrong, you have to be ready to iterate it very quick, working overnight. Letting too much time between experiments is -in my case impossible- but in many cases will bring the participants to get bored and uninterested. In this experiment, when something failed, I made it work for the day after. In that way the participants felt I had made something special for them, but also had improved their experience in programming the robots

    Personally I consider this experiment a success. Oh_Oh v0002 can be used for education, it is open source, it is cheap, and it can be made on-site. However, as you will read in the discussion about future designs, I am not 100% satisfied with the hardware, and I will keep on working in improving it.

    Future Designs and Testing

    From a technical point of view, the robots are not done. I learned that the motors were better in pushing the robot than in pulling it. This means it seems to be better to have the traction from the back than from the front. I made it the other way around based on a design we looked into from Imori Kits, a Mexican company whose design inspired ours. This made that out sensor nose was located at the totally wrong side of the robot. There are other aspects I need to consider for the robot’s next iteration:

    • as mentioned, the sensors have to be placed at the other side of the robot
    • no matter how simple it is to mount the Oh_Oh, we shouldn’t expect any one to mount it, we should design it to be surface mounted, this will also make the price decrease. It will also make the robot shorter in size, making it lighter
    • we should get rid of the external programming cable, it increases the price of the final design by 17Eur, we should be able of using USB-enabled microcontrollers
    • the wheels we used were not so good in providing friction, this made the movement of the robots to be unexpected in many times, what frustrates the kids because the robot will not make the same movement the same way twice in a row
    • the servo motor is on the way to the sensor nose, since we plan to move the sensors from place, this will stop being an issue
    • 9V batteries are not good enough, they run out really quick and the 9V batteries are really expensive in general, we should move to a different format, rechargeable and add a recharging circuit to the board so that the robots will recharge while being programmed
    • if possible we should consider some sort of optical encoder to be used with the wheels and assure both wheels are moving at the same speed – if this is too much work, or gets too expensive, we should move away from DC motors and use servos instead
    • adding an IR LED to the current nose v0001 could help making an inexpensive IR distance detector

    When it comes to the software, we need to keep on working in two lines: the IDE towards VP and the library that commands the robot. There are some things regarding the way it works internally that can be improved. Actually, it should be possible to make the robot work by means of just some sort of operating system and the only reprogramming the kids would do to it would be some kind of commands that could be stored in the robot’s EEPROM. In this way we would skip using Arduino’s IDE to use only some kind of Serial enabled program. This needs further discussion, since as much as I would love to see an open source robot doing things as smoothly as a closed source commercial equivalent, we need to think about how much time more we want to spend working with this.

    As for today we haven’t scheduled any further testing of the robots at a class room, we have learned a lot; it is time to go back to the drawing board and apply everything we learned. As a way to improve our process, I am working on inviting others doing similar projects to work together with us. There are at least two other projects -coming from Spanish speaking developers- that are going in the same direction as ours. Also after showing the Oh_Oh robot at the 2010 Computer Clubhouse summit in Boston last week, the CC manager at FARO told us there is an interest in getting robots by some of the other CCs in Latinamerica … maybe it is time to look for some funding before moving any further.

    Appendix A: Design Files

    The design files of the Oh_Oh robot are available at this software repository, the nose v0001 is also available there.

    Oh_Oh schematic file
    (cc) 2010, Yang-Cuartielles, Oh_Oh schematic file

    All the files are licensed as CC-SA: feel free to manufacture your own robots based on this, feel free to copy the design, feel free to name it the same way, feel free to make you own variations. No matter what you do, remember we helped you, but that we are not liable for any accidents that misusing our code or hardware may provoke. Of course, we want to be mentioned if you make nice things and we want to be credited for being the ones publishing these files in the first place. Ah … if you want to be a developer in this project working together with us, the only thing you need to do is joining us in the Google Code project and bring in your own expertise to the project.

    Oh_Oh board view
    (cc) 2010, Yang-Cuartielles, Oh_Oh board view

    Appendix B: Part List and Cost

    The following table describes the parts in the robot and the price if aim building just one robot purchasing parts at an average distributor in the EU:

    Part Value Device Cost SEK
    PCB Circuit board
    BOTON 10-XX B3F-10XX 7
    C1 100u C-POLE3,5-8 1
    C1A 100n CC050X075_ARTY 1.5
    C1B 100u C-POLE3,5-8 1
    C2 100u C-POLE3,5-8 1
    C2A 100n CC050X075_ARTY 1.5
    C2B 100u C-POLE3,5-8 1
    C3 100n CC050X075_ARTY 1.5
    C6 100n CC050X075_ARTY 1.5
    C9 100n CC050X075_ARTY 1.5
    D1 1N4004 1N4004 1
    H-BRIDGE L293NEE4 DIL16 30
    J1 D(D0-D7) PINHD-1X8
    J2 C(A0-A5) PINHD-1X6
    J3 B(D8-D13) PINHD-1X8 9
    LED12 L LED3MM 2
    LED13 L LED3MM 2
    M1 PINHD-1X2 1
    M2 PINHD-1X2 1
    ON SW_DIP-1 EDG-01 2
    PWR PINHD-1X2 4
    PWR_M MA03-1_BB MA03-1_BB 5
    R1A 100K RR0207/10 0.2
    R1B 100K RR0207/10 0.2
    R2A 100K RR0207/10 0.2
    R2B 100K RR0207/10 0.2
    RESET 10K RR0207/10 0.2
    R_PWR 220 RR0207/10 0.2
    SERVO MA03-1_BB MA03-1_BB 99
    VREG 7805
    DC motors Imori kits
    Wheels Imori kits
    JVC remote
    TOTAL 598.2

    Essentially, what we see is that, making one robot including the programming cable, a remote control, and everything needed to run the same experiments we did, is not expensive. If this was about to be manufactured in certain amounts, and we got rid of the programming cable, the robot should not cost any more than the state-of-the-art of an Arduino board. The difference is that the Arduino board needs other parts to get going making experiments, while this robot allows getting started with the experiments directly. Therefore, if I was about to make a product that would allow students learn about robotics and I would include everything needed, the 50Eur price tag wouldn’t be that far from reality and would allow manufacturers to have a (tight) margin to profit from.

    I haven’t made here a cost analysis in comparison to other products existing in the market. That is subject of a completely different kind of article where I should go into analyzing the products from different manufacturers and how they integrate sensors, exercises, and in which way they support their users. This is just an analysis on how much things cost. I guess Xun and I will have to buy some toys and go deeper in what is possible pretty soon.

    Credits & Acknowledgements

    Contributors and how they were involved:

    • Xun Yang, Malmö University, Sweden: Master Student in Interaction Design, responsible for software and behavior creation for Oh_Oh
    • Gianluca Martino, Arduino, Italy: Hardware responsible for Arduino, made the original hardware designs easy to manufacture
    • Tlacotalpan, México: inspired us with her infinite knowledge about how to name our robot
    • Alejandro Jimenez, México: runs the Computer Clubhouse at FARO and hosts the workshops with kids
    • Hugo, México: runs the paper sculpture workshops at FARO and designed the skull-covers for our robots
    • David Cuartielles, Arduino, Malmö University, Sweden: PhD. Candidate in Interaction Design, Oh_Oh’s project initiator, hardware designer and software instigator

    Institutions and companies contributing to the project:

    • Centro Cultural de España en México: commissioned the project, special thanks to Eva Gómez for her endless support during the two years it took us to gather the funding
    • FARO de Oriente, México: hosts the Computer Clubhouse
    • Malmö University, Sweden: gave D. Cuartielles and X. Yang a workspace where to prototype the robot
    • Arduino LLC, USA: donated 15 Arduino Duemilanove boards to FARO in order to start the workshops with kids

    Read More, Watch More

    You can find more data and documentation having to do with this project at the following sites: