Laurel and Holly holding their first-place trophies for the robot competition.

After two months of work, the big day was finally here. Friday night we drove up to Philadelphia with lots of tools and the robot nestled in a box at my feet. The kids were very excited and we all brought matching robot t-shirts to wear. Saturday morning we showed up bright and early for the Abington firefighting robot competition. I was not sure what to expect and wanting to be absolutely certain of getting a spot with power and a place to test the robot. As it turned out, the organizers had some very nice lab classrooms for us and I didn’t need my power strip and long extension cord. I tested all the sensors on the robot and everything seemed in order.

According to the website there were 54 robots registered for the competition. There were a large number of Vex robots and even more Lego NXT robots. Only a handful of robots were non-kit ones like mine. Most of the Vex robots were part of a local club. I had some very good conversations with the guys who run the club. They were very interested in my bot because of its use of expanded rigid PVC and the Arduino platform, a switch that they are considering. It turns out that Vex robots are extremely expensive. They showed me one of their entries, which had a fairly large metal frame and large wheels, along with a number of plug in sensors, I am guessing about 5 in total. They told me the cost of the bot was $850! In contrast I had encoders, far more sensors, and wireless communication, at a parts cost under $150, and — had I had the time — the ability to add more things like line sensors for less than a dollar. Now it is certainly true that I spent more than $850 on this project as part of equipping my workshop with loads of parts “for the next project”, the power saw, and replacing Parts That Burned Out as I learned how to use my power supply correctly. (The list of fallen includes a motor, two encoders, a switching voltage regulator, and an XBee with breakout board.) Still, that is quite a price difference.

When I made it over to the practice arena, there were some bad surprises in store. Most of the maze floor was hardwood; well and good, as that is what I had at home. They also had carpet. I knew this was coming, but had expected relatively thin carpet. Not true. This was thick, and worse, it was uneven in height with patterns. On my first practice run, the robot stopped dead. Since I was not running at top speed, I changed the code to boost the speed greatly (knowing that I might pay a price in accuracy in the hardwood portion of the maze).

I knew that narrow wheels on that carpet was not going to work well. They would get stuck in the grooves. As luck would have it, that rug was on the path to the single room I had chosen. And so, while I had wanted to avoid any last-minute code changes, I decided to go for another room instead, where there was no carpet. The first thing that happened after that was the robot started running backwards continuously, saying that it was stalled. Turns out I had overwritten an array, which had nothing to do with the stall code, but this was another example of the sensitivity of the system to any coding error. Fixed that, but lost more time.

Another weird thing, when I would start my practice runs, the robot would instantly swerve left into the wall. Since this was practice, I could simply hit the reset button and then it ran fine. This happened on both practice runs. Not a good feeling.

The competition started with the high school students. Another surprise, as I saw with a sinking heart that there were now two carpets, and no way to avoid them. We watched as 11 robots in a row failed to put out the candle. Robot 12 succeeded…then there was another string of failures. That robot was the only one in the division to make it, and later in the day it was not able to do it again in the second round.

It was surprising how many robots made it into the room but were unable to put out the candle. Some of them were thrown off by candle reflections on the white walls — I had uncovered this potential problem in testing at home. The biggest problem, though, is that so many of them avoided using a powerful fan. You get a 25% time reduction factor for using non-air methods. So there were lots of balloons and a few sponges. Only problem is, if you aren’t exactly in the right position, those methods don’t work well. Some folks used fans, but wimpy ones; I am guessing those are the ones that worked most easily with the kits. By contrast, I had a fan designed for providing thrust on airplanes and a dedicated servo to sweep it rapidly back and forth. It was loud as hell but if I got anywhere near the candle, it was going out.

The interesting thing is that there was a much easier way to get a time reduction — 20% — by having your robot start with tone activation instead of a button press. This was a no-brainer for score improvement, and I had bought all the parts (a few dollars) but didn’t have time to build it. Yet almost none of the contestants used it. I realized that this is probably because the kits don’t offer a plug-in version of a tone detector.

Next was the junior division. They did not have the carpets to deal with, and so, there were a decent number of successes. About halfway through this, I found out that Laurel and Holly’s division had been moved up so that they were now going to be next, not the original schedule. I ran back to reprogram the robot for remote control, plug in the laptop XBee and haul everything back. All in all, quite a bit of running around.

