Electrical engineers, mechanical engineers, control systems engineers: how do you work together, really?
June 6, 2010 8:35 AM Subscribe
I’m tasked with writing an article about a new "mechatronics" device. I have an engineering degree and understand the device and its benefits. I’m having trouble with the “mechatronics” part since I have not actually worked as a development engineer. I’m hoping that some practicing engineers can shed some light on how EEs, MEs and control systems engineers work together.
The device integrates a novel type of motor along with its drive ASIC, a position sensor and a microprocessor, in one package. It’s intended to be embedded in handheld products.
I am told by the inventor that the disciplines of EE, ME and control systems engineering are still largely separate, and that typical product development teams have an ME to define the motor and mechanical interface, an EE to design the driver, and possibly a software engineer or systems engineer to program the system. (The inventor is basing this assertion on experience with large companies who are interested in reselling the motor, but are adamant that end users to want to design their own drivers and control circuits.)
The inventor asserts that mechatronic devices such as this one will change the way product development teams work, because they only need drop the device into the product design and feed it high-level commands to make it move.
Is the assertion true in a broader sense? Is that the way “typical” product development teams work? Or is there a lot more cross-over among disciplines than that?
Thanks in advance for any insights.
The device integrates a novel type of motor along with its drive ASIC, a position sensor and a microprocessor, in one package. It’s intended to be embedded in handheld products.
I am told by the inventor that the disciplines of EE, ME and control systems engineering are still largely separate, and that typical product development teams have an ME to define the motor and mechanical interface, an EE to design the driver, and possibly a software engineer or systems engineer to program the system. (The inventor is basing this assertion on experience with large companies who are interested in reselling the motor, but are adamant that end users to want to design their own drivers and control circuits.)
The inventor asserts that mechatronic devices such as this one will change the way product development teams work, because they only need drop the device into the product design and feed it high-level commands to make it move.
Is the assertion true in a broader sense? Is that the way “typical” product development teams work? Or is there a lot more cross-over among disciplines than that?
Thanks in advance for any insights.
Best answer: Many people have invented many things that remove certain steps of the engineering process. There are lots of off-the-shelf products available -- motor controllers are just one example, as well as various sensors, sensor mounts, etc -- that engineers usually had to develop on their own in the past. However, the creation of these COTS products does not so much change the development *process* as it changes what the developers are working on.
Engineering development I find to be a lot like the scientific method; there are certain prescribed steps that you follow the same way at both a very high level and at a very low level. For example, I work on robots. For each huge complicated $1M robot that takes a year to develop, there's a team of some people who come up with high-level requirements, define the interfaces between the disciplines, create some architecture, and then execute. Within the larger robot proejct, there are teams who work on extremely low level things, like an interface circuit board. Maybe it only takes a week to design and test, but it still requires a couple of people sitting in a room to come up with requirements (size/shape/power consumption/etc), define the interfaces to the other electronics (USB/serial/power/etc), architect it, and then execute on the design. On any given project I work on, there are dozens of times the "development process" is used to manage some part of the system or subsystems.
So, back to your person's invention. If i now have a little module that eliminates one subsystem I have to develop, that's probably pretty great -- like all the other COTS modules that have come along in the past couple of decades, it will make things go faster. That's one less group of people you have to have sit around the table and design something, and instead you can just buy it, install it, and focus on interfacing to it. BUT. The *process* of developing that interface, and the process of building that product as a whole, has not changed, regardless of what revolutionary COTS modules have appeared in its bill of materials.
posted by olinerd at 9:31 AM on June 6, 2010 [1 favorite]
Engineering development I find to be a lot like the scientific method; there are certain prescribed steps that you follow the same way at both a very high level and at a very low level. For example, I work on robots. For each huge complicated $1M robot that takes a year to develop, there's a team of some people who come up with high-level requirements, define the interfaces between the disciplines, create some architecture, and then execute. Within the larger robot proejct, there are teams who work on extremely low level things, like an interface circuit board. Maybe it only takes a week to design and test, but it still requires a couple of people sitting in a room to come up with requirements (size/shape/power consumption/etc), define the interfaces to the other electronics (USB/serial/power/etc), architect it, and then execute on the design. On any given project I work on, there are dozens of times the "development process" is used to manage some part of the system or subsystems.
So, back to your person's invention. If i now have a little module that eliminates one subsystem I have to develop, that's probably pretty great -- like all the other COTS modules that have come along in the past couple of decades, it will make things go faster. That's one less group of people you have to have sit around the table and design something, and instead you can just buy it, install it, and focus on interfacing to it. BUT. The *process* of developing that interface, and the process of building that product as a whole, has not changed, regardless of what revolutionary COTS modules have appeared in its bill of materials.
posted by olinerd at 9:31 AM on June 6, 2010 [1 favorite]
I just realized my first sentence conflicts with the rest of my text. (Oh, my kingdom for an edit window...) What that should read is something more like, "Many people have invented many things that reduce the number of new things that have to be developed in a new system or product.
posted by olinerd at 9:32 AM on June 6, 2010
posted by olinerd at 9:32 AM on June 6, 2010
Look at some sites frequented by people doing DIY CNC machines if you want to look at how different individuals see the design issues you're talking about. You're mostly not going to be dealing with engineers of any stripe at these, but people tend to come to the table thinking in terms of electronics or mechanics just by virtue of the source material that is out there.
posted by Kid Charlemagne at 12:30 PM on June 6, 2010
posted by Kid Charlemagne at 12:30 PM on June 6, 2010
Best answer: It sounds like you're talking about phidgets.
I do prototyping, so I don't know exactly what you're asking, but I do work alongside the process. Having drop-in components with high level control is a life saver when developing prototypes. If I want to make something move I don't want to have to make a motor driver and a power regulator, and a gear train too. With an integrated module the number of things I have to know has been reduced by several orders of magnitude. (For the example of a motor, now all I need to know is RPM, torque, power requirements, and measurements. Whereas otherwise I'd need the equivalent of degrees in EE and ME.)
However that's just for a prototype or a one-off build. If you're talking about building a commercial product these modules make little sense. A prebuilt component is either over or under built for the design, and they're full of redundant hardware everywhere because they were designed to be mostly independent. So once a concept has been shown to work it's sent to a fleet of smart and experienced engineers, designers, fabricators, machinists, accountants, purchasing agents, etc to apply their magic to the finished product. One of their main jobs is to make it as cheap and reliable as possible. This includes drastically reducing the parts count, picking the parts with the correct wear characteristics, etc, which is the opposite of a generic prebuilt module. For example the prototype might have several microprocessors communicating with each other in different parts of the device. But that's expensive and redundant, so they would consolidate those functions as much as they can. The product goes through a number of cycles where different versions are made, put through testing of systems and subsystems and tweaks are made, either replacing, redesigning, or rearranging components or features. I can't conceive releasing a product to the general public that didn't pass under the scrutiny of all of these highly trained people. Yes, it's an expensive and time consuming process, but without them the product would be very expensive and still perform poorly. Otherwise it's like saying you can just put any old wings on an engine and have an airplane. Hop in, lets go!
On the other hand there are certain base components that manufacturers drop in to designs and are are happy to have them. They tend to fall into two categories: The super, cheap, simple, common functions (like pretty much every IC ever developed) or the expensive, complex, single function things. LCD displays for example often include the glass and a driver circuit to make it relatively simple to interface with. Other examples wold be bluetooth transceivers, GPS, and camera imagining elements. If this invention falls into this category, he's got to find a major manufacturer like Toshiba to build and sell them.
Just to give you a timely example, I recently made a prototype where I used a high level servo driver module. It was great for the prototype because it made development much faster. But the component would add around $30 to the retail price of the item. Smart folks figured out how to do the same thing with some clever programming and about $0.35 worth of parts.
So I guess what I'm saying is that the process works and exists for a reason. If the invention isn't going to make development significantly shorter and the product cheaper then it's going to be a hard sell. A motor driver alone isn't going to keep from needing an EE and ME on the project. Any project that has a motor driver has other requirements that they'll need to be consulted on, especially a handheld device.
posted by Ookseer at 1:13 PM on June 6, 2010
I do prototyping, so I don't know exactly what you're asking, but I do work alongside the process. Having drop-in components with high level control is a life saver when developing prototypes. If I want to make something move I don't want to have to make a motor driver and a power regulator, and a gear train too. With an integrated module the number of things I have to know has been reduced by several orders of magnitude. (For the example of a motor, now all I need to know is RPM, torque, power requirements, and measurements. Whereas otherwise I'd need the equivalent of degrees in EE and ME.)
However that's just for a prototype or a one-off build. If you're talking about building a commercial product these modules make little sense. A prebuilt component is either over or under built for the design, and they're full of redundant hardware everywhere because they were designed to be mostly independent. So once a concept has been shown to work it's sent to a fleet of smart and experienced engineers, designers, fabricators, machinists, accountants, purchasing agents, etc to apply their magic to the finished product. One of their main jobs is to make it as cheap and reliable as possible. This includes drastically reducing the parts count, picking the parts with the correct wear characteristics, etc, which is the opposite of a generic prebuilt module. For example the prototype might have several microprocessors communicating with each other in different parts of the device. But that's expensive and redundant, so they would consolidate those functions as much as they can. The product goes through a number of cycles where different versions are made, put through testing of systems and subsystems and tweaks are made, either replacing, redesigning, or rearranging components or features. I can't conceive releasing a product to the general public that didn't pass under the scrutiny of all of these highly trained people. Yes, it's an expensive and time consuming process, but without them the product would be very expensive and still perform poorly. Otherwise it's like saying you can just put any old wings on an engine and have an airplane. Hop in, lets go!
On the other hand there are certain base components that manufacturers drop in to designs and are are happy to have them. They tend to fall into two categories: The super, cheap, simple, common functions (like pretty much every IC ever developed) or the expensive, complex, single function things. LCD displays for example often include the glass and a driver circuit to make it relatively simple to interface with. Other examples wold be bluetooth transceivers, GPS, and camera imagining elements. If this invention falls into this category, he's got to find a major manufacturer like Toshiba to build and sell them.
Just to give you a timely example, I recently made a prototype where I used a high level servo driver module. It was great for the prototype because it made development much faster. But the component would add around $30 to the retail price of the item. Smart folks figured out how to do the same thing with some clever programming and about $0.35 worth of parts.
So I guess what I'm saying is that the process works and exists for a reason. If the invention isn't going to make development significantly shorter and the product cheaper then it's going to be a hard sell. A motor driver alone isn't going to keep from needing an EE and ME on the project. Any project that has a motor driver has other requirements that they'll need to be consulted on, especially a handheld device.
posted by Ookseer at 1:13 PM on June 6, 2010
Best answer: It sounds like you're talking about phidgets.
I thought it sounded like evilmomlady was talking about servo motors.
The processes I've seen have involved small groups of engineers. Often there will either be an engineer knowledgeable enough to specify both a motor and a control board; or there will be an arrangement used previously part of which can be reused.
There will be a specification, an iterative process of design and redesign, and regular meetings between people working on related areas.
So for example engineers might decide at the start of a project "the robot will weigh about 25kg and be able to ascend a 45 degree slope". Then they might look at how much power that will require, and what batteries and motors are available (if they're experienced they probably have a fair idea) and make provisional decisions - on the electronics side, they might say that 22v batteries which can supply 100 amps look like a good choice; on the mechanical side they might be thinking of either direct-drive of the wheels, or offset motors with spur gears driving annulus gears at an eight-to-one reduction ratio, on the cost side maybe there's a budget of about $500 for the drive train. At that point it's easy enough to start looking at motors, control boards, and feedback sensors.
Motor selection usually seems to fall to mechanical engineers, as they're in a position to modify the drive train (e.g. by changing gear ratios) if the design calls for it. On the electronics side, as long as the motor is the right voltage and doesn't demand too much current, there's flexibility.
If it's not possible to find a motor to meet all the requirements, the next time the engineers meet up they can decide on a course of action - bigger batteries, spending a bit more money, reducing the weight, and so on - or if it's a mechanical change like a change to the gearing, the mechanical engineer can just go ahead and make the change.
And if you've made a previous product and you got on well with that brand of motor controller which can supply sixty amps per channel, and your software already works with it, then as long as your motors are below sixty amps, why change the sensors and control boards at all? Unless there's some compelling reason to change.
posted by Mike1024 at 1:19 PM on June 6, 2010
I thought it sounded like evilmomlady was talking about servo motors.
The processes I've seen have involved small groups of engineers. Often there will either be an engineer knowledgeable enough to specify both a motor and a control board; or there will be an arrangement used previously part of which can be reused.
There will be a specification, an iterative process of design and redesign, and regular meetings between people working on related areas.
So for example engineers might decide at the start of a project "the robot will weigh about 25kg and be able to ascend a 45 degree slope". Then they might look at how much power that will require, and what batteries and motors are available (if they're experienced they probably have a fair idea) and make provisional decisions - on the electronics side, they might say that 22v batteries which can supply 100 amps look like a good choice; on the mechanical side they might be thinking of either direct-drive of the wheels, or offset motors with spur gears driving annulus gears at an eight-to-one reduction ratio, on the cost side maybe there's a budget of about $500 for the drive train. At that point it's easy enough to start looking at motors, control boards, and feedback sensors.
Motor selection usually seems to fall to mechanical engineers, as they're in a position to modify the drive train (e.g. by changing gear ratios) if the design calls for it. On the electronics side, as long as the motor is the right voltage and doesn't demand too much current, there's flexibility.
If it's not possible to find a motor to meet all the requirements, the next time the engineers meet up they can decide on a course of action - bigger batteries, spending a bit more money, reducing the weight, and so on - or if it's a mechanical change like a change to the gearing, the mechanical engineer can just go ahead and make the change.
And if you've made a previous product and you got on well with that brand of motor controller which can supply sixty amps per channel, and your software already works with it, then as long as your motors are below sixty amps, why change the sensors and control boards at all? Unless there's some compelling reason to change.
posted by Mike1024 at 1:19 PM on June 6, 2010
Response by poster: Thanks all… very helpful! I realize I was over-stating the “change the way you work” angle and will downplay or eliminate that.
Also my use of the word “inventor” was probably misleading; it’s not one guy with an idea but a small company full of experienced and smart engineers. I know they understand their customers’ processes so the over-statement error was mine.
@Ookseer and @Mike1024 – if you’re curious, it’s not phidgets or servos; it’s piezoelectric motors. The company absolutely understands about prototype vs. production, and have helped their customers develop drive circuits, but doing it optimally takes much specialized knowledge of piezos. We believe most customers won’t find it efficient to develop this specialty in-house and that providing a customized drop-in subsystem is probably the answer.
@Mike1024 - The only compelling reason to change is if you need something much smaller than servos, and using way less than 60 amps.
Thanks again, I really appreciate the time you took to share your insights.
posted by evilmomlady at 4:50 AM on June 7, 2010
Also my use of the word “inventor” was probably misleading; it’s not one guy with an idea but a small company full of experienced and smart engineers. I know they understand their customers’ processes so the over-statement error was mine.
@Ookseer and @Mike1024 – if you’re curious, it’s not phidgets or servos; it’s piezoelectric motors. The company absolutely understands about prototype vs. production, and have helped their customers develop drive circuits, but doing it optimally takes much specialized knowledge of piezos. We believe most customers won’t find it efficient to develop this specialty in-house and that providing a customized drop-in subsystem is probably the answer.
@Mike1024 - The only compelling reason to change is if you need something much smaller than servos, and using way less than 60 amps.
Thanks again, I really appreciate the time you took to share your insights.
posted by evilmomlady at 4:50 AM on June 7, 2010
« Older Kindle or Nook: Does it matter which files they... | My, that's a mighty fat lip you have, grandma. Newer »
This thread is closed to new comments.
I am sure this device has some commercial merit, but I don't know that it will change product development as much as you're describing. [Caveat: my product development experience is with electronic instruments such as oscilloscopes, not hand-held electro-mechanical devices. I do have 25+ years of experience in product development in several different high-tech firms.]
posted by elmay at 9:16 AM on June 6, 2010