View unanswered posts | View active topics It is currently Thu Jul 31, 2014 7:57 am






Reply to topic  [ 26 posts ]  Go to page Previous  1, 2
Troubles with encoders 
Author Message
Rookie

Joined: Mon Jun 11, 2012 9:28 pm
Posts: 37
Post Re: Troubles with encoders
MHTS wrote:
sqiddster wrote:
I'm having trouble coming up with an RPM value.

Not sure what you did here: rpm = (delta_encoder * (1000.0 / time1[T1])) / 360.0;

but it's not working for me.

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_revolutions
time1[T1]/1000.0 gives you delta_seconds
rps = delta_revolutions/delta_seconds
rps = (delta_encoder/360.0)/(time1[T1]/1000.0)
rps = (delta_encoder*1000.0)/time1[T1]/360.0

And what do you mean by "not working"?


OK thanks, I got that working. I removed the /360 for a dps value, is that reasonable?

As for the rest of the program (image/description a few posts above) I am still quite stumped!

Any ideas?


Sat Jun 16, 2012 8:46 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Troubles with encoders
You need to be more specific on what your question is. I re-read your post and still don't quite know your question.


Sat Jun 16, 2012 9:19 pm
Profile
Rookie

Joined: Mon Jun 11, 2012 9:28 pm
Posts: 37
Post Re: Troubles with encoders
MHTS wrote:
You need to be more specific on what your question is. I re-read your post and still don't quite know your question.


Sorry.

Basically, I want to know how to go about knowing when each arm should push, and in what direction (based off the color of the ball, scanned earlier). Each arm should be assigned every second ball.

Thanks for putting up with me,
sqiddster


Sat Jun 16, 2012 9:31 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Troubles with encoders
Why do you need two arms? It makes the logic a bit more complex when you have one color sensor with two arms and each arm will handle one ball and skip the other. Is it because the arm is not fast enough to swing back to process the next ball? In any case, there are many ways to tackle this problem. This touches a little bit mutli-tasking concept. What is the maximum possible number of balls on the conveyor belt at the same time? From the diagram, I assume, there could only be a maximum of one pending ball for even the farthest arm. If so, that it is slightly simpler, else you need a process queue for each arm. The pseudocode should look something like this. Essentially, the loop below is processing three tasks: one task to sense ball color, one task to control arm1 and the last task to control arm2. You may need a 4th task if you need to control the constant conveyor speed.
Code:
while (true)
{
    // Task 1
    if sense a ball
    {
        read color of the ball;
        ballcount++;
        if ball count is odd
        {
            set arm1 delay;
            set arm1 direction according to color;
        }
        else
        {
            set arm2 delay;
            set arm2 direction according to color;
        }
    }

    // Task 2
    if arm1 delay != 0 and currTime reaches arm1 delay
    {
        swing arm1 to the specified direction;
        arm1 delay = 0;
    }

    // Task 3
    if arm2 delay != 0 and currTime reaches arm2 delay
    {
        swing arm2 to the specified direction;
        arm2 delay = 0;
    }
}


Sat Jun 16, 2012 10:25 pm
Profile
Rookie

Joined: Mon Jun 11, 2012 9:28 pm
Posts: 37
Post Re: Troubles with encoders
MHTS wrote:

snip



This all looks good! In answer to your question, there are two arms because they are not fast enough to do 1 ball per second.
Your method is all well and good, however it misses the concept that you will have multiple balls awaiting each arm - the belt is long enough that there are spaces for a few balls between the color sensing point and the collection point. I assume I'll need arrays for this.

Thanks for all your help!


Sat Jun 16, 2012 11:06 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Troubles with encoders
Yes, that makes things more complicated. You need a process queue (aka array) for each arm. What is the maximum possible pending balls for each arm?
Code:
while (true)
{
    // Task 1
    if sense a ball
    {
        read color of the ball;
        ballcount++;
        if ball count is odd
        {
            Enqueue(arm1, delay, direction);
        }
        else
        {
            Enqueue(arm2, delay, direction);
        }
    }

    // Task 2
    if arm1 queue is not empty and currTime reaches the delay of first in queue
    {
        dequeue(arm1);
        swing arm1 to the specified direction;
    }

    // Task 3
    if arm2 queue is not empty and currTime reaches the delay of first in queue
    {
        dequeue(arm2);
        swing arm2 to the specified direction;
    }
}


Sat Jun 16, 2012 11:16 pm
Profile
Rookie

