P08205: RP 1 Motor Module First Generation
/public/

Transcript and Notes on Large Group Interview - 10-11-07

Jason Kenyon: Most of us here are mostly mechanically adept, so we are confused on exactly how the MM's are controlled, like the control architecture. I think we need a background knowledge of how that works so we can possibly set up a standard control architecture for the 5 different project. It is my understanding is that there are 2 different control architectures, CAN and SPI, and they control PWM units, and then that PWM unit controls the motors.

Hensel: Do you know what PWM is and how it works?

Team: Not in detail

Hensel: Lets discuss that. If you understand the core technology you might better understand the difference between the controls and the communications. So you have a DC motor, and sometimes you dont want to run that motor full out. Sometimes you want to just turn the motor on and let it roar and let it go full speed, but usually you want to start and slow down, accelerate, decelerate, go slowly, go rapidly etc. in a robotic system. One way you can control the speed of a DC motor is to adjust the voltage being provided to the motor. That is not a really effective means of controlling the speed to the motor. You tend to be way off the efficiency curve, and you could shorten the life of the motor. A slightly more sophisticated way to vary speed would be to turn it on and off for intervals of time. Duty cycle refers to the amount of time a motor is running during a period of time. Pulse Width Modulation (PWM) says were going to take a motor and if there is a 1 cycle interval, if we turn the power onto the motor at full voltage for 50% of the time and off for 50% of the time, it will roughly move at half speed. If you turn it on for half of the time and off for half of the time, it will be spinning the motor at roughly half of full speed. That is what PWM is. And then youve got the period of the pulse. If you have a really long period you have a jerky motion of the motor where you turn it on and off slowly for long intervals. As you decrease the pulse width (increase the frequency), you would maybe turn the motor on and off 1/1000 times a second, it appears to be continuous operation but it is actually on for a certain amount of time and off for a certain amount of time. So Pulse Width Modulation is where you have a pulse width, and the shorter the pulse width, the closer you get to a continuous operation. There is a limit however, so you cant have a pulse width too short. You change the speed by changing the duty cycle, or the fraction of time that the power is on. So there is a motor controller, and there are many different motor controllers that are commercially available on the marketplace, and there are some that have been locally developed at RIT as well as other academic institutions, that take a digital signal called a PWM signal. That PWM signal is usually a low voltage signal, like a TTL voltage signal like 0-5V. It is a command signal that doesnt carry significant current. It is simply providing instruction. As that PWM signal goes to 100% duty cycle, you are telling the motor controller you want to run at full speed. That controller is a piece of power switching hardware. On the controller you have a PWM signal that has a square wave shape to it. Then you have power coming in (+V and -V or ground) and then you have power going out that is connected to the motor. This controller flicks the power switch thousands of times a second. The motor controller switches the power on and off in response to the PWM command. You can buy those motor controllers and you can also build them. The motor controllers are rated by how much current they are able to pass through them and what voltage they are able to switch. The motor controllers are typically expecting some standards on what kind of a PWM command they are going to be driven by. It could be a 0 to 5V command, which is the most common.

Jason Kenyon: Where does the PWM command come from?

Hensel: The motor controller is at the hardware level. That PWM signal can come from many different sources. You could take a function generator that you have sitting on top of a benchtop, and produce a square wave coming out of that function generator with a BNC connector, and you could drive a motor controller with a piece of laboratory equipment, the function generator. So that is entirely appropriate for benchtop testing and proof of concept. You could have any other digital system produce that PWM signal. There are PLC's (Programmable Logic Controllers) that can produce PWM signals. You could create a piece of hardware that would be driven by a USB port on a computer that would produce a PWM signal. Or you could receive that PWM signal as a command and control strategy over some kind of network. So 2 common communications protocols that were looked at last year were SPI and CAN. SPI and CAN are 2 alternative techniques to providing the PWM signal to the motor controller. They have a lot more capability than just that. Typically there has to be an interpreter. This is a communications protocol that can handle lots of commands. There has got to be some smarts that are interpreting the commands coming from a SPI or CAN bus and sending the PWM signal to the individual motor controllers.

Phillips: The 2 communication protocols SPI and CAN are both what are known as serial communication protocols, which means they send information out one bit at a time. Its a sequence that is similar to Ethernet. SPI is fairly high speed, and really meant to be point to point. One of the reasons it can achieve a high rate of communication is that it sends the ones and zero's along with a clock line so the receiving party knows precisely when to look at the bits. It is not really meant to be in a distributed environment where you would have to speak to 5 or 10 different things. CAN is also a known as a synchronous serial communications standard. It sends out bits 1 bit at a time, and is meant to support a network of connected devices. It was developed by Bosch. It is meant to provide networking and is specifically applicable to an automotive application. You have an engine controller that takes in inputs from brakes, manifold temperatures, the oxygen sensor, and you'd like to have one network that you could just plug into and not have to have too much intelligence on the thing you plug in. It also has to be robust to exist in a harsh environment, so the signals, instead of having a ground in the signal wire, it is a differential pair to help eliminate contamination due to noise.

Jasen Lomnick: What is a differential pair?

Phillips: Basically if you have a signal from a function generator, for example, you have a ground line, and then you have a signal line. The ground line is a return path. The signal line is the voltage changing line. What a differential pair does is actually send out the signal in a differential fashion, sort of plus and minus on 2 lines. The benefit of that is if you have interference, it is common to both lines and essentially cancels it out. So in an automotive environment, or in this case a bunch of motors that are turning on and off, it is common to have a lot of noise on the power supply. So the differential pair helps a lot. More to the point, it is meant to support a network of multiple devices, which in your case might be perfect, especially if you were to have more than 1 of these motor modules and who knows what else is on the robot. The bad news is that to support that protocol, you have to have a little more intelligence on both sides. Some good news is that most microcontroller manufacturers recognize that a lot of people are driving cars and put electronics in them are supplying their microcontrollers with a CAN interface, so it is common to have a microcontroller like a PIC microcontroller that will have that CAN interface built into it. Also, some software support makes it easy for you to send stuff out without having to know the whole protocol. All of that stuff is taken care of as a set of routines.

Jasen Lomnick: So we could possibly find a PIC microcontroller that could accept CAN signals and set that as the standard for each of the 5 motor module teams. That is one direction we were trying to go with is to have a single communications system between each of the motor modules so that if they are on a different platform, the platform doesn't have to read multiple control languages. So does that seem feasible?

Hensel: Ultimately when you go to drive the DC motor, there is going to be a PWM signal in the loop. My recommendation is that you have that PWM signal be an interface point. Whether that PWM signal is coming from a function generator, or from a smart chip that is hanging off a SPI network or CAN network really doesn't matter. I think all 5 teams should accept a PWM signal as an input to drive the MM. You may decide that one of the teams is going to have strong responsibility for the mechanical drivetrain design of the motor module because it has a lot of ME's on it or that is where people's personal interests are, and you may have another MM team that has much more microprocessor focus. So you can say 'if one team is designing the structural part, let's propagate that across all the teams'. You may have some competing ideas for structural teams. I think it makes sense to have the PWM be a natural interface point for a MM. If we think about the minimum acceptable deliverable, you could develop a MM that was driven by a PWM signal that was coming out of a function generator, and not even have to touch SPI or CAN. So you have a very high probability of success of having a functioning MM without having to be distracted by SPI or CAN. At the same time, once that functional PWM Motor Module is working, having the ability to say 'ok now I'm going to disconnect the function generator and connect a SPI-smart Micro-controller that is going to deliver the signal. So I can imagine you have a motor module. That motor module gets a PWM signal and gets power. That's all it really needs to know about. One way to drive that PWM signal would be a with a function generator, and that is appropriate for benchtop lab testing. Another way is to have a computer programmable function generator and have a computer send signals to a function generator. Now we could take that function generator out and we could put a SPI receiver and a SPI transmitter in and have a computer drive a SPI transmitter where there is a physical wire between the two and now you have a motor module specific spy receiver which delivers the PWM signal to the motor. Or you could have a CAN receiver and a CAN transmitter. So you have a wired connection which produces a PWM signal that comes from a computer. Or now this computer could be replaced by an FPGA microprocessor or a laptop, so rather than relying on a big desktop computer with a lot of smarts you could have the actual robot itself have some significant smarts on the onboard computer that drives the system. So it's very modular in design. You could design the motor module and be highly confident that you could drive it with a piece of laboratory equipment that is available today with no development time, no questions, it's there and robust and done. But then say as we move forward there are some distinct advantages to SPI and there are other distinct advantages to CAN. I think as you go towards the smaller modules, SPI probably would win. As you go towards the bigger vehicles like 1000kg payloads, CAN would probably win. So there is value in having the architecture of the family be supportive to both so that, like, if there is a PWM interface, as long as the cable has the same physical connector, it doesn't care if it is being driven by SPI or CAN or anything else. So you might very well have one team that has a lot of EE's and CE's that investigate CAN and they focus on that connection. You could have another team that says 'were going to investigate SPI', and they are not competing with one another; they are collaborating. SPI is going to be easier to implement I think. Is that right?

Phillips: Yes I think so.

Hensel: So it is highly likely that the SPI team gets done in one SD cycle. With CAN there is a lot more work. They might not be fully deployable by the end of May, but they can make some pretty good progress and it might take another full design cycle before CAN can be fully deployed. That is ok. It's technology maturation and development. I think that could easily be a set of parallel projects where there is a lot of benefit to be gained from collaboration between the groups but no competition.

