Turning "Safety" Code

[FeuerMadchen]

Okay, so I'm new to programming for the robot (this is the first year that I've made a significant contribution), and I came up with a weird idea. What if an automatic "slow-down" was implemented into the robot during turns so that if the driver is less than capable (not saying ours is, just in general) of understanding that the robot needs to slow down for a turn, the robot would automatically slow down?

I outlined my thoughts in the following part of the code (which I put under void Teleop(void) ):

if(p1_x >= 0 && p1_x <= 56)
{
pwm13 - 20;
pwm15 - 40;
}
else if(p1_x >= 57 && p1_x <= 124)
{
pwm13 - 10;
pwm15 - 20;
}
else if(p1_x >= 125 && p1_y <= 129)
{
}
else if(p1_x >= 130 && p1_x <= 198)
{
pwm13 - 20;
pwm15 - 10;
}
else if(p1_x >= 199 && p1_x <= 255)
{
pwm13 - 40;
pwm15 - 20;
}

I don't know where to go from here. Maybe change it so that it only slows down while accelerating beyond a certain point?

(Feel free to use this if you want, by the way.)

[psy_wombats]

A few things:

You might not want to use set amounts subtracting from the pwms just because that will decrease the sensitivity, as in if the joystick is anywhere between 0 and 56, the speed will be the same. That assumes you aren't assigning the pwm anywhere else, and it's actually in neutral to begin with. If you are mapping the pwm to joystick elsewhere, you're going to run into problems with values going outside the expected range (negative values). Etiher way, it would probably be better to map the values and then multiply by a fraction to get the end result.

Also, this code doesn't only apply when turning. Keep in mind the subtraction will occur independant of the other side of the robot. Assuming you're using tank steering, the robot's max speed will have a reduction if the joysticks are at full forward. If you're using arcade steering, then you might want to check the y... It seems to be only referenced at the neutral point?

Have you tested this, by the way?

[Greg Marra]

Does the robot need to slow down for turns? I've never seen a robot tip itself from it's own G forces unless it had a large weight in the air.

[DonRotolo]

Testing is a good idea. You might be surprised how that code you wrote actually works.

Anyway, a different idea might be to divide the PWM values by some number when the driver pulls the joystick trigger (for example), or perhaps reduce the PWM values (subtract for over 127, add for under 127) by the difference between left and right joystick values, again maybe divided by some number.

In a different direction, we have traditionally found that drivers don't like anything between their joysticks and the robot. What would be better (in their opinion) would be more driving practice time. Consider: If they were able to drive for 150 hours, they'd be awfully darn good, eh?

In a still 'nuther direction: Use the gyroscope sensor to help the driver make the turn (and drive straight, too): If the driver pulls the trigger (or whatever) the robot makes a 180 degree left turn. Or maybe a 90 degree left turn, and they can do it twice. And, if the left and right joystick values are about equal, the gyro is used to slow the faster side down a hair to make the robot drive perfectly straight.

Just some things to play with.

If you don't have time to implement this for this season, then play with it outside this season, so you know how to do it for next season. For anything complex, the build season is not the time to be learning how to do it for the first time, the time for that is pre-season.

Don

[JohnC]

Originally Posted by Greg Marra

Does the robot need to slow down for turns? I've never seen a robot tip itself from it's own G forces unless it had a large weight in the air.

Like, for instance, a trackball?

[Branden Ghena]

I would be careful with this code, if you have "safety code" in, the driver won't be able to complete that quick turn when he really needs to.

[Nightfall831]

Originally Posted by Don Rotolo

Testing is a good idea. You might be surprised how that code you wrote actually works.

it's interesting how programmer's work...we write stuff, but never actually know if what we wrote is even close to correct. Usually ends in "Build Failed."...sigh....

[ebarker]

More ways to keep you thinking.

Figure out things like where the robots CG is and you could do something like mount an accelerometer on the bot, measure the g-forces while making the turn and limit the controls in real time to prevent an unwanted tip over when in a tight turn.

Yet another way is to put encoders on the wheels and calculate the speed and turn radius and limit the controls as in the above example.

Enforcing stability with your fly by wire system. It's great !!

[psy_wombats]

Just thinking about tipping forwards and backwards as well... You could try mounting a gyroscope vertically on the side of the robot (so that you sense angle to the ground,) and then move backwards or forwards to correct any tipping.

Although, that would also be annoying to the drivers...

[FeuerMadchen]

Originally Posted by psy_wombats

Although, that would also be annoying to the drivers...

I understand that our excellent driver might be a little peeved, but considering he's also our head programmer and gave me the thumbs-up to try the idea out, I have some justification.

Part of the reason I'm making this code is because last year our robot was very top-heavy, and fell over 2-3 times. The trackball is going to be a huge weight, so it'd be nice to have a backup if we try driving our robot and the driver needs an extra cushion for turns.

Also, I just thought of this a few days ago, so I couldn't have played around with it during pre-season. I have tested the basic code I posted, and the robot has one side's wheels turning slowly while the joystick is in the neutral position, and the other side's wheels not moving. I'm debugging that as we speak. Type. Post. You understand what I'm getting at.

It seems to work other than that little problem, though. I appreciate all of the ideas, and try a few out today.