OpenServo.com

[cweeks]

Hi all,

I have read on this forum that some code has been started with optical encoder feedback in mind and I am interested in it's current status.

I have a project that would really benefit from an optical encoder for feedback rather than a pot. It's a piston ballast tank on a model sub, basically it's a linear servo that will use a lead screw and have a travel of about 200mm. A 10th of a turn resolution on the screw would be enough, 20th of a turn resolution would be amazing, and flat out RPM will need to be around 600RPM.

Using a 2mm lead screw 10th of a turn accuracy gives a .2mm resolution on the piston and a traverse time of 10 seconds.

I think I talked to Ginge a little while ago about this, but other projects got in the way and I never bothered him to get the code. But this project is back on the burner again so here I am open handed

Any help appreciated.

Cheers, Cam.

[ginge]

Hi Cam,

[cweeks]

Dummy post so I can post some urls

[cweeks]

No the board isn't letting me post urls, guess I have to wait two days after my second post ?

[cweeks]

Thats good news, thanks for taking the time to explain the situation, looks like I will have to get myself some V3 hardware to. I notice at http://pendragonrobotics.com/OpenServov3.html that they aren't currently available, is there another source, or am I making it myself ?

Ultimately I will probably need to remake the board with more current
ability as the piston tank will need a fairly beefy motor, 380 or 540 sized, but for testing the normal servo board would be a starting point, then again it depends how you connect the quadrature encoder, and how much butchering the standard board needs, or not.

Haven't decided on an encoder yet, was going to have a flick through the Farnell catalouge, maybe etch or print a disc, or possibly use something like is shown here:

http://www.portlandrobotics.org/index.php?id=77

Does the v3 hardware use the same programmer ? Ive got a OSIF V1.0 USB board.

And finally this is a commercial piston tank:

http://www.engel-modellbau.de/catalog/product_info.php?cPath=2_29&products_id=506&osCsid=a8533928c175a910c9e99d6f2945a462

Thanks again, Cam.

[ginge]

Hi Cam,

I believe that we are waiting for some more orders to get the v3 manufactured. I am going to place an order this week for 50 for the OpenServo webshop, and jay informs me that they will be ready within a couple of weeks after that.

I think you are correct that you will need to remake the board to suit your needs. It would certainly be worth doing, and something we can all help you with. I will get the finer details hammered out (MCU connections etc) and then we can go from there.

The homebrew encoder you linked to is the system I was using for the v2 hacks I was playing around with. I think I will revisit this hacked up servo for the encoder testing.

As for your OSIF question... yes, the v3 it uses the same programmer. You will need a generic AVR programmer to get the bootloader into the OpenServo, but from there you can upload the firmware and control the V3. If you have an AVR programmer, you can upgrad your firmware to the new OSIF v2 branch, which has faster comms and AVR flashing capability.

Cheers,

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

[ginge]

Hi Cam,

I went ahead and made the modifications to the fried v3 I have to see how much work is needed to make play nicely, and it is fairly insignificant.

The encoder support relies on using an external interrupt pin for tracking one channel (channel A) of the quadrature input, and another pin for tracking the second phase (B). The current incarnation of the v3 hardware ties up both of the interrupt lines for use as the bridge driver hardware (Enable A and Enable B) which means we have to cut one of those traces and reroute it to another pin. This is very tricky because of the current size of the PCB, meaning it is easy to destroy the board.

The good news is that I have working encoder tracking working, at least in the most simplistic form. At the moment the pot is read for the initial position, and then the encoder is used to calculate the position and velocity from that point.

There are a few things that are going to make this a tricky feature for people to use in their own hardware, such as your ballast driver, as the encoder will have to be calibrated for the number of pulses per full range output.

Another thing that is going to be tricky is hardware without the dead reckoning potentiometer to get a position on startup. Unless the hardware always starts in a known good position, there is only one other way of telling the OpenServo where the servo horn currently is, which would be to turn the motor until it hits its endpoint. At this point you can detect the current draw to determine if it is at the end of its travel, or use a switch to detect the home position. This could be potentially dangerous depending on the application.
I am assuming your hardware won't have the potentiometer to get this initial input, so I am unsure as to how we should go about handling this potentially dangerous situation. Thoughts?

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

[cweeks]

Hi Barry,

In my enthusiasm I hadn't stopped to consider the finer points, i.e. the starting position. I see a couple of ways to get the starting position.

1) I could add a pot to the design, linear ones are out as I can't find a one with 200mm stroke, if I could there would be no need for the encoder, it would probably work fine as the only feedback source. I could use a multi turn pot driven by a gearwheel off the lead screw but this seems like an ugly solution, it will be bulky and tricky to implement, I'll have to machine the gearwheel etc.

2) An end stop switch would be fine for my particular need, as you say just run the servo up to the stop on start up. It wouldn't cause me any concern. I guess for you guys using them in robotic creations you have far greater concerns about un-coordinated movements towards end points. Maybe implementing both alternatives in the code would cover everyones needs ?

I don't mind having a bash at the PCB design, It will only be single sided through hole as thats all I can manufacture at home, but it might work as a starting point should another want to make it smaller. I can program AVR's to so that's no problem. So I can get started can you confirm you have used pins 1 (EN_A) and 32 (EN_B) for the quadrature inputs ? And what pins have you connected EN_A and EN_B to instead ?

Cam.

[ginge]

Hi Cam,

It isn't really important which pins you use for the encoder as long as one channel has a connection to the interrupt pin. For simplicity I remapped ENA to pin 30 (PD0/RXD) you could use pin 12 (PB0) for the locater switch. If you wanted to keep the serial lines free for future use, you can use PD5 and PD6 for the encoder channel B and the switch. It is very simple to remap these in firmware, so the choice is yours.

To summarise:
Encoder channel A - pin 32 (PD2)
Encoder channel B - pin 31 (PD1)

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

[cweeks]

OK, got ya. After I have done a little research into finding none SMT alternatives to some of the IC's used in the current design, and I have designed my PCB I will let you know.

Cam.

[cweeks]

OK I'm struggling to find an none smt alternative to the SN74CBT1G125, would a 4066 with a diode to protect it's input from the negative going spike be acceptable. The 4066 has a higher Rds but it's still orders of magnitude lower than the impedance offered by the voltage divider, what you guys reckon ?

[ginge]

I just got some of these Hamamatsu p5587 photoreflectors

http://www.active-robots.com/products/sensors/sensors-hamamatsu.shtml

It has all of the bits in it to directly interface with the AVR. I will hook it up and let you know how it goes.

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

[cweeks]

They look ideal, little, cheap and easy to interface. Will get myself some, cheers for the tip off.

Cam.

[subculture]

There are commercial controllers available for piston based submarine dive tanks.

They use hall effect sensors instead of optical sensors.

Markus Rieger sells a board which can control motors upto 30A, and Christian Feldman makes a smaller board for up to 5A motors.

Andy

[cweeks]

Thanks for the info, do you have links for them ?