Jasen Lomnick: Now if they focused on those electronic portions, where would their responsibility be held on the physical motor module (mechanical portion)? Would it be ok to say 'you just focus on SPI or CAN and have other teams that you can connect to and work with on the mechanical side'?

Hensel: You are defining the projects right now. These projects could be defined in many different ways. I think we want to avoid saying 'We'll put all the EE's over here doing that, all the ME's over here doing that etc.' That is somewhat the natural tendency, but youre going to have problems. My recommendation would be that you take the idea that maybe you think about this cross-functional teams. You may have one team that is responsible for a CAN based motor module, another that is responsible for a SPI based motor module, and another team that is responsible for a benchtop motor module that only gets one EE on it and it gets heavily loaded with ME's. The others may get more heavily loaded with EE's and CE's. All this builds on the strengths that a particular project needs. Then you might say 'all the ME's on the team are responsible for making sure that the powertrain is robust, because every team needs a robust powertrain. Every team needs a robust PWM motor controller whether it's built in house or available off the shelf. Maybe all 5 teams say that it is in their vested interest to have an open architecture motor controller. So even today we could go out and buy a Victor Motor Controller for $80 off the shelf, it's here in 2 days delivered. There are probably some in the cupboards over here even. These motor controllers already exist, but they are proprietary and $80 apeice. Eventually it might be nice to build our own. So if they are interchangeable, they are not mutually exclusive so that if you look at the physical connector that is used to deliver power to the motor controllers and the PWM signal to the motor controller and look at the physical mounting pattern, you could easily say that you are going to develop your own motor controller that is physically interchangeable with this off the shelf motor controller. BUT, we have a victor ready today. So our goal is, by the end of SD1 to have an open architecture replacement for the victor. Maybe we won't quite make it for the end of SD1 so we're going to go ahead and keep working on it through SD2. If you find yourself getting down to the last week of SD2 and it's not working so great, you are still able to demonstrate that the motor module works with the victor. Right now we have many components where any single point of failure leads to a system failure. We want to get to the point where there are so many alternatives that if one piece is not working that you can get a complete working system somehow and demonstrate full functionality. To me that is elegance in design and that is impressive. Maybe we could have a 5th path where we say that 'weve been working with this protocol and there are some fundamental flaws but we have this other type of protocol that is custom made by us and will work'. Eventually when our technology matures we can get to the point where we truly drive innovation in this area. There are COTS chips that recognize CAN today. Well alright so we may not make our own chip today but maybe a couple years from now the microelectronic students would like to make their own chip.

Phillips: Students could even develop their own RIT communications protocol

Hensel: Yes, open architecture RIT-Comm.

Jason Kenyon: Will our motor module contain the actual module that uses SPI or CAN as a language? Like what will the motor module team be responsible for and what is the platform team responsible for? Does the platform simply supply the DC power?

Hensel: The goal of the Motor module's team last year was to have their MM be a smart MM. Their goal was to put the break at that level so that this MM could be plugged into say a CAN network which is a bus network. Last year the team was attempting to make it so the motor module was listening on the communications bus. It knew what it had to listen for on that network like 'Motor module #10, turn left!' . So it had power coming in and a CAN or SPI signal coming into it. That was their objective. That's why there were microprocessors and motor controllers local to the motor module. That was the architecture they were promoting. I think there is value to that. You saw some of them that had the circular disc motor controller. The nice thing about this is that the “listener" smart chip could be mounted on the motor controller or it could be physically mounted a short distance away on the platform and have a PWM signal go from the motor module to that chip. There is nothing about the architecture that says it has to be physically on the motor module. The farther away you get, the PWM signal going long distance might be degraded, but at the scales you're talking about, it's not an issue I don't think. So the smarts can be put on the motor module or they can be put on the platform. They are not mutually exclusive, especially if you design them well. At your scale it might be better placed on the platform for noise purposes unless you use some shielding. Whether you choose to put it on-board or off-board this year, it's an order of magnitude less important to me.

Walter: About the EE courses that are required; is the SPI protocol taught in any EE courses?

Phillips: No. SPI protocol is in an elective but not in any required courses. Everybody takes Micro-computers and we talk about RS232 and I2C for example.

Hensel: So they all get exposed to I2C?

Phillips: Well mostly it's only mentioned once. I'm not as familiar with the CE curriculum but I would have to check if that protocol was taught in there. With recruiting students you might want to make that a requirement for enrollment into the team.

Hensel: How about PWM?

Phillips: That should be part of the curriculum in power electronics, but I do not think that is a core course. PWM however is taught in an elective computer course.

