Lag Issue

[bizarospooky]

Our team is having an issue with we hit the joystick forward and then a few seconds later the motors go (like noticeably slower). We are trying to create a function to slowly ramp up the speed, and of course I'm using EasyC. I'm thinking (and have no access to the robot right now) that I know the problem and that it is I should add the variable outside the SetPWM (see the attached code)

[TubaMorg]

Look at your ramp functions. You need to rethink how you're doing that. Once you enter a loop, your program has to wait for it to finish before it can continue on, thus you get delays. Try, instead, to maintain a state variable that represents the current PWM input. Your joy values represent the desired PWM input.

psuedo code:

If pwmDesired > pwmActual then pwmActual += 2;
If pwmDesired < pwmActual then pwmActual -=2;

Add in some approprate limits etc. and it should react more quickly to user input.

[ericand]

We found that a lag function as TubaMorg described worked well. We tuned it such that full forward to full reverse took about .5 seconds.

Since you would be setting the PWM value in the slow loop that executes about 38 times/sec, that would give you an adjustment of about 13-14 towards the desired setting. (255/(38/2) = 13.4)

This does help avoid spinning the wheels and slamming the motors back and forth if the joysticks are bumped.

[bizarospooky]

neat so, baisically ignore the function stuff and do something like in the operator control

If(Joystick_1(that's the desired)>rampspeed(that's the actual? with it starting at 127))
{
rampspeed+=2
SetPWM(1, rampspeed)
}

Something like that?

[TubaMorg]

Originally Posted by bizarospooky

neat so, baisically ignore the function stuff and do something like in the operator control

If(Joystick_1(that's the desired)>rampspeed(that's the actual? with it starting at 127))
{
rampspeed+=2
SetPWM(1, rampspeed)
}

Something like that?

That will work, but I like how you break the steps out into functions. That's good style and will make it easier to tweak your code. Because you want to add limits (make sure rampspeed stays between 0 and 254), perhaps a deadband (127 +- 10 maybe), or maybe some PID (for greater control). Also consider how your code will handle different situations:

1. If you go from forward to reverse, do you really want to wait for your ramp to count through neutral before it changes direction?

2. If you are going full forward and need to stop (joystick in neutral) do you want to wait for the code to count to neutral?

Good luck!

[Alexa Stott]

Correct me if I'm wrong, but, because the joysticks are analog devices, couldn't you just have your driver slowly ramp up the speed manually?

It would make your job as a programmer much easier and give your driver something to practice other than making left turns for hours on end.

[TubaMorg]

Originally Posted by Alexa Stott

Correct me if I'm wrong, but, because the joysticks are analog devices, couldn't you just have your driver slowly ramp up the speed manually?

It would make your job as a programmer much easier and give your driver something to practice other than making left turns for hours on end.

You are correct. Joysticks are analog devices, however the analog signal is converted to a digital one which the program passes along as output to the Victor. Ideally you would like motor behavior to be linearly proportional to joystick input, but this isn't the case most of the time. Depending on robot and drive train design a small deflection from neutral joystick position can translate to a high speed reaction. Two-wheel drive robots with 2 motors on a single speed transmission often have this problem. Because of this drivers will find it impossible to have fine control of their robot because it goes from stop to very fast with very little user input.

The solution, therefore, is for the programmers to make the driver's job as easy as possible by providing a range of controllability (when desired) without sacraficing full speed and power. It is our view that controlling the robot should be as intuitive as possible so that robot responds as the driver desires in high-pressure game situations. The programmers on our team take input from the drivers seriously, because in the end they need to feel comfortable with the controls. This applies not only to how it drives, but which buttons should perform which actions.

[ericand]

Originally Posted by bizarospooky

neat so, baisically ignore the function stuff and do something like in the operator control

If(Joystick_1(that's the desired)>rampspeed(that's the actual? with it starting at 127))
{
rampspeed+=2
SetPWM(1, rampspeed)
}

Something like that?

That is the general idea. We actually did not take the joysticks directly either. We fit the joystick raw value to a curve such that large movements around neutral gave small changes in target speed, and small movements at the extreme ends gave larget changes in target speed.

For those that question ramping through zero on the way to reverse, we did do that, it helped avoid skidding/tipping. We had to work closely with the drivers though because a little ramp helps, but too much response lag makes controll feel mushy (hard to control).