It was worth it though, because the kids did a great job of driving the robot and putting out the candle, even though we’d had zero time to practice. Here is the video:

Then first run for the senior division. Once again, I put my robot in and wham — straight into the left wall. I later figured out that this was a software bug introduced the morning before, when I hastily added the required button switch. That put a delay in the code, and I put it in the wrong place, so the sensors were calibrating while outside the maze.

At the time, though, I had no idea of what was going on. So with dark thoughts about my motors I quickly put in a edit that if the robot hit a wall, it would back up and then turn right.

Surprisingly enough, this worked decently for the second run and the robot at least made it down the hallway heading straight. But, then it hit the dreaded carpet, and a wheel got stuck in the grooves. And that was that!

Only one robot in the senior division successfully completed two runs (I think). A man named Paul B. had brought a beautiful pair of robots in for a swarm demonstration. Two robots working in coordination searched each room for the candle and put it out, choreographing their moves, and returning home to nestle back together at the start. Needless to say they were also well capable of putting out the candle acting alone. They moved wonderfully smoothly, with no carpet issues.

After the show I talked with Paul a bit. The first thing I asked about were the motors, and these were indeed high-grade medical motors that cost over $100 each new. (Mine were $8!) Like me he had encoders, and interestingly enough they were about the same counts per revolution. Since his were integrated into the motors, it was much cleaner. I had 10 wires going into my breadboard from my encoders, and while they never got loose, it was ugly. His robots didn’t seem to have any wires anywhere, though there must have been some. Lovely PCB boards with surface mount components made for a spare, elegant design.

Although I would have liked to do better, we had a great time at the event. The kids got two very nice trophies, and I met a lot of cool people, too many to mention here. The organizers were friendly, not to mention that we got free food, and the entire event was free! I’m very glad I came here instead of Trinity.

Goals for next year:

• Have more time to get everything done and tested!
• Use different wheels. Those were my biggest limitation. Small, wider, and better traction.
• The wheels were part of the motor/encoder package. Since I was not at all thrilled with the motors, I will upgrade to a higher-quality pair with integrated encoders.
• Even with good motors, relying on a robot to go straight is never robust design. I will spend much more time building in recovery behavior. With all the sensors I have it is possible to choose a reasonable course of action. Most robots in the show hit a wall at some point and then they were doomed.
• My battery was a little big and heavy. Might change it. On the other hand I have to say it performed well.
• Designing PCB boards would be fun, though of course this assumes you have a fixed plan for that component!

I’m happy to say I’ve crossed off a big item on the list already, namely moving to a real development environment for the Arduino instead of the toy one that comes with it. Turns out Visual Studio has an Arduino plug-in that works great and is effortless to install.

And now, time to catch up on real life.

I am very proud of my fire sensor. It is based on the Rockhopper design, but since there were no schematics I had to figure a few things out. I found that using four photodiodes instead of one did increase sensitivity, and gave a sharper angular peak — very desirable if oriented properly. As usual, there was some trial and error. I discovered that the photodiode responds to the frequencies emitted at the base of the candle flame. Thus the tea candles that I originally tested with were a disaster, because when they burned for a little while the interior hollowed out and covered that part of the flame. The diodes are also sensitive to candle height, so I spread them out to cover the maximum allowable range in the competition, 2 inches.

Robotic fire sensor

Figuring out how to mount everything on increasingly limited space was a challenge as well. Ultimately the flame sensor went on a butter container, with the fan mounted on the side. All of these were then attached to a servo, which sits in a rectangular opening cut nicely by my new power saw. Again, all very time consuming.

So by yesterday I realized that I would not have time to get the navigation reliable for the entire maze. And therefore, I have lowered my sights a bit. Abington offers a “single room mode”, where you can pick ahead of time the place you would like the candle to be. As long as your robot can make it to that one room, then, you are in good shape. There is a 3-minute penalty added to your time, which means that you are not going to win unless everyone else crashes (or chooses the same option). I was disappointed to have to do this, but I suspect I’m not the only one. Looking on YouTube, there are a suspiciously high number of videos with robots finding the candle in the first room they look at, and it’s the easiest room to get to.

