Electrical, Mechanical, and Software engineering students collaborate on paper-delivering robots
It was an ambitious project for any class. Teams of three or four students would be required to design, build, and test a self-powered robot capable of autonomously delivering a ream of paper to two multifunction printers on the Blue Level of Dunwoody’s main building.
Add to that a built-in safety mechanism so that it would stop moving when an object was placed in its way.
And they had to do it all with a budget of only $150 to buy all the parts used in making the robot.
But the project, which Assistant Professor of Mechanical Engineering Jonathan Aurand designed, wasn’t for any class: it was for Introduction to Engineering, a first-semester class offered fall 2018 for students entering Dunwoody’s Electrical, Mechanical, and Software engineering programs.
It was a lot to ask. But there was a reason for that:
“I designed this project so that it would be challenging, but achievable,” Aurand said. “In the real world, engineering problems are rarely well defined from the beginning. Part of the problem-solving process is to understand what the problem is as well as the various possible paths to solve it. The goal of this project was not only for the students to learn core skills like project planning, problem solving, and teamwork, but also for them to develop an understanding of how mechanical, electrical, and electronic systems work together to accomplish the desired result.”
This meant that there’d be a key role for all of the students no matter their major.
More importantly, it meant they’d learn from the beginning that their disciplines are intertwined.
Putting It All Together
The teams started by sketching out some initial ideas by hand. They then sourced parts and refined their ideas, including the housing, sensors, motors, wheels, power source, and a method for carrying the ream of paper.
Just like with real-world engineering projects, the limited budget and time-frame to complete the robot meant that they had to make difficult decisions about where to invest their time and money.
Brian Gonzalez Melgar, a first-year Mechanical Engineering student, said that he and his team looked for a solution that was lightweight, reliable, and inexpensive.
“We started by researching many different models and designing some of our own until we could all come to an agreement,” he said. “We decided on an OSOYOO robot kit that came with all of the components that we needed.”
Once they got their robot working, however, they discovered that the robot vibrated so much when it turned that the paper would fall off. To fix that, they purchased a wire letter tray and affixed it to the top plate of the robot.
Donald Posterick, Software Engineering student, and his team decided that it was most important to not lock themselves into a specific solution from the beginning.
“We started with a rough prototype frame made out of wood so we could immediately get our sensors and electronics interfaced and then began working on the programming for it,” he said. “We made iterative improvements towards the end goal with many revisions. By not worrying about perfection, but about functionality and reliability we were able to bring together the working pieces we developed into a robot.”
Each of the teams took different approaches, but all of them discovered that their design decisions led to certain strengths and weaknesses for their robots.
The Competition
The teams may have been aware of those strengths and weaknesses during their testing, but they really came to forefront with the competition, which took place at the end of the semester.
Aurand took a stack of paper printed with a thick black bar across it and then taped it together along the Blue Level hallway to create a 225-foot track from just outside the Robotics Lab to the multi-function printer and then also forked off to the other printer all the way down to the other wing of the building. The black bar gave the robots’ sensors something to navigate off-of.
Each of the seven teams tried their robot on the track. Dean of Robotics & Manufacturing E.J. Daigle used a foamcore sign to test each robot’s ability to stop when a barrier was placed on the track and then start again when it was removed.
The robot built by team 7 — Donald Posterick, Jess Johnson, and Jared Matteson — won the competition and was the only one that was able to complete the full course to the far printer.
Learning From Success and Failure
Even though only one team did the full run, how the other robots failed provided interesting engineering lessons.
One team discovered that while their robot could handle the weight load and traverse the course, it could only do so at a snail’s pace. Another had an impressively fabricated housing, but couldn’t get the software to draw enough power from the battery to drive the motor. Yet another discovered that their navigation software needed some fine-tuning as their robot weaved wildly back and forth as it over-corrected itself to stay on course.
“The recurring themes from the students’ presentations included how they planned and managed the project, dealt with setbacks, and worked together as a team,” Aurand. “One student in particular was very excited at the end of the project. He explained he didn’t think his team would be able to do complete the project when it was initially assigned, but he was impressed and proud of how far his team came; even though they did not win the competition. I believe all the students learned valuable lessons through this project and I trust they will apply them in their future coursework and ultimately in their future careers.”
And even the winning team discovered that their robot could use some improvements.
“I would say that the tuning for the Proportional Integral Derivative (PID) controller could be improved, which would allow the robot to not only go faster, but also to navigate smoother,” Posterick said.
What was most important, of course, was the overall process of tackling such an ambitious project.
“The main lesson that I could pull from this project is that mechanical engineering isn’t about working alone — it’s about working with other programs and coming together as one to complete a goal,” Gonzalez Melgar said. “I also think that this project is a good way to start your first semester because it lets you work with other engineering programs, and you end up learning a lot more than what you thought you would.”
Which is exactly why Aurand designed such a difficult project for first-semester engineering students in the first place. And why Dunwoody designed its School of Engineering so that you enter as an electrical, mechanical, or software engineering student from day one.
Learn more about Dunwoody’s School of Engineering.