Embedded Systems Design Course: Putting the 'Fun' in Functional

Note: In Part One of a two-part series, we feature two projects from CSE 145, which teaches students how to use software and hardware to build an embedded systems. First up: An autonomous flying robot and another that can solve a Rubik’s Cube® in fewer than 30 seconds.

San Diego, Calif., June 24, 2014 – The official directive for students in the University of California, San Diego’s Embedded System Design course is to “learn fundamental knowledge of microcontrollers, sensors, and actuators” and other hardware and software tools to build an embedded system.

The unofficial directive for this past quarter's students? To put the 'fun' in functional.

The resulting projects provide a glimpse into the future of embedded systems, which are essentially computing systems built into larger mechanical or electronic devices and are designed for handling specific tasks. Digital watches, traffic lights, and MP3 players are all examples of embedded systems.

But so are flying robots, robots that can solve Rubik’s Cubes® and aerial balloons that can take time-lapse shots of the Coachella music festival (these are still college students, after all).

Computer Science and Engineering Professor Ryan Kastner, who is an affiliate of the UC San Diego Qualcomm Institute (QI), says “It is important for students to take the knowledge that they learn in their classes and apply it to real-world problems. This not only allows the students to better understand why they need to learn sometimes seemingly obscure topics, but also gives them a view of how computer science and engineering can make a significant impact on the world. The projects this year demonstrated that the students had an inherent desire to combine the knowledge that they learned in their classes and also spend countless hours to learn new skills from a variety of engineering areas, to ultimately create truly outstanding and unique embedded systems.”

Autonomous Flying Robots

Many of the students in the course made use of the tools and resources in the Prototyping Lab at QI, which is the UC San Diego division of the California Institute for Telecommunications and Information Technology. For undergraduates Miles Minton and David Dantas -- as well as their teammate Abraham Hart, who works for the unmanned systems branch of Spawar -- the ability to use the lab’s Makerbot 3D printers to create a tower to house their “Autonomous Flying Robot’s” sensor array was a big step up from what they’d previously used: a modified cardboard toilet paper roll.

The toilet paper roll wasn’t necessarily a poor fit for the team’s autonomous drone, which they designed to navigate rooms and hallways while avoiding obstacles. One of the key considerations for the drone is that it remain lightweight enough to properly fly. With a total of five ultrasonic distance sensors (for avoiding obstacles), an Arduino microcontroller, and the weight of the drone itself (which is equipped with a built-in high-resolution 720 p HD camera and a webcam), the sensor housing had to be as lightweight as possible. 

“That’s why we went with a honeycomb design for the new tower,” says Dantas. “It makes wiring easier and saves weight. With this device adding even 20 grams is a big deal.”

Saving money was also a chief objective for the team, which jokes that their device resembles a ‘flying Roomba’ – and with off-the-shelf parts totaling around $300, costs about the same. Contrast that with more sophisticated flying robots, where just the sensors alone can cost upwards of $8,000. 

The team used the drone’s sensors to collect and analyze data that they then used to program the device.

“Initially, we could tell it what to do, but didn’t know when to tell it what to do,” says Hart. “Now we’re working on refining the code.”

With only about six minutes of battery life, the robot is more of a proof-of-concept than a viable instrument for its intended purpose: Mapping buildings, especially in the aftermath of disasters or crime scenes when first responders need to know if it’s safe to enter a building. 

But building proofs-of-concept is what this course is all about – as is learning how to work on a team, how to create a Gantt chart (a type of project schedule commonly used in information technology), how to present their work to a lay audience and how to avoid Planning Fallacy, or the tendency for people and organizations to underestimate how long they will need to complete a task.

Minton, Hart and Dantas, like most of the students in the course, have some familiarity with Planning Fallacy -- they were six weeks into the academic quarter before they got their drone to fly. The robot also had some difficulty navigating corners and going down hallways (this particular drone flies by shooting air in a downward direction, which can cause interference with nearby walls). 