I have had a number of surprises working on this project. Everything felt very rushed, as I had only two months to work and no experience. I had to make design compromises. These included using an Arduino Mega, motor shield, and breadboards, as opposed to wiring everything individually. One surprise was how well this worked. I thought there would be issues with wires popping out of the breadboard or falling out of the Arduino headers. As it turned out, they worked extremely well. I cut the wires precisely and used the proper housings and…it just worked. What did not work well were the screw terminals. I had many problems with the battery leads coming out and the same with the motor leads. Since screw terminals are supposed to be more reliable, this was an unpleasant discovery.

The Arduino works with C or C++. After years of working with Java and its automatic memory management, I knew going back to C++ would be painful. It was worse than expected. If you write a buggy program on a computer, you usually get a nice error message. On a microcontroller, your only clue may be when things suddenly to act weird. And in the worst case, you can completely lose the ability to communicate with the board and get rid of the faulty code. At one point I thought a coding error had bricked an expensive board. Finally I found a suggestion of sticking a large capacitor between the ground and reset pins to prevent automatic resets, and that eventually worked. Quite a scare though. Flawed code is quite easy to write, with no warnings about dereferenced pointers or default values. I learned to put in a few seconds delay at the beginning of the program to allow some time for communication before any errors surfaced. That was not 100% foolproof, though, as some global objects get constructed first. So I had to make the constructors dead simple and call separate setup functions on the objects later. Even then, sometimes, problems.

I did get to appreciate how much work the Arduino folks did to make a microcontroller usable by “normal” people. They are hard to work with. The trade-off is that you lose power; for example, the board runs at a much slower clock speed than needed, because to change that would mean rewriting older code. And the Arduino IDE is hardly suitable for a large code base (which I eventually had), with no line numbers and certainly no way to find function usages, etc. There was no time to configure another IDE this round, but next time, that will happen.

This was one of the hardest things I have ever done. The intellectual challenges were constant, with no time to delay or rest. It was harder than my big challenge last year, Mountains of Misery; as hard as it was, that was only ten hours with the last one being truly hard. This required intense drive for weeks, and there were many times I was tempted to throw in the towel.

This morning I tuned the candle-finding algorithm, put in the required red button start switch, and added two joystick functions the kids will need for their remote control portion: turning the fan on/off and swiveling the servo. The Robot Operating System has done very well for the remote control part, it was fun to work with.

Here is a video of FireCheetah navigating the maze and putting out a candle. I got it working even better by the afternoon, but this should give a good idea. Let’s hope he does as well tomorrow!

Along the way, I ran into two problems that nearly drove me crazy and cost a week of time:

1. The robot would drive straight at times, but other times not. And when it wasn’t going mostly straight, navigation failed.
2. Even when the robot went straight, it overshot the target distance. Now after some experimentation, I was able to compensate for this with various fudge factors in the software. However, these factors change on different surfaces and the Abington maze has a variety of them.

The first problem was by far the worst, as it was very frustrating to see a well-behaved machine suddenly turn into something that could not move an inch without listing severely to one side. Not always the same side! One step I took to help was to add more sensors, the two side sonar on the left. These helped with initial wall alignment and reduced the element of chance. Still, when the robot was in bad shape, nothing could help.

Eventually I figured out that the robot generally started its day working well, then degraded at a certain point. The first thing I looked at was the battery. But that wasn’t it. I found that leaving the robot alone for a few hours would allow it to recover, even without charging the battery. (The LiPo battery I’m using is a champion, and well worth the money. It never seems to hiccup or run out of juice. A world of difference from standard alkaline.)

Then I thought about what could be stressing the robot. It is well known that when the motors stall — under power but unable to move, probably because your robot hit a wall — the current surges. In theory, my motor controller was rated for a much higher current than the stall current for my motors. But these events can generate a lot of power = a lot of heat = potential thermal shutdown by the L298 chip on the motor controller board. So I took the robot when it was fresh and running straight, then deliberately stalled the motors. Sure enough, that killed any straight motion for several hours.

