OpenServo.com

[ginge]

Hi all, I am just wrapping up my quadrature encoder modification for OpenServo, and want to know if the features described below are adequate, or am I missing an obvious mode...

MODE_CONTINUOUS
The servo is modified for continuous rotation, and the encoder is used exclusively to track servo rotation and velocity.

MODE_COMPLIMENTARY
The servo is used as normal, but the encoder input compliments the potentiometer input to gain higher accuracy.

MODE_EXCLUSIVE
The encoder is used on an unmodified servo, the potentiometer input is disabled.

When I get the source fully tested, I am going to embed my optoelectronics into the servo chassis. I will keep you all updated as to my progress.

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[linuxguy]

[ginge]

I just ran up against a small problem whist testing the continuous rotation mode... Travel distance.

Assumptions:
max distance using current position scheme: 0xFFFF (65535)
wheel diameter: 3cm
encoder resolution: 1024 ticks/revolution

so:-
3 x PI for wheel distance/revolution = 9.425cm

crunching the numbers you get a maximum distance of 603cm

This is limiting my robot to motions of 6 metres at a time.

There is a way out of this, but I don't see it as an elegant solution. The only way I can get a longer distance is to write a new position to the servo, which clears the encoder count, and starts again. I say this is a bad way of doing it as it still adds additional contstraints on the controller making sure it has a valid position, and calculating distance already travelled.

I have a couple of ideas for solutions:
1) Have another 2 position registers for a total precision of 32bits. This is pretty much guaranteed not to overflow (unless you are moving in the 4million metres range)

2) create a single new register that stores the number of full length movements (6m) to perform before using the 16 bit position values. This acts as a simple multiplier.

Any comments would be appreciated.

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[linuxguy]

[ginge]

I forgot to omit there is a mode for continuous rotation. With works by sending a go/ stop signal to the servo. WHile this mode is fine for applications that dont need to go certain distances and then stop, I feel it's not in the spirit of ""set the position and forget"".

A friend of mine who is going to be using these encoders is going to need to move the bot in 10-12m lengths, which is how this issue came up.

[linuxguy]

[ginge]

Okay, I see where you are going with this...

As with all OpenServo functions, the encoder values, and rotation count are exposed through a register. You can use the host controller to do the grunt work.

[linuxguy]

[ggpipe]

What is the status on the encoder support? I am really interested in this too. I would like to use open servo boards to drive a couple small continous rotation servo motors with encoders.

Thanks,

Glenn
_________________
Glenn

[ginge]

Hi,

At the time of writing those posts there was a less than enthusiastic response for the idea.

It does look as though the idea is gaining traction again, so I will pick up where I left off.

There is a little work that needs to be done to get things working smoothly, but it is possible.

One word of warning though, the OpenServo loses a lot of pulses at fast speeds. You have to make sure you have an encoder with a fairly low resolution output to get things working smoothly.

I will pick this up in the next few days and let you know where I am at with this.

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[linuxguy]

[mpthompson]

I've been working for the last few weeks to build a balancing robot and I'm using a board that utilizes the LS7366 chip from LSI which is a 32-bit Quadrature Counter with SPI Serial Interface. Because it implements the quadrature counting in hardware it can work at very high RPMs without missing a beat. It seems to be a bit hard to get ahold of, but I'm told that you can get them through Gemini Electronic Components if you call them. Like Dale, I'm using the GHM-04 motors and a pair of QME-01 encoders in my 'bot.

The chip is connected through a PIC so I don't have experience working with it directly (I'm an AVR guy), but it looks like it would be trivial to connect to an AVR either through the SPI pins or bit-banging on some spare IO pins.

Once I get through building this 'bot and another OpenServo related project I would be interested in helping to support this or a similar quadrature chip in the OpenServo. I'm not as enthusiastic about implementing quadrature counting in the AVR itself for the issues Barry pointed out. I think this is a case of using the right tool for the right job.

I do have a question. I'm assuming that support for a quadrature encoder would not necessarily mean supporting the same PCB form factor as the current OpenServo. Correct?

-Mike

[linuxguy]

[ginge]

I like that chip, although the SPI does put me off a little. It does mean that some pins that are previously allocated to the headers need to be reassigned to the SPI interface. In theory it would be possible to bit-bang the device using a different set of unused IO, but this would add latencies that would make the quadrature encoder values be several us (ms) out of date.

As Mike has mentioned, I am not overly enthusiastic about incorporating the interrupt counters directly into the OpenServo, as it is just too slow. The only workaround I can see is to use something like the LS7366 or a small attiny45 which does the pulse tracking and provides a serial interface. This is the route I went down to test my rig, and it works fairly well. I put the whole project onto the back burner while I considered latency options. Having another chip in the loop introduces another layer of comms that need to be dealt with. For example, the test rig with the attiny on it introduced a latency between the the host and the slave in the order of 8ms. This doesn't seem like a lot, but when you are talking fast moving motors and quick transition times, it is practically a huge amount of time.

[ginge]