“There are lots of gouges in the styrofoam bumper,” admits Hart. 

And then there was the time the drone took off by itself, without any foam bumper at all. 

“We were doing an initial test on the control software, so we set it down and it suddenly took off,” recalls Minton. “It was supposed to hover, but instead went out the door. That was frightening.” The blades on some drones are sharp enough to take off a finger, while this one has only “drawn blood,” thanks to what Hart calls Minton’s “quick reflexes.”

A Rubik’s Cube-solving Robot

Trial and tribulation were also the modus operandi of Team Ruku, another trio of students from the course (known in the UC San Diego course catalog as CSE 145). The students -- Daryl Stimm, Jonas Kabigting,  and William Mutterspaugh, -- decided to improve upon a prototype of a wireless robot designed to autonomously solve a Rubik’s Cube puzzle. 

It was supposed to, anyway. The first version, which Stimm helped create for another ECE course a year ago, “failed miserably.”

“It was slow, it jammed, it had lots of problems,” he recalls. “But we knew if we could get it right it would be fun to develop the robot as a kit that educators could use to get students interested in the STEM (science, technology, engineering and mathematics) fields.”

After Stimm presented his idea to the students in the Embedded Systems course, Kabigting and Mutterspaugh signed on to help. The original robot was controlled by a credit-card sized single-board computer known as a Raspberry Pi and had two ‘arms’ and servos to manipulate the cube. The team now outfitted it with an additional pair of arms and replaced the servos with stepper motors and linear rails, which sped up the process of solving the cube and reduced the number of jams. 

Kabigting also created Python-derived color recognition software and a motor design script that, when combined with a smartphone mounted to the top of the robot, allowed the robot to take photos of the mixed-up cube (even in varied lighting situations) and then calculate how to solve it. 

“We made a giant leap in this project with the color capturing,” says Mutterspaugh, who was primarily responsible for designing and wiring the device. “Before, you had to enter each side of the cube manually with Internet-based software to be able to solve it. It required a lot of hand-holding. Now it’s all done locally. You just insert the cube, press start, and the robot does everything.”

The team also designed an app that allows a user to take photos of a cube and then follow step-by-step instructions for how to solve it. 

Some might ask: Isn’t that cheating? But Mutterspaugh points out that Rubik’s Cubes come with a guide to help the user along, and there are lots of online resources to help solve the puzzles. 

“For us, this was more about building a robot than solving a cube,” says Stimm. “No matter who I show this to, people are kind of wowed by it.”

It is a sight to see. After snapping photos of each of the cubes six sides, the robot takes only 25 seconds on average to solve a cube.

Getting to that speed involved a lot of trial and error, says Stimm. 

“Everything -- even rotating the cube 90 degrees -- was more work than we expected,” he admits. “These cubes, depending on the manufacturer, are different sizes, and the torque is different. If the cube was a little loose inside the arms, it wouldn’t rotate a full 90 degrees, so we had to optimize that in the software.

“Also, a lot of the parts we’d order wouldn’t work, so we had to go back and reorder things. The motors were a perfect example. We had three designs for what we wanted and we and almost went to a company to have them build a casing, but right before the order for the company was about to go through, we stumbled upon a better solution: We could do it ourselves, at less cost.”

The next step for the Ruku team is to get enough financial backing to market and sell the robot in educational kits, following the business model made popular by Tom’s® shoes -- buy one Ruku kit, and they will donate one to education. Their goal is to design the kits so students as young as 11 can assemble a Ruku in about an hour. 

“We did a lot of research on this and we know that students in middle school have the highest interest in STEM-based paths,” notes Stimm. “Kids are really engaged by these technologies. By capturing that age group, especially with a cool gender-neutral project like this, we hope to inspire them to be the next scientists and engineers.” 

Related Links

Computer Science and Engineering Department

Media Contacts

 Tiffany Fox, (858) 246-0353, tfox@ucsd.edu