I added checks in the software to detect a stall and to cut power to the motors if one is detected. It’s probably a good idea to have the robot back off and/or reposition itself too. Simply protecting the motors gave a big improvement. I’ve also concluded that there is no need for me to run the bot at 12V. I have far more torque than I need and have only been doing 70% of top speed. If I lower the voltage to 9V, the power drain caused by a stall is only 60% of what it is at 12V. I will have to experiment and see if lowering the voltage causes any problems. Finally, I’ve ordered a heatsink to prevent the chip from overheating. Many experienced roboticists recommend using one, if nothing else it extends the life of your chip. It was a bit of a challenge to find a heat sink for a surface mount component.

Next, the travel overshoot. On my hardwood floor I could predict it fairly well, but that wasn’t good enough for general use. It finally occurred to me, there should be a way to actively brake the motors. Up to this point I was simply applying voltage to the motors, and at a higher duty cycle they moved faster. To stop, I sent no voltage. But the shaft could continue to spin for a while. After doing some research, I discovered that the L298 has a built-in brake that activates by setting both direction pins HIGH.

Wonderful news, but my lousy motor controller did not allow direct access to those pins. I had already noted that it also grounded the current sense pins which are an easy way to detect a stall. I had purchased it for its economical use of Arduino pins…bad idea. Time to replace it with the Arduino Motor Shield, conveniently available at local Radio Shacks (for once I did not have to pay exorbitant shipping to get a needed part quickly). The Arduino Motor Shields gives both current sensing and dynamic braking! And if you don’t need them, you can easily cut the jumpers and free up the pins. $10 more than the SparkFun product but a better design. It also uses the L298P, a more advanced version of the L298 chip that has better thermal resistance.

Navigation has consumed more time than I would have liked, but I have done some work on the fire detection as well. Most of that will be covered in another post. I did want to show off the new toy I bought to cut a hole for the detection servo:

Rockwell Table Saw

This saw can be used for straight and mitre cuts, and as a scroll saw. I purchased the attachment to cut circles as well. I’ve been wanting a saw for a very long time, but was intimidated at the thought of buying one. The ones I used in the woodworking club seemed far too big for a home. The Amazon reviews were very helpful; and sure enough, this one proved to be extremely easy to use. It opens up many possibilities for new projects.

The robot is actually quite fast. I had to slow it down to 30% of full speed to control it reliably by hand. The weight is unevenly distributed right now as well, which adds to the challenge. I have heard that victory in robot combat is often determined by the skill of the driver, and I believe it. Driving well takes practice. Fortunately, this part of the event is not timed; the kids can take their time getting the robot to where it needs to be.

As planned, for remote control I am using ROS on a PC talking to the Arduino on the robot. The ROS portion was surprisingly easy. Where I did have difficulty were the limits of the microcontroller. One painful discovery is that should your program crash, you won’t know it has happened, and very weird things can happen. (However, you may see the reset button flash on the micro as it reboots.) A keep-alive signal of some kind is a good idea. I chased some long rabbit holes before realizing that a program crash was the issue. The crashing, in turn, was through attempting to do some pin manipulation in class constructors, before the microcontroller was ready. This cost me a few days, very expensive at this point.

I am changing the architecture for the autonomous mode. I won’t be using ROS. The bandwidth limitations became obvious even in remote-control mode, my sensor suite is limited, and the robot needs to move fast. More significantly, I did some research on previous winners of the Trinity firefighting competition. Wall following is a proven technique, and can be done in an elegant way.

There is a lot of work to be done in the next few weeks. I need to mount the sensors, and build the circuits for the fan and candle detection.

• Set up wireless communication between the Arduino-controlled robot and a PC running the Robot Operating System (ROS), using XBees and the rosserial library.
• Made a robot descriptor file, and learned how to publish the basic frame and joint transforms to visualize the robot in ROS’s rviz.
• Created a foamboard maze for testing. I didn’t want a huge maze taking up floor space in my house, and the contest arena is 8′ by 8′. To my surprise the web was useless on this, so I had to design it from scratch. My maze is light, portable, and easily taken apart or reconfigured.  These foam connectors are the key; it took time to track them down.
• Learned how to use wheel encoders, and debug them properly. Getting it right required using my cool palm-sized oscilloscope. Added debouncing code to improve accuracy.
• Learned enough about the ROS navigation stack to send fake odometry messages and see the robot move in rviz.
• Converted the contest arena schematic into an 3D obstacle map for ROS.
• Wrote the basic differential motor controller for the Arduino to move the wheels, collect odometry information, and correct the velocity based on a PID system. Much of this was built from scraps of code acquired various places online. It is not tested yet.
• Got a Logitech F310 game controller, installed the ROS joystick driver stack, and  “drove” a simulated robot. This works via ROS velocity commands, identical to what the real robot will need. The joystick stack was not compatible with my version of ROS and it took some hair-pulling to fix. After managing it, I went in and added the details to the official ROS documentation so that others won’t suffer. The kids have enjoyed driving the fake robot around.
• Figured out a nice system of crimp connectors and matching housing to wire the robot up.
• Purchased and received the necessary parts for the robot construction, including chassis, wheels, motors, motor brackets, encoders, standoffs, and ultrasonic sensors.

