Lizard Brain

I am building a low level Uno based Differential Steering Robot Motion Base. Everything is oversized because this is going into an Electric Wheelchair robot. I
have:
1 Sabertooth 2 x 60 (dual motor 60 Amp)
1 Kangaroo x2 motion controller.
2 Very nice Dynopar Quadrature Encoders.
4 Sharp IR ranging units(2 long and 2 short range)
4 Scanner mounts with servos for IR units
1 IMU (compass , Roll , Tilt , Yaw)
1 Arduino Uno
2 Small 24 volt gearmotor driven O-Ring Wheels
2 Rechargable 15 Volt Battery Packs and Charger
1 Small Tail-Dragger Robot Platform.
1 Large 24 Volt Electric Wheelchair Base.

My Goals:
Monitor Battery, On low battery FIND NEST using just the UNO
Wander using non-contact IR bumpers using just the UNO
Monitor Contact Sensors using just the UNO
Wall Follow using just the UNO
Beacon Seeking (Find Nest) using just the UNO

Receive Motion Commands Serially from laptop(Drive, Turn, Distance, etc.) as high level commands from Roborealm and/or FlowStone

Where Am I at:
Manually Charging Batteries
Rudimentary Driving controls.
Sabertooth run in Analog Mode.
Sabertooth run in Simple Serial
Sabertooth run in Paketized mode
Kangaroo x2 ordered.
Rudimentary Wandering code using Sharp sensors mounted on servos to scan for obstacles.
Moving Sabertooth S1 fsrom TX pin to Pin 2 To restore serial coms to PC
IMU Examples up and running doing Telemetry back to PC

Discussion:
How to Implement Primary/Secondary relationship for motor speed.
The first question is analog or Digital motor feedback.

urthlight:
How to Implement Primary/Secondary relationship for motor speed.

What is 'Primary/Secondary relationship'?

urthlight:
The first question is analog or Digital motor feedback.

I'd expect the digital approach to be more accurate, but you will need to decide your own trade-off between how well it works and how easy it is to implement.

What is 'Primary/Secondary relationship'?

Master/Slave if you like. Driving one wheel and matching the speed with the other wheel.

It looks like the Kangaroo x2 may take care of it

I'd expect the digital approach to be more accurate, but you will need to decide your own trade-off between how well it works and how easy it is to implement.

I concur with your assessment but was throwing it out to see if anyone would argue for analog.

The Next discussion would be Fusing and E-stops.

From Dimension Engineering:

We prefer that you fuse the motors rather than the battery leads, or if for safety reasons you need to fuse the battery that you do it at a much higher current than the motors. The reason is this:

Because Sabertooth is a regenerative driver, it relies on having a battery to put regenerated energy back into when you command a stop (and at other times). If you draw enough power to blow a battery fuse, all of a sudden the Sabertooth has nowhere to put the energy. It will see the fault, though, and try to stop the motor. It doesn't, however, have anywhere to put the energy (the mechanical energy of the vehicle and the electrical energy carried in the windings and the caps). So blowing a battery fuse will sometimes kill the driver -- which we would replace under warranty, but it's still annoying for all parties.

The better way to do it is to fuse the motor leads. If a motor fuse blows, the motor will freewheel, the Sabertooth will sit there contentedly, and the only thing you will have to replace is the fuse. A very large fuse (100 amps) on the battery lead will protect the wiring in the event of a battery lead short or motor driver failure.

This appears to handle fusing unless there are any other opinions.

E-Stop:
So killing the power to the Sabertooth is a bad thing but the motor circuit could be broken giving me a simple but expensive option of a dual 60 amp switch or relay if this practice will not bruise the controller.

Being as I will probably be using Packetized mode Any other E-Stop will be generated by software. This is bad practice in the industrial world and could be bad on a large rover.

Are the motors just two lead DC motors, not brushless? If so, it seems to me you only need to open one lead with an E-stop. Please correct me if I'm wrong.

Are the motors just two lead DC motors, not brushless? If so, it seems to me you only need to open one lead with an E-stop. Please correct me if I'm wrong.

Yes brushed DC Motors but there are 2 motors hence a dual switch to disable both motors.

Still no Kangaroo. Maybe next week. Which brings another point.
I want the command from the laptop to be forwarded to the drive but if the laptop is off (low battery) the arduino enters seek nest behavior. I considered just using a relay to switch the TX and RX lines from laptop to microcontroller but serial comms would have to be reestablished after the switch so I think i will need a more robust solution. But I will try it when the kangaroo comes in.

I brought the wheelchair base into the shop and decided to cut the plugs off and start spinning the motors. Encountering locked rotor amperage and no movement I started breaking down one the motors. It was full of rust and frozen in place. After applying a liberal application of deep creep, I pulled the other motor and gave it the same treatment. One good whack with the plastic hammer and they came apart. To the wire wheel with the rotors. Then with a sandpaper wrapped broomstick the magnets were almost pristine. Four new bearings later the motors are purring. I did inspect the gearboxes and found no water in them.

The Kangaroo x2 is in. After some driver issues I got it running on my desk. The encoders are attached and coupled to the motors. It needs improvement but it will do "for testing purposes". And the gearboxes and wheels are safely in a tote.

The original questions were indeed answered by the kangaroo x2.

The next dilemma is how to implement a two way switch to supply the packetized serial data to the kangaroo from the laptop and I have decided to use an R/C transmitter/receiver for teach mode.....so the Arduino now has to be the Lizard Brain, Pass data from computer via USB and interpret 2 channels of R/C.

I may have to move to the Mega to accomplish all of this just from a program space considerations.

Any thoughts / discussions?