Corner Encoder System - General Improvement possible

[ericjunkins]

Problem

The absolute encoders used on the corner system are relatively expensive, and also require a voltage scaling solution to convert from the 0-5V analog output signal to the 0-2V scale that the RoboClaw motor controller accepts as input.

Solutions

There are many potential solutions to this problem, and could be an improvement in complexity, or cost. Below are a few proposed potential solutions that could be explored further.

Cheaper Absolute Encoders

One solution would be just using a cheaper absolute encoder, one example would be https://www.usdigital.com/products/encoders/absolute/rotary/kit/MAE3 . These would require a little bit of design work as they are to be mounted in-line with the output shaft of the motor. These are about $10 cheaper per encoder, but also allow you to skip buying the gearing system for each corner as well, meaning you save closer to $20 per corner

Potentiometer

To greatly increase the cost savings on the system you could use a potentiometer (variable resistor) in order to do get the absolute position on the corners. This would be a bit more work on the design side to mount a pot in a correct way, as well as tune all the numbers correctly. Below is a forum thread on arduinos' site that talks about this a little bit.

https://forum.arduino.cc/index.php?topic=262286.0

Quadrature Encoder

Another high cost-savings solution would be to replace the entire absolute encoder system with a standard quadrature encoder (like the drive motors have on them already). This would save about $60 per corner for a total of ~ $240. However this system now loses all knowledge of absolute position every time it boots up. In order to make this implementation work a software calibration process would have to be written to find the position of the corners each time upon boot-up of the robot.

[mikcox]

I'd like to throw into the discussion that another alternative is to use servos rather than dc motors and encoders for the corner steering. There's some ongoing discussion about this already, but I figured it'd be valuable to mention that option here as well.

[Playville]

Absolutely like that idea. I’m also experimenting currently with servos and noticed a better torque and more accuracy. Also it could save some money if you get rid of encoders.

[mikcox]

@Playville that's fantastic. If you wind up creating a solution that you're happy with, we'd love to take a look at incorporating it into the master instructions!!

[Playville]

Sure thing! I’m about building it in 3D for some printing parts, I’ll keep you updated for sure!

[lukeweston]

I'd consider using something like an AS5040 (DigiKey SKU: AS5040-EK-AB-ND for an assembled breakout board with the AS5040 IC.)

Requires a small diametric* neodymium magnet, mounted to the end of the rotating shaft at the back of the motor etc, with the sensor IC mounted concentrically a couple of mm away from the magnet. Imagine a magnetic compass needle, which is the sensor, sensing the position of a rotating magnet hidden below it.

(* The magnetisation is 'across' the disk, not 'through' the disk as magnets usually are.)

This provides a non-volatile absolute index position (the north-south axis of the magnet glued to the shaft), high-resolution encoding, and standard quadrature TTL output, at a cost of about USD$10-20 per encoder (depending on economy of scale and whether you make the breakout PCB yourself.)

[ericjunkins]

At a quick glance these use SSI as a communication protocol if I read correctly. What were you thinking about how to get them to communicate to the rpi

[ericjunkins]

Also if you get the motor without encoders on them from either servo city or pololu neither of them expose the motor shaft out the back of the motor, only option is in line with the motor output shaft

[dcschooley]

The RoboClaws have homing capability, where the motors are driven to a home position and the encoder position is set to zero when a switch is closed. It looks like it would work, but you need access to pins 24 and 25 (S4 and S5) on the controllers, and those pins aren't accessible in the Rev E. PCB design. If this works, you could get rid of the all of the absolute encoder stuff by adding a few wires, a switch, and maybe a resistor. There would need to be some software changes. The steering motors would be identical to the drive motors with the built-in encoders.

As a benefit, the rover would get to do a brief dance at every startup to do its own calibration of the encoder position.