Upcoming tasks include figuring out the full navigation and localization stacks for ROS, which seems rather daunting at the moment. I also need to convert the ultrasonic sonar data into something that ROS can use, it is designed for laser scans or Kinects. With that, I will have a full framework for a robot capable of autonomous navigation.

The only major area not looked at yet in depth is the candle itself. Once in the proper room, we need to detect the candle and put it out. It seems that this will not be too hard, so I am leaving it for the end.

Looking at all this, I can see I will never write about all of it. But for those topics that are not well covered elsewhere online, I will give it a shot.

If you own an XBee, you likely already know that the official configuration tool, X-CTU, only runs on Windows. As result, if you need to configure an XBee on a different operating system, a Google search brings up repeated suggestions to install a Windows emulator, install X-CTU, then manually update some drivers.

Now this is fine if you already have or want an emulator but really…there is no need for such a heavy-weight solution. You can fully configure your XBee via the serial port and a terminal program.

Windows comes with Hyperterminal pre-installed, but for Linux I downloaded the free minicom program. (Mac…you are on your own.) Before starting, you need to know the port the XBee is attached to and the communication settings, just as you would with X-CTU. For a factory-fresh XBee, the communication settings will be:

• baud rate: 960
• data bits: 8
• parity: None
• stop bits: 1
• hardware flow control: None

To find the port the XBee is using, follow the directions for your operating system: for Linux udevadm, or on Windows it is Device Manager.

For Linux minicom, I recommend the terminal options of turning on local echo and adding linefeeds.

Once your terminal program is up and running, open the connection to your XBee port. Type the string +++ quickly without pressing the Enter key. You should get back a reply of “OK” from the XBee. If it doesn’t work, wait 10 seconds and try again. If it fails repeatedly, you may be at the wrong communication settings. Usually it is a matter of mismatched baud rate. But if you’ve totally forgotten the XBee settings, you can use this simple method to do a hardware XBee factory reset.

After you’ve gotten the OK, type

AT

You should get another OK back. +++ and AT put the XBee into command mode. This is a temporary state! For the next few seconds any information sent to the serial port will be used to command the XBee, and the XBee will not forward it on to any listeners.

The most common change is that of baud rate. Type

ATBD

The XBee will reply back with 3, which equates to a baud rate of 9600. Let’s say that we want to increase this to 57600. We type in

ATBD 6

and get back OK. To write the change to the XBee’s memory, type

ATWR

At this point, the XBee will be communicating at 57600 baud, so you must change the communication settings in your terminal program in order to continue.

If you ever have to pause and figure out what you are doing, just type +++ again to put the XBee back into command mode.

Another common change is PAN ID. XBees ship with a default PAN ID and you will want to avoid crosstalk with other people’s networks. The command for this is ATID. As before, issuing a plain ATID tells you the current value (probably 1332) and sending a command like ATID 1414 will change the PAN ID to 1414.

There is a full list of XBee configuration commands in the XBee User’s Guide, Chapter 10.

In writing this post I learned about the moltosenso IRON, a free cross-platform alternative to X-CTU. I have not tried it, but it might be useful for those who need to do more complicated configurations.

The objective of the fire-fighting robot contest is to design a computer-controlled robot to navigate a maze (8 ft. by 8 ft.) that consists of 4 rooms. Rooms are surrounded by walls except for a 18″ entrance. A single candle is randomly placed in one of the 4 rooms. The goal is for the mobile robot to explore the maze, locate the candle, and extinguish the candle in the minimum time. Robots must be within 12″ of candle before extinguishing candle. The layout and dimensions of the maze and rooms are fully known to all contestants prior to the contest. For the advanced divisions, the hallways and room may be covered with carpeting, and there is a small staircase located within the maze. Bonuses are earned for returning to the start position after extinguishing the candle, and allowing obstacles to be placed in the rooms. Participants are permitted to use any combination of building materials and computer technology. All robots must operate autonomously except for the K-5th grade remote control division.

