You have /5 articles left.
Sign up for a free account or log in.
Andrew Stelter, South Dakota School of Mines and Technology
The robotics industry is evolving quickly -- so quickly, in fact, that higher education programs in computer science are struggling to keep up.
About a decade ago, Jeff McGough, professor of mathematics and computer science at South Dakota School of Mines and Technology, started teaching a graduate course in robotics. Textbooks and other course materials that approached robotics from a computer science perspective were almost nonexistent, aside from some materials for K-12 students working with Legos.
McGough tried to solve the problem a few different ways. First he wrote a textbook, but he never published it. Then he subscribed to some commercial tools and employed physical robots, but the learning curve -- and the minimum $3,000-per-student price tag for hardware -- proved too steep.
“It just took us all semester to get to the point where they could move the simulation robot,” McGough said.
Most simulation products are industry tools, designed for professionals or students who have had at minimum two semesters of training. McGough wanted something more straightforward, allowing students more time to focus on the concepts.
Last fall he took matters into his own hand, enlisting three students from his senior capstone course to create a simulation tool for future students of his courses, and beyond. The result is the RoboScience Simulator, an open-source platform that includes a simulation tool, free textbooks and basic robotics software.
McGough will roll the program out to other instructors at the School of Mines this fall, with the goal of expanding access beyond his institution in the next year or two. He also plans to introduce the tools to schools in the local K-12 district, which includes students from some of the least affluent Native American reservations in the country.
McGough and his collaborators started by assessing existing tools, like an open-source project from 15 to 20 years ago that established a 2-D robot simulation. Those efforts didn’t get an update until the 2010s, when three Greek electrical engineering Ph.D. students decided to write a replacement for it. The only problem: the robot's movements didn't adequately mimic real-life physics.
The South Dakota project set out to succeed where the Greek students had faltered -- implementing a “physics engine” that allows simulated robots to process when they’ve run into a wall. McGough broke the project into “sprints” of two weeks apiece, wrapping up an alpha version in May.
“I’m sure it’s going to blow up on me lots of times, because new software does,” McGough said. “But the grad student’s still around -- he and I can try to finish and polish it.”
The simulation tool allows students to program a robot to perform basic tasks like following a line, navigating a maze and moving objects from one place to another. McGough used to spend the bulk of a semester teaching students how to complete these tasks using physical robots that would frequently malfunction or even break altogether. The software lets students engage in more trial and error, giving them a sense of what’s possible with their robot without derailing their learning momentum.
The most challenging part of the process, according to McGough, was “getting the physics to look right.” The physics engine they used is designed to deal with multiple loose objects rather than a collection of interconnected objects that make up a singular entity (the robot).
Andrew Stelter, who graduated in May with a bachelor’s degree in computer science and is now pursuing a master’s degree there in the same discipline, had taken McGough’s introduction to robotics course during his junior year, and he jumped at the opportunity to work with McGough on an ambitious project for his final undergraduate project. Until then, though, he hadn’t even imagined a better tool than the ones he and his peers struggled to use.
“We accepted it as part of the process, because we were required to use it for the course,” Stelter said.
The project cost "several thousand dollars of faculty time," according to McGough -- he describes the project as a relatively modest investment, given that much of the work was student driven. Each student took a distinct role: one concentrated on the user interface, another conducted research on transferring a specific feature from the old simulation to the new one and Stelter focused on back-end coding.
“It ended up being a homework project that was just a lot bigger than any other homework projects we’d gotten,” Stelter said. “There were definitely times we thought it may not work the way we wanted it to.”
