Occassionally followed Makey mini sumo directions

Always wanted to build a robot. Makey in Make magazine seemed easy enough. Since then I've spent way too many hours learning the hard way why I should have followed directions in the first place. First short cut was choosing an old RC for the robot's base, motors and wheels (well tracks). The motors required more AMPs than the sparkfun TB6612FNG dual H-bridge could deliver. I kept adding 9 volt batteries in parallel till the bot moved smoothly. Eventually the H-bridge overheated, melted away insulation on the PING wiring and *POOF*!!! blue smoke and that unpleasant burning smell. Crud! Rework time. Used two L293 H-bridge chips in parallel run fine for about 30 seconds till they overheated.  Two SN754410 h-bridges in parallel running fine so far. Using two seeedo PING $15 knockoffs so I can detected left and right without servo delays. Two lithium cells from an old laptop provide 8.5 volts for the motors. On a full charge I set the bot's PWM speed to 125 (half of full). At 255 it enjoys smashing into everything and I can't catch it. This one time while running object following, it found the dog and instead of following it, the bot drove up and over the dog's back. Currently working on adding compass or 2 axis accelerometer to provide turns in degrees. Then I'd like to add some debugging lights and or sounds, and experiment with programming. 

Currrently considering starting over with better requirements (controlled environment, do a specific task, controlled speed).  Less fun, less frustrating.

Basically roams around the house, avoids walls, smashes into chair legs, runs over dogs.

  • Actuators / output devices: RC motors
  • CPU: Arduino
  • Power source: 9v for arduino and 7.4V Lithium (2 cells from laptop battery pack) for motors
  • Sensors / input devices: Dual Ultra Sound
  • Target environment: undefined

This is a companion discussion topic for the original entry at https://community.robotshop.com/robots/show/occassionally-followed-makey-mini-sumo-directions

Motor battery voltage monitor to control PWM

My next robot goal is to drive the robot motors with more consistency.  Too often I find myself trapped fiddling with PWM to adjust motor speed.  I’d like to just run the robot without always checking the motor battery pack.  Freshly charged battery makes the robot zoom into a wall (overrun the distance sensor) and too weak makes the robot motor stall. 

So I want to compensate motor speed by reading battery voltage and divide that by 8 (1024 max analog read / 4 converting to useful digital output range / 2 slow that bot down) feed that into drive motors’ PWM. Link below has good enough background on voltage divider.

http://forums.trossenrobotics.com/tutorials/how-to-diy-128/cheap-battery-monitor-using-resistive-voltage-divider-3264/

Any pitfalls to constantly measuring motor battery volts?  Wondering about motor noise, monitoring drain on battery, protecting arduino.

Graph of traxbot motor battery voltage monitored 30 second under

Here’s motor battery voltage monitored 30 second under load.  The two old laptop li-ion cells fully charged to 8.4 volts and used a 680uF/50volts bulk capacitor. From what I read the bulk cap doesnt have to be that large but that’s what was handy in 50volts.

The dip at the end is when I put my hand in front of the PING sensor to make the bot go in full reverse. :slight_smile:

 

Guess I’ll need to stop both motors running to get a stable battery read if I’m going to feed this back into PWM.

traxbot_motor_battery_monitor_30_second_.jpg

Also here's the voltage divide circuit slightly tweaked from Yenka simulator. Used 1N4148 for all diodes. "4.05 V" is a volt meter for simulator purposes but that is the output to analog pin.

VOLTAGE_DIVIDE.jpg

Bigger capacitor!

I’d advise you to use a bigger capacitor, or -if you don’t have a bigger one- use multiple capacitors in parallel. This will (partially) take care of the voltage drops. Also, if you know that under normal operation your battery will have these voltage drops of let’s say 0.25V, you can add a line to your code that only works with a corrected voltage if your measured voltage differs more than 0.25 or 0.30V from the measurement before. Code would be somthing like:

voltage=analogRead(voltagePort);
if(abs(voltage-previousVoltage)>0.25) {
previousVoltage=voltage;
}

During the rest of your program you work with the previousVoltage, which will only get updated if your voltage difference exceeds a specific treshold (in this case 0.25V).

To handle big voltage drops like when you slam it in reverse, you could check the voltage 2 times before working with an updated value (so you’ll have 3 voltage variables: current, previous and the on before the previous).

Bulk Motor Capacitor Tests

Bulk_Motor_Capacitor_Tests.jpg

I've been running a bunch of bulk capacitor tests for the motor over 30 seconds at 75% power.  No cap seems to have the most voltage. Confusing!

Fixed!!!

Fixed!!! Moved my voltage divide circuit from pin 1 to pin 5 and set 0-4 analog pins and set the two PWM pins to the h-bridge as OUTPUT.  Apparently arduino sets all the pins to INPUT by default - doh!

Reran my tests (averaged two passes) and the reasonable sized 100uF bulk capacitor provided the most consistent voltage to the motors from two lithuims (averaged 8.46 volts as compared to 8.30 volts for three 2200uF caps in parallel).  Not shown in the graph - four lithuim batteries held steady at 8.48 volts.  The extra weight of two more batteries concerns me though.  Guess I can cancel that 15000uF cap from my next Jameco order.

robot_motor_capacitor_tests_2_passes.jpg

 

So the real problem I've been trying to solve -- the robot stalling in a corner like the kid in the basement at the end of blair witch project.  I suspect the dual L293 h-bridge resistence and heat (thermal shutdown) after running for more than 30 seconds than the battery.  Adding stop and wait between direction changes next.

False PING Readings

While debugging I’ve noticed that the PING sensors occassionally return false readings.  Sometimes get really long distances over 20 meters.  I’ve added if statements to ignore zero distances which is helping.  Not sure how to tell arduino what readings are believable after throwing out zero and over 20 meters – like confidence based on previous reading (%), or stop movement and double check distances.