This is not a simple task, but I was particularly excited to see the K-5th grade remote control division. This allows us to participate as a family; my kids can drive the robot to the candle and extinguish it, while my entry must be autonomous. Robots cannot be larger than 12.25″ in any dimension.

At this point, I’ve figured out the basic design. I believe the most difficult task will be navigation, especially as the robot will have limited sensor capability. The robot may start from a known position in the maze, and I will take this option. I would like to use existing software; many brilliant people have worked on this problem. A few months ago I took a great course on the Robot Operating System (ROS), taught at HacDC by Andrew Harris.* ROS has the firepower to do the job, but there is a steep learning curve, it must run on a full PC, and I will have to use Ubuntu and Python, two environments I’m not familiar with. In doing the course assignments, figuring out Ubuntu and Python slowed me up more than anything else. However, I already have a working setup from the class, and with Google all things are possible. So my plan is as follows:

I will run ROS on my laptop. The robot will have an Arduino microcontroller as its brain. The laptop and the robot will communicate wirelessly using a pair of XBees. ROS has a package, rosserial_arduino, which allows the Arduino to run little ROS nodes that can send sensor and odometry data over the serial port to the ROS nodes on the laptop. The laptop nodes will do the heavy computation and reply back with navigation directives. The XBees make the serial port communication wireless.

Although the ROS site has some good tutorials, setting up the XBees on Ubuntu to run the demo Arduino programs was not obvious. Their rosserial_xbee package is designed for a mesh rather than point to point, and the two modes are not compatible. And the XBee configuration tool is Windows only. I got it working — if I have time, I will write up a post on how to do all of this — and was quite impressed with the performance of the XBees. I walked outside my house for a few hundred feet and was still able to communicate with the XBee in the upstairs office. The big risk with this design is that if the wireless communication fails, the robot is dead in the water. My XBee series 1 802.15.4s have a range of 90m and operate at 2.4 GHz, so they should work well. I did of course change the default PAN ID to avoid interference from any other competitors with the same device.

One nice thing about the wireless design, the kids can use the same robot for their entry. I will just hook up a joystick to the PC and it will send commands via ROS. Even if my autonomous design fails, and I give it a 50% chance given the total novelty of all this, theirs should have a better chance.

I purchased 10 ultrasonic sensors (HRC SR04) from China for the price of 1 PING))) — $3 each on eBay, free shipping, and they arrived quickly. Currently waiting for the chassis, gearmotors, wheels, and encoders to arrive. I opted for a mostly circular ABS chassis that is 7″ in diameter. The wheel encoders were more expensive than anything else, so it will be interesting to see how well they work. I already have Arduinos and servo motors from other projects.

In the meantime, there is a lot of software work to be done. The ROS navigation stack is not at all simple to understand, nor are the simulation tools. But I am making progress. I already have a simple robot model URDF file, and understand how to translate frames of reference using tf. I should be able load a 2D map of the maze using a properly dimensioned image, so the next step is to generate that.

The contest is April 21st — not far away!

*The HacDC ROS class wiki is publicly available and is complete enough to learn from on your own.

So I was delighted to see that new courses are being offered for the spring semester. An excellent summary of them can be found here. (Be sure to scroll all the way down, as there are some important updates at the bottom.) The list includes computer science, entrepreneurship, robotics, and many other topics that all look incredibly interesting. As mentioned in my previous post there are also archived courses available through Stanford Engineering Everywhere, though there would not be any grading for those.

An interesting note here is that Sebastian Thrun is offering his courses through his new online education venture, Udacity, rather than Stanford. Apparently he has chosen his Google position over his professorship at Stanford, and given up his tenure. It appears to have been an amicable split. The AI class attracted over 100,000 students. Thrun discovered that even the Stanford attendees preferred to watch online, rather than live; his lectures dwindled from 200 to 50 over the course of the semester. I don’t blame them. As with the Stanford classes, Udacity’s courses are free, but without any sort of accreditation. Starting February 20 they will begin “Building a Search Engine” (for programming novices) and “Programming a Robotic Car” (programming experience required).

