Advice to monitor HB25 current draw
ptiago
Posts: 37
Hello everyone,
Today doing my first Arlo bot test drive (lab and on blocks do not count), i blow up a 5A fuse from the Arlo Power Distribution Board. I was careful, but i did a few tests, payload test (my 2 1/2 kid was sit in the bot) and some driving maneuvers led the bot against some walls.
To avoid blowing more fuses, I would like to monitor the current draw for each motor, and stop before reaching an abnormal value.
Breaking down these are the points i would like advise:
1) On the HB25 has a 25A fuse, the power distribution board has a 5A, this is huge gap, although the HB25 power in and motor output is the same voltage (+- 12V). I'm assuming the HB25 fuse protects the motor side and the value is higher to support more powerful motors is this correct ?
2) Should i put the current sensor between the power and the HB25 or between the HB25 and the motor ? The last option makes more sense to me.
3) The Arlo motor Kit Aluminium's page mentions the following info: "Current requirements: 2.5 - 8.0+ amps (depending on terrain and load)", the question is if the motor pulls more than 5A, the Power distribution fuse will blow up ? If this is correct the limit must be less than 5A, and not more at least for this arlo kit combo (Power+HB25+motor) ?
4) There are a few boards with allegro circuits (ACS7xx) , besides the rates i need to choose between unidirectional vs bidirectional current. I'm not sure but, i need a bidirectional current if i'm interfacing before the motor (because the output changes if is driving forward or backward), if i'm interfacing before the HB25, i could go with the unidirectional input.
5) I found two boards using the same chip ACS714, both bidirectional but different ranges (-30A to 30A, -5A to 5A), if i need to have the 5A limit constrain, does not make sense to go with the 30A, otherwise i'll have less resolution (ADC), but the question is if the circuit will blow up if has more than 5A or is just a question of reaching the limit sensor output value.
6) I need to replace the mini low profile fuses, besides mouser and digikey anyone knows an alternative supplier (brick & mortar).
All feedback will be appreciated.
Tiago
Today doing my first Arlo bot test drive (lab and on blocks do not count), i blow up a 5A fuse from the Arlo Power Distribution Board. I was careful, but i did a few tests, payload test (my 2 1/2 kid was sit in the bot) and some driving maneuvers led the bot against some walls.
To avoid blowing more fuses, I would like to monitor the current draw for each motor, and stop before reaching an abnormal value.
Breaking down these are the points i would like advise:
1) On the HB25 has a 25A fuse, the power distribution board has a 5A, this is huge gap, although the HB25 power in and motor output is the same voltage (+- 12V). I'm assuming the HB25 fuse protects the motor side and the value is higher to support more powerful motors is this correct ?
2) Should i put the current sensor between the power and the HB25 or between the HB25 and the motor ? The last option makes more sense to me.
3) The Arlo motor Kit Aluminium's page mentions the following info: "Current requirements: 2.5 - 8.0+ amps (depending on terrain and load)", the question is if the motor pulls more than 5A, the Power distribution fuse will blow up ? If this is correct the limit must be less than 5A, and not more at least for this arlo kit combo (Power+HB25+motor) ?
4) There are a few boards with allegro circuits (ACS7xx) , besides the rates i need to choose between unidirectional vs bidirectional current. I'm not sure but, i need a bidirectional current if i'm interfacing before the motor (because the output changes if is driving forward or backward), if i'm interfacing before the HB25, i could go with the unidirectional input.
5) I found two boards using the same chip ACS714, both bidirectional but different ranges (-30A to 30A, -5A to 5A), if i need to have the 5A limit constrain, does not make sense to go with the 30A, otherwise i'll have less resolution (ADC), but the question is if the circuit will blow up if has more than 5A or is just a question of reaching the limit sensor output value.
6) I need to replace the mini low profile fuses, besides mouser and digikey anyone knows an alternative supplier (brick & mortar).
All feedback will be appreciated.
Tiago
Comments
But, because you're feeding the motor controller with a very limited supply, you want to monitor the current through the 5 A fuse. This can be done with a small-value resistor in series, but does require attention to make sure the a/d input is differential to account for the fact the sensing resistor is at a voltage much higher than 0v.
Without complicating the issue, the sensing resistor could also be placed in the negative lead returning to the battery. Using a sense resistor of 0.3 ohms ( 3 - 1 ohm in parallel) would give the a/d a nice voltage from 0 to say 1.5 volts, regardless of motor direction.
You could also invest in one of the isolated current sensing devices ( see HASS_200-S) so all you have to do is put the fuse wire through the sensor and the 0-5 volt signal is isolated from it.
Cheers,
Just a couple points that might help...
1. The fuseholder Parallax used on the Arlo Power Distribution board will take 3 fuse sizes that I have tried. One is the funky mini fuse they supply, but you can also use standard automotive blade fuses (both mini and maxi size) usually available from filling stations, car parts shops, large supermarkets. Likely will work with the ATO (regular) fuses too.
http://en.wikipedia.org/wiki/Fuse_%28automotive%29
2. The power traces on the arlo distribution board are more than capable of handling 20A, so you could replace the fuses for higher values as you suppose. I suspect when the decision was made about the fuse sizes shipped by Parallax, they were targetting older/smaller motors.
As an extra... you could get the Parallax current sensor board (#29130) and replace the sense resistor with, say 0.01 or even 0.001 ohms. Then you could use that nice little breakout board to monitor current up to 30A, and likely beyond. I thnik the parallax product page mentions some options about the resistor.
Hope that helps! Have great fun with your Arlo !!
I've been monitoring the current on my robot with a gizmo from HobbyKing. I'll find a link and add it to this thread sometime soon. There are several other options to monitoring current draw which haven't been mentioned yet. I'll try to find links to some of these other solutions.
I personally don't think it''s necessary to monitor the current. I think 10A fuses would very rarely blow and if you just keep a couple extra fuses on hand, you shouldn't need to worry about the current.
Besides the problem with too low of current values on the motor fuses, I think the APD also has an issue with pulling current from the USB when a Propeller Activity Board (PAB) is connected to both a PC (via USB) and the APD. As I mention in this post, the 6.5V regulator draws current from the PAB's power connection.
I added a switch between the APD and the PAB on my robot. The switch disconnects the positive line but leaves the ground line connected. When using the PAB without the USB connected, I turn on this extra switch and keep the switch turned off when the PAB is connected to the PC.
What program are you using to control the Arlo? If you haven't done so already, I hope you try out the Eddie firmware which has been modified to work with the Arlo hardware. I think the demo video in post #41 looks pretty good. I still hope to smooth out the stops a bit but I think the code works pretty well in its current state.
The firmware for use with the ActivityBoard and HB-25 motor controllers is available as a zipped archive titled "EddieActivityBoard - Archive . . ." and is available from my GitHub account. There are some instructions in post #38 on how to test the firmware without having the PAB connected to a PC. There's also instructions on how to switch from hexadecimal input/output to decimal input/output.
If you decide to use the Arlo without a PC, you can check out my "Cleaver" repository. The "Cleaver" code currently uses a wireless Wii Nunchuck as a remote control device. Right now my robot can either be controlled with the Nunchuck or it can play through of a script of commands. I plan to make my robot autonomous and able to avoid obstacles but I haven't gotten this far yet.
You should also take a look at NikosG's "The Artist" robot.
One advantage the Eddie firmware has over the modified ActivityBot firmware is the Eddie firmware uses both channels of the quadrature encoders. Using both channels of the encoders provides twice as many transitions as when monitoring a single channel. While this should theoretically improve the performance of the robot, I think it's safe to say the precision available with a single encoder channel is still pretty darn good.
http://www.hobbyking.com/hobbyking/store/__10080__Turnigy_130A_Watt_Meter_and_Power_Analyzer.html
I also like these:
http://www.hobbyking.com/hobbyking/store/__17864__In_Line_Voltage_and_Amperage_Meter.html
Of course either of these sensors requires the user to monitor the displayed current. Using a current sensing solution which the Propeller could monitor would also be nice but these current sensors which display the readings are (IMO) easier to use to use than machine readable sensors.
Thanks for the feedback.
@Stamptrol: the resistor idea, seems cheap and easy, and the heat dissipation resistor is not dangerous for high currents ? Regarding the HASS 200-S/50-S do you know if it works with motors (reversing polarity), can you point some example using those circuits, how efficient they are (magnetic noise, fluctuations etc)
@Maxwin: Fuse size, that is good to know, i'll buy a combo of MINI fuses. The #29130 device, i remember reading somewhere some warnings in using that with high currents > 3.5A, anyone knows if is safe to use to measure 5A to 20A and what kind of resistor it's needed ?
@All: no one made comments regarding the ACS7xx (hall effect ICs)
@Duane:
1) Those gadgets seem nice how, you are they connected e.g. serial connection, high side ? The second one seems to be resistor sensing.
2) Wow a lot of projects, to be honest i'm not a fan of SPIN, I'm a C supporter and all derivatives: c++, obj-c, java, c# etc.
3) What program i'm using to control arlo ?
I do want to make you read a lot, short version:
i'm using Arduino and an ARM embedded device with linux+ROS. More or less the same path as Chris. I started first with activity board, and i got demotivated with the Arlo drive C code, and other issues i run into it, e.g. lack of support of 4x decoder, low resolution ticks per revolution (i.e. 144) is still low if you want to implement a PID Controller. I switch to Arduino but i didn't give up on the propeller, i have plans to come back to it later. I can't work with the Arlo drive C code, it's little mess, also seems is not being upgraded.
Tiago
I've not seen those warnings, so cannot comment.
However, the resistor size (footprint) on that current sensor pcb is 2512... so just grab anything that size in 0.01 ohm, which will enable you to measure the current range you seek. You might also consider 0.001 ohm, which will reduce the measurement accuracy a bit, but would also reduce potential heat issues cause by large currents across the current sense resistor (that may not even be an issue on the 0.01ohm 2W part- I leave the power calculation for you!)
example parts:
0.01 ohm: 985-1553-2-ND
0.001 ohm: 985-1556-2-ND
A quick glance at the current sense board shows rather thin traces from the 6pin header vin/vout pins to the sense resistor... maybe that was the warning. Definitely use only the 2pin screw terminal to connect the vin/vout in this application. Those are duplicated pins to the 6pin header - only use those header-pins for monitoring much lower currents.
Hope that helps a bit. With one resistor change, this does appear a simple way to add voltage and current feedback to your project!
I haven't used these sensors yet myself. I have this one from Pololu I plan to try and I've read the datasheet on the sensors.
You shouldn't need the bidirectional sensor since you can measure the current going into the HB-25 or before a h-bridge (if using a h-bridge).
I think the sensor can be damaged from too high of currents but I doubt it will blow up very easily. It has a "FAULT" output which latches when the current exceeds the sensor's rated value so I think it's safe to assume the sensor can withstand some over current conditions.
I'm using it between the battery and APD board. Since both sides of the battery are connected to the sensor, I don't know if it's reading the current on the high end or the low end. My guess is it's monitoring the low side.
The second one must be sensing on the low side since the red wires are soldered to the same pad on the PCB. The negative side passes through the metal wire on the front of the board (a shunt?).
While it's not a very practical way to add a machine readable sensor, I have soldered wires to the back side of the PCB and used a '165 shift register to read the segments on the display. As I said, it's not a practical way to add a machine readable current sensor, but it was something I had wanted to try for a long time. (I didn't take a picture of the current meter with '165).
I used to think 144 transitions per revolution was not enough to allow precise control of the motors but now I'm inclined to think 144 transitions are plenty. I recently changed the control algorithm of my experimental version of the Eddie firmware to compute speed based on the time between encoder ticks rather than counting transitions over a given period of time.
By computing the speed based on time between ticks, the speed can be updated as frequently as 50 times a second (I'm not sure what the fastest update frequency is). The previous version of the firmware monitored the number of encoder ticks over a period of 0.5 second. The 2Hz speed detection (which was updated at 50Hz but used values from the previous half second to compute speed) was fine for most speed settings but the half second lag causes issues when the robot stops. I'm hoping by reducing the lag when computing speed, the robot will have better control at low speeds and will be able to roll to a very precise stop.
Even without this new way of monitoring speed, I thought the Eddie firmware did a good job with position control. The video attached to post #41 of the OPP#8 thread shows the robot traveling a two meter by one meter rectangle ending with a couple of figure 8's. IMO, the movement of the robot looks pretty good. As mentioned, the speed control as it stops could/will be improved. As the code works now, the wheels wobble a little at the end of a maneuver as the motors align the wheels to the exact encoder tick desired. I'm hopeful my new method of monitoring speed will allow me to remove most (hopefully all) of this wobble.
Apparently the present C code for Arlo is an adapted version of the ActivityBot code. I personally will be very surprised if the code isn't upgraded soon (I may do this myself). Even with a single encoder channel, I think the C firmware controls the motors pretty darn well (I'm afraid better than the Spin/PASM firmware in its current state). NikoG's The Artist robot sure seems to go where it's told.
I've been thinking a lot about encoders and motor control lately and I have more rambings on the topic in post #55 of the OPP#8 thread.
I'm very curious how well the Arduino works when controlling the Arlo motors. If you make a video showing your robot in action, I hope you share it with us. I know John Blankenship is using a "RobotBASIC" controller with his "Arlo". I don't know what microcontroller is used but it appears to do a decent job controlling the hardware.
Fuses: i bought a fuse combo on a brick & mortar store "Harbor Freight Tools" and i got mini and ATO fuses, both work on APDB, although the lp mini fuses are sexier and good quality. This avoids going online plus shipping etc.
Current monitoring:
I'll test two options the circuit #29130, and a ACS714.
I have one Phidgets current sensor #1122, i use to monitor the total current. From observation it's based in a ACS712, has a PIC and ADC IC, probably is the reason why is 3 x the regular ACS7x product (Pololu). They must have some kind of software filter/logic to provide a stable value.
ACS7xxx seem very prone to noise and magnetic interference. Probably i'll need to have the current sensors far from the motors or i'll build some isolation box around the circuits, more work and time to test...
HB25: If i could ask two product improvements on the HB25 would be:
1) Current sensing output to read through a analog port.
2) Fan control, if the motor will be idle for a specific period, i would send a switch off command to the HB25, and a switch on on the next speed command. To be on the safe side the HB25 could activate the fan when the temperature is high, overriding the user commands.
I'll implement a relay to control the both HB25, i have doubts if this is the proper/best way to control the HB25/FAN, or if there is another away e.g. some backdoor left open in the circuit for advanced users
Tiago
we are moving away from the initial conversation (current monitor). I hope nobody gets upset. The topic is also interesting and multiple ways to address...
PID Controller.
1) arlo drive code: difficulty to understand the code logic, too much copy paste, there is a calibration process that i could not understand how it was implemented (code logic), I'm a developer i get very sensitive to code design it's my fault, free code you should not complain. btw I'm not complaining, please keep going.
2) arlo drive implementation: only 2x ticks, and a calibration process. I don't like calibration idea, i prefer some kind of PID controller, dynamic adapt to the different loads, terrains etc. Although a calibration could help to detect min max values, only relying in a initial calibration does not seem very dynamic.
3) Encoder: low resolution: I think for a great motor product/kit (ARLO), the encoder should be inside the motor connected to the gears and providing a higher resolution.
After mounting the 36x encoder it seems the rotation is weird (wiggle?) and seems fragile. It would be a number one wish list product improvement to have a high resolution encoder.
I would still leave the door open to install the existent encoder for scenarios where the frequency could be an issue (software decoders), and/or learning how the encoder works. High res built in and low res outside as add on.
4) Arduino vs Propeller: to be honest i would love to explore more the propeller concept (multi core), versus a single loop execution, interrupt based code. The reason why i went via Arduino is mainly due to SPI library and the PID code, like i said i didn't know how to do it propeller way.
The decode is done via hand made PCB hardware with two chips (for each wheel) they decode the signals, increase or decrease autonomously, then they are interfaced via SPI to the arduino. I select which slave decoder i want to read, reset or change other settings. The advantage of these ICs is you can offload the task, and support higher resolution encoders, basically i have Ferrari decoder connected to school bus wheels.
5) PID Control: The only measure i get from the encoders are ticks, otherwise does not make sense to use an IC to offload the task.
I had from a previous project a PID implementation, running 30 times per second. This was the first problem, my tests got ~27 ticks per second slow rotation, ~275 ticks per second high speed. Running the PID controller at 30 Hz, is not even a tick for delta period. I changed the PID controller to run at 20 Hz, but is still low the number to be efficient. Only to compare to a previous project Pololu Motors, the number of ticks per revolution = 8384.
Is interesting the idea you mention of measuring time between ticks the question is how you translate to run the motor x inches per second. Hum... must be possible.
I need to perform a similar test to yours (square), can you point which file/files you have your PID implementation ?
Tiago
This would be nice, but I doubt I'd be willing to pay much extra for this feature.
The HB-25s shouldn't reach near their max current with these Arlo motors. I wouldn't complain if current sensing were added as long as it didn't raise the price of the HB-25s
+1 from me!
Having the cooling fans constantly running is kind of annoying.
I think the fan could be controlled with a relay relatively easy. Undo the two soldered wires, remove the fan, add your own wires to the relay and reattach the fan.
BTW, I really think Parallax should change the 5A relays to 10A relays.
Well, the OP did say " I was careful, but i did a few tests, payload test (my 2 1/2 kid was sit in the bot) and some driving maneuvers led the bot against some walls." Stalling a motor might get up past 10 A.
https://www.sparkfun.com/products/10643
Also I believe the chip used on the HB25 has a pin for current output but is not used. I know I look up the chips data and some of them have and output for current monitoring. I don't know if this is one of them.
And while were at it what happened to the rumor of a 48v motor driver?
thanks, john
@jdolecki: you are right, in the chip datasheet Pin 9 is the CS output, with a resistor the output could be read, unfortunately i do not have soldering skills, neither i fell lucky to perform the operation, but definitely being there, so near grrrr, would be far more effective than probably interfacing third party circuits.
Tiago
I'm a little jealous of your Eddie firmware honestly. I wish those of us on that old ancient C code could benefit from all of this research regarding the use of the quadrature encoders!
I plan to get back to the quadrature encoder code but I'm taking a bit of time right now to get my "Halloween Hex" presentable.
I'm not promising to take on the C code but I'm very curious if aspects of the C code could be used to improve the Spin code and visa versa. I'm not satisfied with how the Spin code works at very low speeds but I am optimistic this is one area I can still improve.
I think my new ability to accurately measure speed over short intervals (by measuring time between encoder ticks) should make it easier to precisely control the motors at low speed.
I ramble on about some of my ideas for improving the code in this OPP#8 thread here:
http://forums.parallax.com/showthread.php/158030-Open-Propeller-Project-8-Eddie-Firmware-Ported-to-Propeller-Activity-Board?p=1312170&viewfull=1#post1312170