[FTC]: FTC read encoders vi

[Jim.D]

I'm having trouble getting the encoder position from the FTC read encoder vi. I can get the move fixed dist to work so I think the encoders are working.
Any help appreciated.

[ttldomination]

I'm not to familiar with Labview but check out the following page to see if you can find anything helpful. http://www.education.rec.ri.cmu.edu/content/events/ftc/labview/index.htm

[Jim.D]

Thanks for your reply. I have already been there. I think I have all the patches applied. I didn't see any samples for reading the encoder, only for using the fixed dist or speed vi's. I can get those ones working but not the one that just reads the position. I noticed that the fixed distance vi has output terminals for the encoder position but they don't really show encoder position as they will count even if the motors aren't turning. They just echo the count that you told it to use for the distance.

I need to find ends for the encoder cords and make a diagnostic cord.

Thanks again
jim


Update - Maybe the vi works different than I am expecting. I can read out the position after I use a motor move command. Is there a way to read the USDigital encoder position directly without having to use a move command ?
(like you can with the lego motor/encoder). For now I will try issueing a move 0 command before the read encoder.

[jbbjjbt]

Read thru this thread and check out the sample code.

http://www.chiefdelphi.com/forums/showthread.php?t=69991

[Jim.D]

Thanks Jon,

I had looked at that. I also have noticed the problem with the rest. My main problem was that I wanted to read the encoder position. It seams that you really cant do that directly like you can with the lego motors. the read encoder vi returns the pointer of were the encoder should be and not were it is. IE you can watch the reported position change even though you disconnect the motor and it realy didn't move.

Not getting an accurate position can lead to letting the smoke out of the motors. We need to be able to use motor protectors on the FTC bots.

Do you know how the error out for the motor VI's works ? can it be used to protect the motors or does it also just report that the motor should be turning ?

Thanks for your help. I am new this year to robotics and labview.

Jim
FTC 1983

[TimeOut]

Morning Jim,

The encoders don't actually keep the position, they tell you how many clicks away you are from where you last zero'd the encoder count. So, if you have 360 ticks (I'm not sure how many there are on these encoders) then each tick would be 1 degree. As the wheel turns forward the tick count increase, as the wheel turns backward the tick count decreases.

By counting the ticks you can tell how far you've traveled. By adding a time factor into you can tell how fast you are moving. After doing the math for any gearing and wheel diameter you can determine distance moved.

The Mindstorms Encoder keeps the count internally and uses the count to determine an approximate 'position' of the motor and to 'move-to' a specific position.

This may have to be accomplished manually with the FTC equipment; part of the fun eh?

If you need the position to control a manipulators position, you may want to consider using a potentiometer instead of the quadrature encoder. The can be easier to deal with when you do not need continuous rotation (like a drive train).

The typical application for the quadrature encoders is on drive trains to help with measuring distance, turning the robot specific angles, and helping the robot drive straighter (especially in autonomous mode) by either implementing PID controller or comparing the left/right encoders and adjusting speed when one gets too far ahead of the other.

Sean

[PhilBot]

Thanks Jon,

I had looked at that. I also have noticed the problem with the reset. My main problem was that I wanted to read the encoder position.

This isn't a great solution, but one way to read the encoder position is to repeatedly call ConstantSpeed with power set to "0". This keeps the encoder logic running.

So, in a pinch you can have a loop that contains "Constant Speed, followed by Read Encoder and a short time delay... maybe 20ms"

I've still had problems with this approach, but it's better than nothing.

I was going to post a snyde remark to "Sean" indicating that while Pots are a good solution, they are not available to us in FTC..... but then I thought..... Wait, If I use a NXT prototyping board, and the POT is attached to that board, it IS legal..... Hmmm.... potential....

So, Thanks Sean.

[TimeOut]

Phil,

Actually, that was a good catch and I didn't even think about the 'legal for FTC' part and I should have actually looked it up before referring to it.

Sean

[PhilBot]

Thanks Jon,

I had looked at that. I also have noticed the problem with the rest. My main problem was that I wanted to read the encoder position. It seams that you really cant do that directly like you can with the lego motors. the read encoder vi returns the pointer of were the encoder should be and not were it is. FTC 1983

Hey... I just posted a paper that explains what I have found out about the various encoder VIs

It may help you figure stuff out.

http://www.chiefdelphi.com/media/papers/2179