Joined: Mon Jun 11, 2012 9:28 pm
Posts: 37
Post Re: Troubles with encoders
Thanks for that...
What is this 'enqueue' and 'dequeue'? Also, what do you mean by 'delay'? What are you using time for? I would think time should be out of the equation as it should be entirely reliant on the belt tacho.
max balls pending... I believe it's 3 for the first and 5 for the second? Keep in mind they are also out of phase.

Thanks so much!


Sat Jun 16, 2012 11:26 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Troubles with encoders
Sorry, I am not sure how comfortable you are with various programming structures and concepts. Are you familiar with circular queue? If not, I can explain deeper into it.


Sat Jun 16, 2012 11:32 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Troubles with encoders
Think of a circular queue as an array that loops. Initially, the circular queue is empty. For example, if your queue can hold up to 5 elements (array of 5). There is a head pointer and a tail pointer to the circular queue. Enqueue is just a method to insert an element into the queue at the tail end. Dequeue is to remove an element from the queue at the head end. So it is just like a food line. You serve the head of the queue. New customer joins at the tail of the queue. Both the head and tail pointers can move when elements are inserted/removed from the queue. When the pointers are at the end of the physical array, it wraps back to the beginning, thus a loop. The queue is empty when the head and tail pointers are pointing to the same element.

The concept here is that there are two queues, one for each arm. When the SensorTask detected a ball and determined which arm should process that particular ball, it would insert a "request" into the corresponding queue. The corresponding arm task will process its queue for the next "job". When the SensorTask sees a ball and knows the color, it will queue a job for the corresponding arm telling that arm to swing at a calculated time. So if the SensorTask decided the farther arm (arm 2) should process this ball and knowing that it takes 3 seconds to reach arm2, it will queue a job that will execute at currTime+3 for arm2 and also specifies the swing direction in the job. Does it make sense? In other words, time is being used to synchronize between the SensorTask and the ArmTask. Alternatively, you can also use the conveyor belt encoder to synchronize between the SensorTask and the ArmTask. So instead of queueing a request specifying what time to execute, you can queue a request specifying what encoder counter the arm should start swinging.


Sat Jun 16, 2012 11:40 pm
Profile
Rookie

Joined: Mon Jun 11, 2012 9:28 pm
Posts: 37
Post Re: Troubles with encoders
Hey again,

Back to the topic of the post, the control loop I made is very shaky, and my DPS (degrees per second) values are very shaky - and always a multiple of 100 - i.e. they fluctuate between 100 and 200, with nothing in the middle. Any tips?

Code:
task beltMove()

//makes the belt go at precisely 1 revolution every 2 seconds.

{

  nMotorEncoder[belt] = 0;

  int deltaEncoder = 0;
  int previousEncoder = 0;
  float dps = 0.0;

  float kp = 0.06;

  time1[T1] = 0;

   while(true)
  {
    deltaEncoder = nMotorEncoder(belt) - previousEncoder;
    previousEncoder = nMotorEncoder(belt);
    dps = (deltaEncoder*1000.0)/time1[T1];
    time1[T1] = 0;
    beltSpeed += (180.0 - dps) * kp;
    motor[belt] = beltSpeed;

    wait1Msec(10);

  }

}


Sat Jun 23, 2012 1:02 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Troubles with encoders
First, you need to change all the encoder variables from int to long. Regarding the jumping around, we had the same problem with the FRC Rebound Rumble game where we had a high RPM motor with an optical encoder. It turns out that unless whatever you are spinning with the motor have enough mass (i.e. inertia), the CPU is controlling the speed with very high sensitivity. So in the first 10 msec, it may overshoot to 200 dps. It will then decrease the power to the motor and in the next 10 msec, it will undershoot to 100 dps. In other words, your PID control is oscillating. If that's the case, you should tune Kp way down and see if it will stabilize. For example, try Kp = 0.001. With low Kp, it will take some time to "ramp up speed" but it will make the speed more stable. Alternatively, if you understand PID control enough, you may want to introduce Kd to suppress the oscillation. Another way to do it is to increase the sampling period (decrease the sampling frequency) from 10 msec to say 50 msec. This essentially applies a low-pass filter to the encoder data. Yet another alternative is to explicitly apply a filter function to the encoder data (that's what we did in the Rebound Rumble game).


Sun Jun 24, 2012 2:37 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 26 posts ]  Go to page Previous  1, 2

Who is online

Users browsing this forum: No registered users and 2 guests


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

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.