P08205: RP 1 Motor Module First Generation

Mackos Interview 20070929

Interview with Nicholos Mackos

Interviewer(s): Emilien Barrault, Wendy Fung, Jasen Lomnick

Interviewee: Nicholos Mackos, RP100 Motor Module Project Leader, ME

Date: 29 September 2007, Java Wally's

What was your general experience with the project?
The design looked good on paper but actually implementing it proved to be difficult. The problem was that the projects weren't really integrated. The EE members did not get as far as hoped. The microcontrollers could do a few things. The platform was more concerned about getting theirs finished instead of working together. There were hardware issues due to the lack of integration between projects. The platform bypassed the microcontrollers all together and connected directly to the H-Bridges in order to make the robot move.
What were some issues with planning?
Many of the students did not pick the project. As such, everyone had to learn everything from the ground-up. It was difficult to get people motivated enough so they would own a subsystem. The team should have tackled on how to interface with the platform and getting it standardized first in order to establish a base for the teams.
What did you think about the PRP?
It was not actually clear on what the project was. It required Dr. Hensel to come in to talk with the teams for a few hours in order to get everyone on the same page. It would contradict itself occasionally and be convoluted.
What did you think of the kit last year? (Editor's Note: There was a kit for the AY 06-07 RP projects in an attempt to help facilitate understanding of how robots work.)
Nick did not like it very much. He would have preferred to have seen the extra money go toward buying parts. The kit was meant as a baseline for the project but it was too far removed from the actual project to be of much use. But the book recommended in the Robotics would have been useful. (Editor's Note: The book referenced is Building Robot Drive Trains by Dennis Clark and Michael Owings. It should be available in the bookstore during the winter quarter.) He believes that having a professor who taught Machine Design and the professor from the EE Tech lab who has knowledge about the motors come in and give a quick lecture would be very useful.
What do you think the new teams should consider as they move forward?
It is recommended that the teams try to run more simulations during the design phase. Nick's team had tried to look at how things worked mechanically but got stuck at the FEA, electric and programming analysis. RIT has software that allows simulations from the programming level all the way to the mechanical level. The control system can be looked at from within LabView and when used in conjunction with assembling in Solidworks. Together, by using CosmosMotion, a dynamic analysis can be accomplished. And so the simulation should be done in SD1 with manufacturing done in SD2. LabView can also be used to program the embedded processor.
What sort of problems were encountered between teams?
There was an issue with the control architecture of the robot. There were multiple controls: platform, motors, and the computer. But it was not established which controller would be responsible for what and how they would all work together. The members in charge of interfacing the two projects weren't interested in doing so. Rather, they were more concern about getting the grade. The CAN protocol that was been advocated did not have much focus.
How was communication dealt with between teams?
An executive board was created. The members were the project manager from each team. Each bought in a different perspective. A Google group was created to help with the process. The budget was shared across teams. Each member took on a role. For example, one would report on the electric portion while another would focus on the design elements. But when it came down to the wire, each person did not feel responsible for the others and focused on their own teams. Having every single person from the teams meet together resulted in chaos and yelling. So instead, the team leaders met to figure out tasks, go back to the team and debrief, and choosing members to focus on those tasks. It resulted in some reshuffling of the teams.
Anything else?
Having the platform and motor module ending at the same time proved to be a problem. Things weren't being accomplished quickly enough on either team to be able to pass information to the other. The components selected were not up to the task. For example, the H-Bridges frequently went into protect mode. The motor module itself could have been broken into several Senior Design teams. As such, there wasn't enough time to test the entire motor module.
Any thoughts for the RP1?
Going from 10kg to 1kg would be easier because of the less weight and robustness is a lesser concern. But it is going to be hard to be inventive on how to proceed. The motor module would have to be designed smartly and the team would have to be innovative in order to scale down. The team would have to be creative to accomplish the task but should also keep all of the functionalities. When designing the motor module, easy assembly and disassembly should be kept in mind.
Navigation Bar
Planning Mission Statement -- Staffing Requirements -- Intellectual Property Considerations -- Preliminary Work Breakdown Structure -- Team Values and Norms -- Grading and Assessment Scheme -- Required Resources
Concept Development Identify Customer Needs -- Establish Target Specifications -- Generate Product Concepts -- Select Product Concept(s) -- Test Product Concept(s) -- Set Final Specifications
System Level Design Product Architecture
Detail Design Design for Manufacturing and Assembly -- Robust Design -- Design for the Environment and Sustainability -- Design for Reliability -- Design for Safety
Testing and Refinement Prototyping