Micro Dual Serial Motor Controller

this is sooo wierd
i have the uDSMC and i wired it perfectly, i am positive there are no wiring problems

i started by putting in config code:
serout P0, N9600, [$80, 0, 1]
this is for two motor use and the use of motors 0 and 1

then i put in this code after switching the power to my circuit off and on (to reset the uDSMC)
serout P0, N9600, [$80, 0, 3, 127]
i have also tried replacing the three with 0, 1, and 4

all of these give the same results:
one of the motors will give a pulse of movement for about half a second and it will do this every 3 seconds or so

i am using a basic ATOM

please help, i need a quick reply as i have a deadline

Uh oh, when’s your deadline?

It sounds like you’re sending proper commands, but your motors may be trying to draw too much current, overheating the H-bridge chip, and activating it’s thermal shutdown protection. The chip would cool off for a little bit, then start trying to drive the motor and overheat again, producing a pulsing behavior like what you’re seeing.

What kind of motors are you using, and what is the voltage of your power source? Can you measure how much current your motors draw through an amp-meter when you connect them straight to your power source? The H-bridge on the uDSMC can only handle one amp per motor. Alternatively is the H-bridge chip (the larger of the two chips on the uDSMC) getting very hot to the touch when the motor moves?

If you’re only drawing a little too much current you could try putting a heat sink of some sort on the chip, switching to a lower-voltage power source, and even commanding the motors to run only at slower speeds. If the H-bridge is overheating in half a second with no load on the motors though you’ll probably be way over the safe current when you try to actually do work with the motors. The only solutions there are using less powerful motors, or just switching to a higher power motor controller (or multiple uDSMC motor controllers, each driving one motor in single-motor mode).

Just to clear this up, unless you need to use multiple motor controllers on the same serial line, you don’t need to use the configuration command. The only reason to use the configuration command is to change the motor numbers on individual controllers so you can have multiple controllers on one serial line. That way, even though they’re all listening to all the commands, they only respond to commands sent to their individual motor numbers. And if you do need to change the configuration, you only need to do it once. Even when power is disconnected, configuration is saved permanently. If and when Pololu revises their motor controller manuals I’m sure the first thing they’ll do is change the “Configuring the Motor Controller” section to say at the top in big letters “you almost definitely don’t need to do this, and if you really do, you only need to do it once”.

If you did need to change the motor numbers you would send the serial string [$80, 2, n], where n is the motor number command. You wrote [$80, 0, 1], did you send that, or [$80, 2, 1]?

It doesn’t really matter if you did change the configuration or not, motor numbers 0 and 1 are universal to the Pololu motor controllers. No matter how you configure the uDSMC, in two-motor mode all motor controllers will always accept commands sent to motors 0 and 1, in addition to whatever the programmed motor numbers are. Whatever motor numbers the controller is configured to respond to (in two-motor mode), it should be responding to these commands, where s is the speed from 0 to 127:

[$80, 0, 0, s]=motor 0 reverse
[$80, 0, 1, s]=motor 0 forward
[$80, 0, 2, s]=motor 1 reverse
[$80, 0, 3, s]=motor 1 forward

-Adam

wait sorry i think i did use the 2 in config rather than the 0 i said i did

as for current i am using motors the size of M&M’s (GM15 from solarbotics) which draw very tiny amperage
i’m using a 9V source regulated to 5V (the motors are getting 5V), i have measured with a DMM

i think i might have a broken chip?

oh yea, im a thirteen year old author for SERVO magazine, im making a mini robot project andeverything has gone fine until now, i posted here becase i think my chip might be broken, the behaviour seems a bit to erratic to be code issues

the deadline if i want the articles to be in for August is June 16th i can go later but i’d rather not

and by the feel of the chip it is definitly not cooling down, unless when i was soldering the heat somehow melted an internal transistor or somthing, that seems plausible

*sorry about all these posts

it seems when i turn on power after uploading code, nothing happens, then i unplug my I/O line and it does what it’s supposed to do for about 3 seconds, then gives me this pulsing thing

Sounds very cool! I love those little planetary motors, and motor controllers don’t get much smaller than the uDSMC. Anyway it should be more than powerful enough to drive two of them.

I doubt you have a bad chip, Pololu tests everything before they ship. It is possible to mess up the chips by misusing them (I’ve destroyed two so far by accidentally shorting the outputs) but in those cases they just stop working all together, I’ve never heard of behavior like that from a broken chip.

You might be having power noise issues from the motors, especially since you’re putting both the motors and the controller on the same side of one regulator. A good way to test for this is to replace the motors with LEDs and resistors. If you try to power them in the right direction you should see the LED light up, but it won’t draw much current or generate any noisy interference. If you see the LED start blinking like the motor was pulsing though, I’m stumped!

Do you have capacitors on the motors and/or the voltage regulators? Also, you might try driving the motors with a 6V power source, and running the controller with a low-dropout regulator. Come to think of it, What kind of regulator are you using, and are you sure it can supply like about an amp to drive both motors to stall? I could see you getting some weird behavior as the regulated voltage drops low under the strain of the motors.

-Adam