I would very much like to take the robotic car course, and Stanford’s Machine Learning. However, I recently committed to a robotics competition in April, developments are happening at work, and in short this is not the perfect time. But good news: the Udacity courses will be offered again, starting April 16. Now that is flexibility! Thrilling. Udacity has 8 more courses listed as “coming soon” and I fervently hope they do. Democratization of scientific education is something I feel passionate about.

The Stanford courses are tied to their academic schedule and only offered “live” once or twice a year, so if you are interested in those I recommend checking them out now — they start soon.

However, the gift item my husband chose was the Sous Vide Supreme. And sous vide cooking is both new enough and geeky enough that I thought it might be of interest. I first learned of it in “Cooking for Geeks” by Jeff Potter. Basically, it is a precision temperature-controlled fluid bath. Foods are (generally) placed in a plastic bag, then the air is removed and the bag vacuum-sealed. The food bag is placed in the bath, and sits at the desired internal temperature for a long time. This is different than oven roasting where the cooking temperature is often hundreds of degrees higher than the desired final internal temperature. Thus roasting can often result in an overdone exterior and underdone interior. The high heat is required due to the inefficient heat transfer of air. But with the sous vide fluid the heat transfer is much faster. It is possible to get your fish or meat to the right temperature in a reasonable amount of time, depending on the thickness of the meat. The entire piece will be cooked evenly, and exact timing is usually not required; you can leave the food item in there quite a bit longer and it will not overcook.

The classic item to start with is an egg, because being in a shell it doesn’t need the vacuum-sealed bag. As suggested in Jeff’s book, I put the egg in at 146F for 1 hour. Near the end of the hour, I sauteed some asparagus. After that, I took the egg out and did the optional step of cracking the egg into a cup of very hot water (to set the whites more) then took it out immediately with a slotted spoon and put it over the asparagus. The egg was amazing. The yolk was like a custard, ever so slightly runny, and the whites were soft. The look of it was very unique too. It’s easy to play with the temperature to get the egg the way you like, and for slow-cooked eggs the results will be very consistent. Again, exact timing is not required. Here is a picture of the result.

Sous vide egg over asparagus

It is possible to cook eggs quickly as well; I’ve done them at 167F for 15 minutes the last few mornings, and since that is much higher than the desired internal temperature, precise timing becomes important. That said, the eggs are far more consistent this way than using boiling water or the microwave!

Having had success with the egg, my next test was salmon. I had heard this was a classic sous vide dish. I bought 3 8oz filets, and put 3 tablespoons of olive oil in small cups into the freezer briefly to set them into a gel. I then bagged each salmon with the olive oil gel and cooked it for 40 minutes at 122F.

The results were outstanding. I’ve never had such good fish, and the edges were as moist as the interior. Coming out of the bag, it looked raw, which is normal for sous vide. I used a pan to sear each side for 30 seconds, then we all ate. Everyone loved it, especially the kids, who have begged me to make it again.

Sous vide salmon, finished with a pan sear

Next up, chicken breasts. These are healthy and very filling, but let’s face it, they can be dry and boring as well. I’ve figured out some good recipes by now, but I always prefer the fattier dark meat. I tried out a butter poached chicken breast with fennel recipe. Once again, the meat was extremely moist. But the sauce was not interesting enough. Chicken breasts as an entrée still require a strong flavor, whether a sauce, marinade, or dry rub.

Butter poached chicken with fennel and onion

I had better success with cooking a large batch of chicken breasts for my lunch salads. I’ve avoided making these in bulk in the oven because it is too hard to guarantee uniformity, and the last thing I wanted was a large amount of dry or underdone chicken on hand. I rely on leftovers from dinner instead which is a bit hit or miss. In the sous vide making the breasts was very easy, throw the bag in for a few hours and that was it — and the results were excellent.