Hensel: I think that PWM would be a much lower hurdle for any EE to come up to speed on. Even if they didn't have experience with PWM, any of the EE students should be able to get up on that curve pretty quickly. I2C is on I didn't even mention. That is probably the next level of difficulty. SPI is one level of difficulty up from there and CAN another level up. Each are increasingly sophisticated variations on the same underlying idea.

Phillips: I will double check about what students should have what experience.

Hensel: When you are looking for your EE's you would like them to have either a computer engineering option or power systems course?

Phillips: Power systems would actually be more towards this side of things

Hensel: So if you had an EE with power systems across the multiple groups or a couple of them, then they can help one another. If you have and EE with comp. engineering, they are going to tend to gravitate towards that aspect of the problem.

Jason Kenyon: One of the other things we are talking about is a common mounting height for all designs to mount to the platform. Do we want to be able to put any teams RP1 motor module on a single platform design and be able to control it?

Hensel: Yes

Jasen Lomnick: So what about if we had many teams different motor modules on the same platform and they were able to all be usable at the same time? Hensel: That would be impressive to me, especially if they were able to drive together and everything

Jason Kenyon: What about if different teams had for example different drive gear ratios? There would be a lot of challenges involved in that.

Hensel: That would also be very impressive to me. Highly impressive would be: you have a 4 wheeled vehicle and there are 5 different motor module designs from 5 different teams and I could pick any 4 of the 5 MM's, put it on the platform, and it works. That would be very impressive. The next level of impressiveness would be some subset of those 5 different designs, like maybe designs 1 and 2 are interchangeable and designs 3 and 4 are interchangeable, and design 5 is not. That is still pretty darned good. The next level below that in impressiveness (still quite good), is where I would have a single platform and I can take 4 design 1's and drive a platform, take those off, take 4 design 2's and place then on the platform and drive it, etc. so that they are all the same design but interchangeable within a design. The least impressive would be if we had to physically change the platform in order to move from module design 1 to module design 2 etc.

Jason Kenyon: So if we wanted to be really impressive we should probably design a common mounting height

Hensel: Yes. Your questions here about common mounting height, bolt pattern etc are definitely good to ask.

Jason Kenyon: I think we really do want to establish a common way to physically and electrically interchange the motor modules and have them perform the same way but not necessarily make it so you can take 2 different designs and make them move the same platform

Hensel: I think the interchangeability across designs is very important. If you focus on the interfaces you have a good chance of success. Defining those interfaces very well is an excellent idea. The more interchangeability you have within that interface is a higher level of refinement.

Jason Kenyon: For the electrical interface between the motor module and platforms you are obviously going to have to have a connector and preferably a quick disconnect. There are probably problems with having a controls wire and a power wire close to each other, is that correct?

Hensel: Yes. But that will be less-so as you get smaller and more-so as you get bigger. It is conceivable for your size that you could put them on the same connector but I probably would stay away from that.

Jason Kenyon: Do we want to be able to power this with a DC power supply like a battery?

Hensel: Yes, it will be a battery power source when you use a platform. But when you do benchtop testing I suspect you will probably want the ability to drive it with a benchtop power supply. That may be feasible for your size project but not necessarily feasible with larger size motor modules. Walter: You may want to think about having your motor module team also design a test fixture that the motor module will sit in and it can actually plug into a terminal strip of some sort so that you can easily make your connection through a DC power supply and eliminate the need of holding it up and trying to wire connect it shoddily

Hensel: That is an excellent thing to have and is something a lot of teams don't have until the point at which they are testing. If you had a common height and mounting fixture and electrical connectors and 5 teams with all that. You have students early on that need to get familiar with the project, use their hands and build stuff. You should get a design going and within the first 2 weeks you could have a test fixture built and say 'this is the fixture that were going to mount our modules on so you can see physically what the mounting bolt pattern looks like, and let's build 5 of them so every team has one'. Or you could have just 2 where you have mechanical students use one and electrical students use another. In that first few weeks, the most critical thing is to get all the students really understand what the project is. So if you start out saying 'here is our test fixture and this is what you have to design to'. These test stands don't have to be anything fancy, but having them done is worth a lot. If you know what power connector and PWM connector you are going to have, put them on a test stand. It doesn't have to be fancy. If you start out by specifying it to be a team project that would be useful. It also makes the team very engaged and positive.

Jason Kenyon: What sort of connections are available? I am familiar with quick disconnect for DC power, but what sort of connections are there for communications wires.

Hensel: At this level what you will have are PWM twisted cables. You can go on robotics supply websites and find that they sell PWM cables WAY overpriced. Go to digikey and you can buy connectors by the thousands.

Navigation Bar
Home
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