Let's Make Robots!

Arduino Uno + Dagu 4 channel motor controller - power issues?

I have an Uno controlling a 4 channel Dagu motor controller with encoder support. Got this a month ago. (It's the red PCB version).

Although it works, I have read that I shall not power the motors before powering the control logic.

But does that really mean that if the controller voltage dies out in the field, and there's still juice in the motor batteries, the Dagu controller will burn ?

I saw OddBot said this might be the case, at least if you powered it up in the wrong order.

I have asked around on other forums and people seems to think this would be a rather dangerous design :D

People suggest that if this is truly the case, I could hook  up some kind of transistor circuitry to make sure motor power is cut if controller power is cut. At the moment, this is a bit above my electronics skills.

Can anyone confirm or deny that the Dagu board will burn if the controller logic voltage dies while the motor still has voltage ? (AFTER it has been powered up properly :)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I guess this is the kind of setup i have to go for, along with a SPST switch.

http://www.tpub.com/neets/book1/chapter3/1-36.htm

I used this calculator to roughly estimate what i need:

http://www.rapidtables.com/calc/electric/Voltage_Divider_Calculator.htm

For 3 outputs,_roughly_ yielding  9, 5 and 3 volts, i used 18 volts, with 4400, 7800 and 2800 ohms. I have to work on this though, to get it more exact.

I use 2 ATmega328's on my hexapod, one controls 12 servos, the other does wireless communications (nRF24L01) and has an ultrasonic sensor, servo and IR temperature sensor that controls a fan through a mosfet connected to it. It was impossible to use I2C or software serial to communicate between the 2 ATmega's. The servos would twitch constantly. I had to resort to hardware serial to communicate between the 2 ATmega's. The reason is that the I2C (wire.h) and software serial library use the same timer as the servo library.

I will look into this! Thanks.

Ok,

Don't let the electronics get you down. For the purposes of the current setup, there's not that much you really need to be worried about.

First - connect the grounds of all your batteries. Voltage is just a potential difference between two points. Think about standing on a basketball court with a tape measure and asking "How high is the ring?" You'd get an answer. Then consider someone standing on a ladder and carrying out the same exercise. There'd be a different answer. Their points of reference are not the same. You need to have a a common point of reference for all the components, (which is why 0V is called various things - "ground", "earth", "common"  and so on.)

Better still, as OddBot has said, just use one power source. I'd hesitate to recommend a Lipo at this stage. You need to use the correct type of charger and a good high capacity Lipo is capable of delivering very high current. I've been using them in RC aircraft for years and I still treat them with the utmost respect.

Good quality NiMH cells are more user-friendly. A fully charged NiMH supplies about 1.4-1.45 V with a light load. 6 of them will be somewhere around 8.4V which is ideal for all your sensor's and the Rover's requirements. Under load, they'll probably drop to around 1.2V each which is still fine. Forget about alkalines, smoke detector batteries and the like. If you ask them to supply any useful amount of current, they'll sag under the load.

A good voltage regulator is handy to reduce your 8V+ down to 5V and for some sensors, 3.3V. If you feel ambitious enough to get into a bit of soldering, OddBot has an excellent tutorial on this site which shows how you can build one for a few dollars.

As for your servos, there are a few reasons why they might be acting "a little weird". I'm not sure how you're connecting them or what kind they are but an Arduino can't really drive that many servos straight from the board. The voltage regulator mentioned above can supply the power for the servos in this scenario. The Spider controller is a better choice for lots of servos.

Most servos use a potentiometer to control the position of the servo arm. If it gets dirty or corroded, then you'll get erratic behaviour. Sometimes on planes, we can get them working by giving them a good workout, ie move the stick on the transmitter rapidly over the full range of movement. Other times you need to  pull them apart and clean them. While I'm at it, be careful about physically moving the servo arm with your fingers. Cheap servos often don't like this and will strip the gears. Always move a servo electrically if it's a cheap one.

Another reason for servo strangeness could be the way the Arduino library controls servos. I'm not sure if you're using the Arduino libraries? I don't personally but that's another story. Atmegas have hardware to generate PWM which could control a servo but there are only a few PWM-capable pins on a Uno and somewhat more on a 1280 or 2560 but still not enough for something like a hexapod. So the Arduino library uses a timer for each bank of 12 servos and manually adjusts the timer countdown rate and toggles the pins in software. The Atmel datasheet suggests that this method might load up the CPU (but there's not a lot of choice if you want to drive lots of servos). I haven't experienced this but it stands to reason that if you've got lots of other code happening, then the servo code occasionally might not get a sufficient time slice to perform. I guess this scenario is unlikely but you'd probably see the servo "twitch" now and again if this happened.

Did you say that you have a Uno and a Mega talking to each other through the serial lines? That's good stuff, if so.

 

I should also mention that the IRremote.h library uses interrupts. Maybe these are interferring with the servos.

Actually, I had to remove Tone.cpp (a tone generation library) from /arduino/cores to make IRremote.h work because they had conflicts with function names related to interrutps.

I am also using SoftTimer.h, but this does not use interrupts, AFAIK.

Yeah the servo is twitching sometimes ! You might be on to something!

Also when i power up the Uno, the servos move just a little bit. I saw another guy have this issue, that thread ended up in no specific solution AFAIK. (but many good suggestions and was a good read)

Ah, one of the servos are on a non PWM line actually. And actually i did twist the servos manually a few times to find the center position. (this was the DFrobot Pan/Tilt Kit)

And yes, the Uno and Mega are talking. :)

I could probably run the entire project just on the Mega, but I just thought it was cool ut utilize both of them.

The idea is that the Uno runs an IR eye and a sonar as well as the Rover, and and tells the Mega about what the sensors see. It also runs two servos.

Then the Mega is running the rest of the show, with a small OS I am working on, controlled by 4 pushbuttons and an old Panasonic TV remote trough an IR reciever (LTR301). It shows the user whats happening on an 128x64 LCD. It has other sensors and stuff connected to it. It makes the actual decisions. (so for example the Uno says 'hey the sonar says we are 50mm away from an obstacle what to do?! then the Mega says back 'well stop the Rover for a second and lets probe the environment!')

I am using Arduino 1.0.3's servo library as well as IRremote.h by some guy i dont remember just the name of just now.

Maybe i am straining the Uno a bit too much, EVERY analog, digital and power pins is occupied and in use!

I also have the DFrobot IO Expansion Shield v5 that can be used for servos, but at the moment i am wondering how to use this shield with sensors as well.(do i get the power from the analog or digital block's power lines or does this not work at all!) This shield also accepts separate power inputs :)

It's going to be a unholy mess to supply power to all these units and connect their grounds as well :) I'm up to 6 batteries now, if i am to use this shield too :)

Just for the ease of managing one battery, I am tempted to run with a LiPo NiMh and dive into more theory (voltage regulators and so on). Thanks for that tip.

I understand a whole lot more now than when i got the Uno with my SIK 3-4 months ago :)

So far, the only accident I've had was to power the tmp36 sensor the wrong way, and that smoked a wire lol.

Edit: I will also work on getting the grounds connected together. I kind of understand why, but what bothers me is why does the reference points matter if all that is connected together are analog and digital signal pins ? For example, the Uno and the Mega are connected ONLY trough Rx/Tx, Aren't these signals already filtered and regulated to match, or am I actually expanding the whole circuit by having two boards connected this way with each their own battery?

Edit 2:
And by the same token, i fail to understand why the battery for the sonar should be connected to the ground of the Uno, when all that is actually connected between them is one analog and one digital signal. 

Edit 3:
And also with the Rover batteries connected to the Dagu board. Because what i am thinking is if i connect the grounds of 4 batteries (3 9v ones and one 5 volt one), the 9v batteries are going to fry the 5v battery, or this difference is going to fry other components ? Thats just my naive intuition saying this though!

Edited: LiPo->NiMh

Hi Kirk,

I'm using a Spider controller instead of a Uno, the Dagu 4ch motor controller and a 4WD Rover 5. It's all powered (as OddBot suggested) by a single 2S 30C 3500mAh Lipo. The Lipo connects through good quality 4mm bullet connectors (same as I use in my RC aircraft which handle more than 70A). From here the supply goes to three places:-

1. Through an SPST switch to the Spider input connectors.

2. Through a second high-current automotive switch and then via the largest wires I can physically fit into the motor port on the 4ch controller.

3. Through the same switch in 1. to a Pololu 5v switch-mode regulated power supply and from there to the 4ch logic port.

I have a LED indicator on the input to the 4ch logic to verify that voltage is present.

It's probably a bit of over-kill but the large switch allows me to verify that I have power on the 4ch logic before I power up the motors. The smaller switch is only present because the switch mode regulator is a bit sensitive to input noise on power up and plugging in a bullet connector is remarkably noisy.

Just by the way, a fully charged 2S Lipo is 8.4V which is more than the 7.2V specified for the motors but I don't ever run them at full speed. I also don't ever charge the Lipo to 100% (more like 8V) since the Rover doesn't draw enough current to discharge the battery significantly. Lipos don't like being stored at much more than 60% charge so I'd have to discharge it one of my planes (or something) after I'd finished playing with the Rover. (By contrast, most of my planes would run a full Lipo down to 20% in 8-10 minutes).

If my explanation doesn't make sense, please ask and I'll try to clarify.

:)

