Well, summer is over and it's time to get back to work. My team has been busy the last few weeks attempting to finalize the selection of components that will comprise the motor controller circuit. Here's some of the pieces that we're considering right now:
Processor: PIC18F2431
Decoder: LS7184
H-Bridge: IR3220S Current Range - 0-6A Max Cont. Current - 6A Voltage Range - 5-45V Regulator: LM2594N Input Range - 7V
This Sounds like a good start , but I would recommend MOSFETS instead of the integrated Hbridge.
4 Mosfets can easily handle the 6 amps and if the user later wants to add a heat sink or fan he can go to 20 or more amps. Cost is about the same.I think the PID could be nicely integrated into the PIC 18f2431 at 20Mhz and if the PIC is fild programmable then the user could change the PID variables.
I think 24 Volts at 20 amps will support better than 95% of Amateur robot needs.
Steve
OC Systems Team wrote:
Have you considered at Atmel AVR microcontroller? They are supported by the free and high quality GNU GCC compiler (C or C++). It can be run from either Windows or Linux.
Do you know about the Open Source Motor Controller projetc?
There is a Yahoo group dedicated to it...
They are, as we speak, working out the details on version 4.0
Jack :)
Thank you for the responses. We will be sure to check into your suggestions.
Since this project is based around the requirements of our customer, and since our customer IS robot hobbyists and enthusiasts, I want to make sure I have the okay from you guys before I go ahead and change something. Two of our specs for the controller are as follows:
Maximum Motor Supply Current: >5A Maximum Motor Supply Voltage: >=48V
The 48V requirement was set due to a suggestion from an early post in this thread:
"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." - G.W. Lucas
It was also mentioned in the same post, however, that most hobbyists would never need that much voltage. Which brings us full circle to a more recent post:
So then, in order to officially change the customer requirements of our project and proceed with prototyping the controller, I would like a few more opinions on the matter.
WOULD YOU LIKE OPTION A, OR OPTION B?
OPTION A - Maximum Motor Supply Current: >5A Maximum Motor Supply Voltage: >=48V
OPTION B - Maximum Motor Supply Current: >=20A Maximum Motor Supply Voltage: >=24V
Thanks again for your time. My team is looking forward to prototyping the "motor controller of your dreams", but we want to make sure we have all the right pieces to work with from the start.
- Jim
Jim,
In my 20-something years of building hobby robots, I have never used, nor have any of my buddies used a motor at more than 24 Volts DC (Except a 190 Volt DC scooter I built. Wheee!!!!) I think you would sell a LOT more with the higher current, lower-Voltage version.
Be sure you understand what you mean by 48 V. For example, if I take four 12 V lead-acid chemistry batteries to make a nominally 48 V supply the voltage can be as high as 72 V (18 V per cell). If you look into this further you will find there are many 'saftey' issues with such a system (sorry, I don't have a good reference to suggest). If you are skeptical about this take a look into telecommunication systems designed to be powered of 48 V lead-acid batteries (as a backup), and thier safety requirements.
So, my advice... stay the heck away from 48 V. A nominally 24 V lead-acid battery supply can be as high as 36 V which is still a 'safe' voltage.
Still not convinced? From a practical point of view, you will have little trouble finding ICs that work in a 36V maximum system, but you will have great difficulty finding components that work in a 72 V maximum system. A good information source with all the technical arguments for the automotive industry transition to 42 V maximum voltage system would be useful background reading.
TC
Here is an additional reference...
I have a vaguememory that the 18V per cell condition may occur when cells are being charged(which in telecom is whenever the AC power grid is ok). But, its only a vague memory.
TC
Thanks again for the responses. It looks like you guys are pretty unanimous about the lower voltage, higher current requirement. This really does help us out because we were spending a whole lot of time trying to find the higher rated power components while still staying within our price range for the end product. Also, since this is our first experience with the motor controller market, staying away from "unsafe" voltages is probably a good idea.
It is our goal to finalize the component selection of the controller by Wednesday of this week. I will post later this week with each component and a bit of reasoning as to why we decided on it. Thanks again for the help.
- Jim
Does anyone have any history with the LS7266R1 encoder to microprocessor interface chip? Specifics on the chip can be found here:
The US Digital website states the following: "The LS7266 has two functionally equivalent halves, the X side and the Y side, selected by a dedicated input pin Xnot/Y (pin 17). Each half is a completely independent counting system."
Can I take that to mean that only one package is needed to decode two seperate motor signals, or will the quality of decoding be decreased at all if I attempt that with this chip?
- Jim
We have finalized the main component selection for the motor controller:
Processor: PIC18F2431 Decoder: LS7266R1 H-Bridge: MC3386DH1 Regulator: LM2575S-5.0
Now that we have our main components pinned down, we'd like your opinion on a smaller detail:
What kind of interface connections would you like to see on your motor controller circuit board?
The motor controller circuit board will need some sort of external connection for the following signals:
Battery (PWR, GND) Motor 1 Decoder (PhaseA, PhaseB) Motor 2 Decoder (PhaseA, PhaseB) Motor 1 PWM (PWR, GND) Motor 2 PWM (PWR, GND)
So there will be a total of ten external connections. The previous design of the controller circuit utilized male clip connections on the circuit board with female connectors from the battery and motor signals. We want to make sure that our design is as functional and adaptable as possible. Basically, we don't want to put a certain type of male connector on our board if you guys don't usually use the required type of female connector. Should we just leave empty pads on the board for your own installation? Or would a wire clamp connector be a good idea?
We really want to make this board as pleasing to you guys as possible, so please let us know what you would like.
- Jim
I would like to explain why my team decided to go with the MC33186DH1 h-bridge instead of the MOSFETS as recommended. The main factor in this decision was the overall safety features of the h-bridge chips compared to the MOSFETS. Since this is our first motor controller design, we decided that it would be better to go ahead and prototype with the MC33186DH1. However, we will definitely keep the MOSFETS in mind for future implementation as the project progresses.
- Jim
The chip is designed for two quadrature encoders, but in all cases (regardless of the decoder chip) the usual precautions against FRI and power supply noise applies.
-- Gord> Can I take that to mean that only one package is needed to decode two
Actually, there's been a bit of a change in the final design. Due to some last minute ideas, the LS7266R1 decoder chip was tossed out of the design and replaced by a second PIC18F2431. Since each PIC possesses a single quadrature encoder interface (QEI) we will use dual-processing in order to perform accurate, synchronous motor functions. So the new concept looks like this now.
Processor: PIC18F2431 Decoder: PIC18F2431 H-Bridge: MC3386DH1 Regulator: LM2575S-5.0v
So now we have a new question for you:
What type of microprocesor interface do you prefer to use in your systems?
We will most likely use the SPI function of the PIC processors to communicate internally, but we will also have external processor connections in order to program and accept instructions from an external processor (i.e. your processor). Some of the more common interface types that we have run across during our research is I2C and USART.
This week my team will begin to build our first prototype. We are very excited to finally begin working hands on with our project, and we appreciate the continued feedback that you have provided for us.
- Jim
Since you are already using a PIC18F2431 for the processor, what is the need for the second decoder PIC?
Randy Haas
The project that we are working on is a dual-motor controller. Since their is only one QEI per PIC, we need two PICs to perform the dual-motor functions that we are aiming to achieve.
- Jim
And here is yet one more recent reference. This one is about the 42 V systems for cars, with some specific statements about the challenges that
42V systems present for electrical components. It also has some specific statements re: safety issues.Even if you aren't interested in 42V battery systems I would still recommend checking out the website. Many intitiatives in cars have direct connection to robotics and this is a tech oriented site.
link to the site....
Jim,
A google search on MC3386DH1 turns up nothing. Can you post a link to some info about your H-Bridge selection?
--Steve
I apologize for the confusion. There was a little typo when I entered the part number. It should be MC33186. Here is a link for the data sheet, though, so I don't take up any more of your time unnecessarily:
- Jim
I have started a very rough webpage documenting the progress of my team and further detailing the background behind our project. I will continue to add more information to the site in the next few days, and then I will update it as we progress through the project.
Basically, I wanted to give you guys a better idea of what we're trying to accomplish and emphasize the fact that we really appreciate all the feedback that we have received from this group.
- Jim
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.