DC Motor Controller Design Suggestions... please

James,

This is an EXCELLENT project for an 18-month EE/ME group. It will be plenty hard, but you are NOT starting from scratch, so you can look at the existing design as well as a lot of other souerces of information to get there from here. And we are always here to help. "My dream controller" By Alan Kilian I had a dream last night after reading usenet news I dreampt about a beautiful DC motor controller. Then I woke up. OK, a typical problem that is currently left to the hobbiest to figure out is how do you get the two motors on a "wheelchair" type robot to stay synchronized so that the robot goes straight. There are several examples of how to do this out there, but I don't know of a motor controller that implements them "off the shelf". Just this one feature would make a big improvement in current controllers, so if all the rest of the suggestions turn out to be too hard, and you get this one working, I'd give you an A-grade. Everythig you suggested in your list is great. I'll add/clarify a few that I'd like. 1) Serial port: +5 Volt inverted signalling pads for connecting to a mictocontroller's digital I/O pins. Probably add 33 Ohm series resistors to protect the controller. Also an RS232 driver chip and a DB-9 for plugging directly into a PC. (Or more likely now adays, a USB-2-RS232 convertor. 2) Commands to set the encoder-counter resolution so that you can use "Real" velocity and distance commands. This would be something like .001 Inches of forward travel per encoder count so you make the user figure out the gear ratios and the wheel or track circumference. 3) Self-tuning PID. Really Really great feature if you can pull it off. I have seen exactly ZERO of these in the hobbiest arena. You would be the first I know of to get this working. 4) Some way to record the setpoints and actual values for the P and D values during a move and unload it later. 5) Non-volatile memory for remembering the settings over a power-cycle. (This one is probably not all that important) I'd be likely to pay in the $200 - $300 range for such a device. Good luck, and keep us informed with your progress and questions. Good project.

Good luck on this. As a former member of a classic senior project team disaster, there are a couple things I want to stress.

First, don't get too ambitious. A nice project that is possibly on the second or third revision, accompanied by excellent documentation, will do much better than a project that attempts to do everything in the world and doesn't do any of them very well.

Second, and this is key to the success of the project, plan out a VERY strict system of project management and team member accountability. Progress reports, in a standard format, every two days; weekly team inspections of each portion of the project that is being worked on; sticking to a rigid schedule and requiring a team meeting to discuss any cases a deadline needs to be moved back, because that is the time to closely re-examine the project and see if the goals need to be adjusted. There should also be a way for the team to internally deal with cases where a member is not performing, with an agreed-upon last resort of bringing a team member's performance issues to the attention of the advising faculty member. DO NOT BE FOOLED INTO THINKING THAT BECAUSE THESE GUYS ARE YOUR BUDDIES, THAT EVERYONE WILL WORK AND MAKE THEIR GOALS WITHOUT CLOSE SUPERVISION. Believe me, if you get too absorbed in what you're doing and don't pay attention to what the others are doing, they won't be your buddies anymore when the due date rolls around.

My situation was just that: had a team with a couple of buddies, tackled an ambitious but definitely accomplishable project. I ended up with the tasks of designing a circuit, designing a board, milling and soldering the board, developing USB firmware, developing a Windows C++ USB interface and user control, and developing a Java application to connect to the Windows application over the internet. All with no real previous experience in USB or C++ or Java. I did it, and it worked perfectly. However, the other team member had the task of designing the mechanical portion of the device, which consisted of two motors, four gears and two axes of rotation, as well as the documentation. What I ended up with in my lap, two days before the presentation, was a wobbly and completely non-functioning copy of something that I myself had made a sample rendering of months and months previously, with no consideration to load requirements. It wasn't even their original design. I spent 12 hours cutting it apart and rebuilding it, attaching limit switches, and filing the shoddy Pitsco gears into semi-usability. At this time I realized how stupid I was for getting too absorbed in my tasks, and looked over the documentation...it was dismal, not even slightly different from the version of months earlier, with the exception of the addition of my report on my section of the project.

The professor was understandably not lenient, and the fact that the device worked was probably all that kept me from having to go to school for another year. A senior project can be just as detrimental to your employment chances as it can be beneficial; if a potential employer looks at your transcript they can't help but notice it. In my case I think I learned a lot about how a project team FAILS, and came up with some ways to never have that horrible experience again, but that hasn't helped me land more than a temporary mechanical engineering job as of yet, two years out.

If you're a little bit scared now, good. You realize that yes, it could happen it you, and you'll be able to catch and resolve any problems before they get unsolvable. You'll start with a real plan (which everyone does), and stick to it (which fewer do). Take a good look at the project and try to balance having an interesting project with having a functional one. Ideally, you'll be bored with it by the time you're done, you'll have the final report in its fifth proofreading, and you'll all have time for your interview trips during the last couple months of school.

Or, forget everything I said above, buy one of these:

and hide it in your own box, and relax for 18 months.

I've been thinking about your request since you made it and have a few ideas. I'll post them when I have time to write them up, but for right now one thing comes to mind:

Energy Budget

In your posting, you mentioned a potential design criterion of up to 5A, 40V. I think that as your "market research" progresses, you will find that many practical enthusiast-grade robots need to operate with a lot less in the way of power consumption. Just quickly scanning the spec's for batteries in my DigiKey catalog (which I am using only because it happens to be sitting on my desk), I see that the typical ratings of even a good AA battery is 1.2 amp-hours capacity. Okay, so the double-A is not the last word in batteries. But some "grams per amp-hour" penalty is enforced across all chemistries and it is no fun to work with a robot that can only operate for 15 minutes before it needs a battery change. Of course, a robot that has no "get-up-and-go" isn't much fun either. So it's all a matter of balance. A smart and talented roboticist named Bill Wruehl once summed it up very nicely at a meeting of the Connecticut Robotics Society: "If your robot is too heavy, you need more power so add more batteries. If you add more batteries, your robot is heavier, so you need more power. Repeat."

Of course, just because a circuit board can handle 200 Watts, doesn't necessarily mean that it can't handle 12. It's all a question of in what range it works best. Maybe you could consider a 2-pronged design approach, one option featuring a design highly optimized for efficiency in low-power applications, the other intended for the big bots. Which should you build first? I don't know. While the light-weight market is broader, the people building heavy-weight robots have a lot more money.

Finally, I note that there are some attractive motors rated for 48V (see the Maxon catalog). If you are going to tackle the high-end, maybe you want to push your maximum Voltage rating just a bit higher.

I'd be curious to hear what others on this newsgroup (most of whom are a lot smarter about hardware than I) have to say on the matter.

Gary

Thank you all for your comments and suggestions. It is very comforting to know that we are not alone in this project. My team is currently working on the functional decomposition of our motor controller and I will post a draft list of target specifications (including value ranges for each spec.) as soon as we write them up.

As I have implied before, this project is based around the needs of our customer, you guys. So I was curious to find out your opinion on a few topics that we have been researching.

1) Data Logging: How useful would it be for the controller to connect to a PC in order to log data? 2) Brush vs Brushless: I know the facts about cost and reliability, but I'd like to know some personal thoughts on which you prefer and why. 3) System Power: Do you prefer to power your system with two different supplies for logic and H-bridge, or one supply with a voltage regulator? Would you want our controller to include a regulator capable of outputting 5V to the rest of your system? 4) Feedback: Do you use any type of feedback other than an encoder?

Once again, thank you for your time. We look forward to customizing our current design and eventual final product to your desires.

-James Klein Team Leader/ EE Design Engineer

Hello again,

My team is currently in the process of trimming down our functional requirements for the controller. We have had some discussion on the compatibility of our controller with both brushed and brushless DC motors and we have come to the point where we could really use some input from you guys. We would like to know if brushless compatibility is something that you look for in a controller. We understand the extra connections for the phase inputs to the brushless motors, and we may not proceed with plans to implement those connections unless we here otherwise from you guys. We appreciate any input that you could give on the matter. Thank you.

-James Klein Team Leader / EE Design Engineer

I personally feel that brushless motors do not usually meet the needs of the average robotics hobbyist.

I'll second that.

And you've got PLENTY on your plate for this project.

Stick with DC Brushed motors.

Thanks for the comments. Looks like my team has one less requirement to worry about. Now we can focus more on the self-tuning PID...

-James Klein Team Leader/ EE Design Engineer

Check out the website:

We are now working on debugging/programming our first PCB prototype as shown on the website. Please contact us by e-mail or post if you have any questions or comments on the project.

- James Klein