Okay, hehe. I'm in a little over my head here then :)
I've been lucky so far i guess :D I have next to no experience with electronics. From my PC building experiences and petty attempts at repairing cars, I pretty much knew only this:

1. Connect ground to ground first, and those are black.
2. Power comes from the red wires, and shall be connected last.
3. Do not short this connection.
4. Cicuitry is some magic that happens within a magical land where the wires are connected to, and makes it not short.
5. Communication and stuff happens on the other wires.
6. Oh yeah, and  the circuitry stuff has resistors that restricts power and has color codes.
7. Capacitors may hold a charge even if they are not connected to anything and they are also magic.

:)

I've since read up a bit, but I have some way to go with stuff like types of switches, relays and voltage dividers.

One of the things I wonder is if one should connect all ground cables in a system with multiple power sources.

For example, when I researched on how to set up an LV EZ1 sonar, I had to let the sonar have it's own 5v battery to procuce reliable results.  The guy on that forum did not say wether he had the grounds connected. This 'works' and the grounds from the Arduino's breadboard and the separate battery for the sonar are not connected

So I am really playing russian roulette here by having three 9v batteries and the one 5v battery in this system by not wiring together all these grounds ?

1. Arduino Uno on 9v barrel jack

2. The Mega s 9v battery trough barrel jack also. I havent mentioned this one yet, it's hooked up with the Uno trough Rx/Tx and are not connected trough their battery grounds either. 

3. The 4WD Rover5's 9v battery trough the Dagu controller that are wired to the Uno trough the digital pins. The Uno's 5v rail drives the Dagu controllers logic port trough a breadboard rail.

4. The sonar's battery that are connected to the sonar trough a breadboard rail and to the Uno trough one analog and one digital pin.

Am I straining parts here now since these grounds are not connected ?

'awaits answer in a paranoid kind of way emoticon'

Thanks for the answer, gives me something to learn. I'm reading up on SPST switches now :)
Thankfully, I'm used to googling stuff for myself since I work with programming mostly, but sometimes i wish i had some electronics classes with by programming degree  :D

regards, Kirk

And also theres a bunch of other peripherals hooked up to the Mega and the Uno trough their breadboards power. (LEDS, sensors, servos, LCD, etc.)

Everything seems work and I'm currently just polishing the sofware (possibly oblivious to impending disaster), but the question about the ground connections in a system with multiple power sources advice I read, as well as 'do not power the motor before the controller' advice i read :D

I should perhaps mention that my servos are behaving a little weird, but otherwise, it's smooth.

kirk