Well here is my exact set up,
I have a 9V Battery Pack fully charged giving me a full 9V, its connect through a power switch to a Lynxmotion Basic ATOM Bot Board (i beleive that contains regulated voltage). I am using the 5V output and Ground to connect to the motor controller logic supply and motor supply, both grounds are tied

the reset pin is attached to the 5V so it is permanently high

although you’re right this behaviour seems a little erratic for any problem, ill try the LED thing tommorow

Yeah, I bet it’s a current/noise problem then. The Bot-Board II’s voltage regulator can source 250 mA (more than the Atom’s on-board regulator for sure, though I can’t seem to find specs on that). At 5V and no load a single GM15 nominally draws 195 mA. The Atom shouldn’t be drawing too much current, which is why it works at all, but that close to the total available current from the regulator the motor noise effects are going to do nasty things.

You wouldn’t be able to drive the two motors from that regulator in any case, so you should think about a separate dedicated regulator for the motors, or a separate lower-voltage power source.

Good luck with your robot, let us know if you keep having trouble, and of course when you submit your article!

-Adam

P.S. Oh, and I thought you might appreciate this working with such small parts. My crazy (in a good way) friend Justin in the picture below mounted 0-80 brass screws to GM15 motors to make 28 tiny linear actuators for a robot we were working on.

If only it were in better focus, but it’s still a great picture.

that is an amazing 'bot

thanks for your support, I’ll be sure to mention you in my article

wow current problems, i never thought of that, if it was to do with circuitry i would have thought ESD

my first article for SERVO which is on my FIRST Tech Challenge team will be in the next issue (June 2008) and im hoping my mini robot article series (about 3 or 4 parts) will start in august

BTW for kicks, if you have a company you know interested in sponsoring my team…please ask! my team address is team.theroboticsuniverse.com and I have a few sponsors so far but I’m not quite there. LOL

well until i can pick up some regulators to tinker with i have tried the following:
attach an LED -> does not light up, motors still pulse
instead of using the ATOM’s power output i used the main power (6 AA Cells) -> nothing, motors still pulse

i will continue to tinker with this but this is still very wierd

Aah, I meant put an LED and resistor in place of the motors, you need to remove the motors all together for the test to work. It’s odd that the motors would still pulse when you have the motor power supplied separately straight from the batteries though, that would seem to invalidate my current limit theory.

When you said you see this behavior after you unplug your I/O line, you mean this happens when you’ve removed the wire between your Basic Atom’s serial output and pin4 on the uDSMC? That’s very odd indeed. Would you mind posting your complete basic code? Specifically I’m curious if you’re sending the serial command just once, or over and over again rapidly.

-Adam

Also, come to think of it, I know you said you’re resetting the motor controller after sending the configuration command, not that you should be sending a configuration command at all, but the behavior you’re describing is exactly what you would see if you had just sent the configuration command with motor number 2: [$80, 2, 2]

Specifically pin 9 would pulse high with exactly the sort of pattern you’re describing, while the other three output pins stayed low. Is there any possibility that you’re sending these bytes? I’m still interested in looking at your code.

-Adam

P.S. Even if this is the problem, you still shouldn’t plan on running your motors off of your microcontroller’s regulator!

i will get my exact code here tomorrow, i might be using the #2 where i shouldnt, i dont think so

i am only sending the motor code once (not the config)

i am getting a second chip soon , i will not try the config line on that, ill go straight to the motor code line…if that works than your theory will be confirmed

if this is not a software problem i have no doubt it is ESD or heat from a soldering iron (as you might know that is a tough soldering job…the spacing is off…i burned myself :smiley: )

for the sake of it, do you know what the factory default config is (in the state of a line of code)? because ill put in that line of code and reset then try it, ill desolder the motors and add the LED’s and see what happens, im also gonna pick up a couple regulators when i get the chance

thanks,
-andy

p.s. if you subscribe to SERVO make sure to read my June article :smiley: it’s not on mini robots though, if you dont PM me and i might be able to get an extra copy out to you

The default configuration is two-motor mode with motor numbers 2 and 3, but no matter how it’s been set it should at least respond to commands sent to motor 0, and to motor 1 if it’s still in two motor mode.

-Adam

And no, I’ve read a couple of issues of Servo but I don’t have a subscription. How did you end up writing for them?

well ive always been good at writing and I started a FIRST Tech Challenge team, FIRST inspired me and i decided to write an article about my experience…they accepted it and now here I am writing more :smiley:

ok, i have got my new motor controller in the mail…i want to make sure im sending the exact right commands, no config this time…no ESD chance…the motor controller is going straight from bag to the anti-static mat

i assume to run motor one and two run sometihng like this:
to make motor 1 spin forward:
serout P0, N9600, [$80, 0, 1, 127]

is this correct…i want to make sure

thanks,
-andy

I’m not really familiar with Atom Basic, but assuming everything else is set up properly, [$80,0,1,127] is the correct set of serial bytes to make motor 0 (the motor between pins 8 and 9) spin ‘forward’ at full speed.

-Adam

Thanks a lot. The BasicATOM has the exact same code except for the N9600 I believe that is something different in the Stamp