Lag Issue

[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).