The concept of cooking decoupled from time (mostly) is a fascinating one. I usually focus on cooking the protein perfectly and keep the side as simple as possible because the timing issues are such a pain. But the sous vide frees me up to make a more interesting side dish. The butter poached chicken may have been a bit bland, but the roasted fennel, carrot, and onion side I served with it was a hit. And I would never had made that under normal circumstances. One can go a lot further than this. Make your dish ahead of time, keep it in the vacuum sealed bag, then chill or freeze it. Just warm it up again when you are ready to eat. Or, cook multiple items at the same time. If the higher temperature ones go in first, they can stay in while the lower temperature ones are there too — they won’t overcook. And everything is all warm and ready to go when you want to eat. No doubt this utility is why the sous vide became popular in the restaurant world.

This situation has some similarities to a slow cooker, where you also have the luxury of putting something together and letting it sit for hours. In the slow cooker you must use a sauce, the meat will shrink, there are some practical limitations in terms of how long it can stay in, and the cook/chill option is not generally available. Nevertheless the slow cooker is a wonderful tool.

Because sous vide is fairly new to home chefs, creativity is required in figuring out how to apply recipes to it. One idea that occurred to me for tonight was mashed potatoes. To get the richest flavor from the potatoes, it’s best to boil them with the skins on. But you then have the problem of getting the skins off afterwards without letting the potatoes cool down too much. And generally, it all must be precisely timed: if your guests aren’t there on time, you will be stuck with cold potatoes. For Thanksgiving, I found a make ahead recipe which got around the timing problem. The sous vide seemed to have the potential to solve both skin and timing. I peeled the potatoes, sealed them up, and put them in at 184F. When the rest of the meal — stout-braised beef short ribs — was ready, I mashed the potatoes with butter, milk, and sour cream. They were exactly the right consistency and, again, delicious. Bonus: I bagged some peeled, halved pears and cooked them along with the potatoes. When dinner was over I unsealed the poached pears and drizzled on some honey and blue cheese crumbles. A nice hot dessert, yum.

Similar to a slow cooker, the sous vide will not brown the outside of the meat. Browning is desirable from an aesthetic and taste point of view, even if it is not the healthiest option. The easiest way to brown meat is to quickly pan sear the meat before or after cooking. The fun way, is to use a blow torch when the dish is completed! I’ve ordered a culinary blow torch, and am looking forward to trying it out.

Finally, there are some neat things that can be done with a hot water bath. I suspect I could use this to make yogurt, or culture biological samples. I have some herbal tea which needs to steep for 10 minutes, but can’t be brought to a boil again after steeping. To keep the tea warm, just sit the mug in the sous vide. Etc. There are many more uses I’m sure, and I’m looking forward to exploring them.

I just watched the first unit. I was afraid the videos would be dry, but they were fairly pleasant to watch. It is not quite the same as having a live person there; but there are the advantages of attending on your own schedule, and being able to rewind. Breaking the lecture up into chunks is nice as well. The quizzes in the middle of various sections keep things lively, they don’t contribute to your “grade” but are a nice way to keep you on your toes. I am looking forward to the next unit. There will be a new one each week, for a total of 10 weeks.

There is also a weekly study group meeting at HacDC. That will be an opportunity to meet with fellow humans in person.

Although the AI course has received unprecedented publicity, I’ve discovered that Stanford offers many other courses for free. They have the Stanford Engineering Everywhere initiative, which in their words includes:

• Anytime and anywhere access to complete lecture videos via streaming or downloaded media.
• Full course materials including syllabi, handouts, homework, and exams.
• Online social networking with fellow SEE students.
• Support for PCs, Macs and mobile computing devices.

I saw 13 courses on there, which include: “the three-course Introduction to Computer Science taken by the majority of Stanford’s undergraduates and seven more advanced courses in artificial intelligence and electrical engineering.” Many of these look very good.

It is very encouraging to see all of this wonderful information being made freely available. A few years ago I looked for robotics courses and could find nothing. And now, world class material is here for everyone. It makes me very hopeful for the world. Many scientific research papers, too, are being made publicly available now and not being walled off behind private journals — indeed, government grants pay for much of that research, shouldn’t a citizen be able to see it? I have missed my university membership for a long time, but I think it will become somewhat less relevant in the future.

Back to Stanford: the SEE courses are mostly archived, but in addition to the AI class there are a few others that are live this fall. They include Machine Learning and Introduction to Databases.

For more information and to sign up for AI, see http://www.ai-class.org.