@MHTS, that looks interesting. So it's another way to do what I did?In fact, I am both running it long enough for the values to wrap, and I need to use it for another application.

I might as well post this now, I don't want a whole program written however some advice as to which direction to take would be nice.

I am making a GBC (great ball contraption) color sorter, with a central belt and two arms. The arms push the balls off to whatever side they should go on, and thus sort the balls. The arms are not each assigned a color - rather, each arm should push every second ball.Yes, it is gratuitously inefficient but this is the point of the gbc.The belt ticks forward twice every revolution, and the current rate gives the standard GBC 1bps throughput rate.There is a clocker connected to the belt that lets each ball available fall into its slot. a color sensor scans the ball awaiting the clocker and so we can determine the color of the ball a certain amount of 'degrees away' if you will. I also know the amount of 'degrees' from the scan point to each arm.

Hopefully I was some help. Basically, the problem lies in the wrapping of the rotation values, as well as not resetting as the motor encoder needs to be used for both the belt regulator and each arm's distance measure.Oh, the arms are not evenly offset either - i.e. when the ball in the slot is below one of the arms, the other arm does not have a slot below it.

I hope this makes sense, please let me know if you can help. again, I do not want you to write up a whole program for me, I am just a bit lost as to how to achieve this. I am thinking 1-d arrays to store the balls colors? No idea how to implement this...

Thanks again!

Fri Jun 15, 2012 8:40 pm

MHTS

Guru

Joined: Sun Nov 15, 2009 5:46 amPosts: 1523

Re: Troubles with encoders

If you need to run it long enough to have the encoder values to wrap, you may want to reset the encoder in every iteration. You still can keep track of the "distance moved" by having a cumulative variable before you reset the encoder. For example:

Even at full speed (!170RPM), it would take a about ~585 hours of continuous running for the encoder values to wrap. That's more than 24 days!

You need to change the way you calculate your RPM. The encoder delta between the previous and current iteration is always whole, so there is no need to use a float there. The delta will also be small, even if you only poll every second, it would be around 1000 at full speed.

According to the RobotC documentation unless they have changed it in the latest version:

Quote:

nMotorEncoder[]Current value of the motor encoder. Range is -32768 to 32767 so it will "wrap" after about ~90 revolutions. The user's program should reset the value of the encoder often to avoid the value "resetting" itself when the maximum distance is met.

nMotorEncoder is a 16-bit signed value and it will wrap around 90 revolutions. So at 170 RPM, you will wrap around at about half minute. It's true that you don't need to use float to represent speed. The code was just to demonstrate calculating the speed with an easy to understand unit (revolution per second). You can certainly represent it with an integer and multiply it with a scale factor of 1000 to reduce precision loss. I converted it to float just because the FRC library always normalizes units to float between -1.0 and 1.0 so I got used to that scale.Besides, even if it takes 24 days to wrap the encoder value, I don't want to make the assumption that the machine will not run that long. I've seen some stores that have lego demo in their display window running day and light non-stop. So it could easily run beyond 24 days

use more sensors. instead of depending on a fixed speed belt and perfect timing, just trigger when a ball passes a certain point. would that work and actually make it simpler?

edit: thought about it some more; I know your idea of a GBC is to amaze with unnecessary complexity, but will you be showing your code as well? Its even simpler than I was thinking. Move the belt X ticks at any speed, do something, (reset ticks if you want, repeat). the process of trying to maintain a constant speed, then convert that into a distance, then time some event to that, is overkill.

also, after that, I assume I do something like beltSpeed += (intendedRPM - rpm) * kp ?is that correct?Thanks again!

Actually, that equation is to generate rps (revolutions per second) not per minute:delta_encoder/360.0 gives you delta_revolutionstime1[T1]/1000.0 gives you delta_secondsrps = delta_revolutions/delta_secondsrps = (delta_encoder/360.0)/(time1[T1]/1000.0)rps = (delta_encoder*1000.0)/time1[T1]/360.0

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum