Recently our team experienced a major malfunction due to tipping. Because the lift is not designed to handle a lot of tipping, we severely bent an entire stage of the lift due to a tipping accident. We are still recovering from it, fixing the potentiometers, wiring and elastic assist that used to be perfect.
Meanwhile I was thinking about the most efficient way to prevent tipping. Due to our need of getting into the tight corner and building skyrise, we are thinking of something less structural and more with sensors and program. So far I have mounted a gyroscope on top of the lift and written a little program that theoretically will work okay.
#pragma config(Sensor, in3, TopGyro, sensorGyro)
int gyrodisabler == 0; // declare disabling variable of the program
// I skipped all the gyro initialization and config lines... You know
// how to do that right?
// Background task that enables users to zero out gyroscope value
// with second joystick button. I wrote this as a part of the main loop
// in easy c and converted it... Possibly there is a better way in robot
// c to do this.
task TopGyroProcessingBlock ()
{
int currentvalue = 0;
while (true)
{
gyrooutput = SensorValue[TopGyro] - currentvalue ;
if (vexRT[Btn8UXmtr2] == 1)
{
currentvalue = SensorValue [TopGyro] ;
}
}
}
void holonomicbasecontrol ()
{
// I'll skip here... you know how holonomic base works
}
// Also... lines like moveforward () ; are the user functions I made for
// basic base movements because I refused to work with robotc's built in
// features... again, directly converting stuffs from easy c, where you had
// to do all of these... These functions are not included here but you get
// the meaning.
void basecontrol_antitipplugin ()
{
int uppertippinglimit = 250;
int lowertippinglimit = -400;
if (gyrodisabler == 0) // antitip automatically disabled
{
holonomicbasecontrol (); // because the base control block is
// not elegant at all as I wrote it as a
// beginner, I'll just skip sharing it...
}
else if (gyrodisabler == 1) // antitip enabled
{
if (gyrooutput > uppertippinglimit)
{
moveback (40); // not sure what to do when the robot
wait1Msec (700); // starts to tip... Maybe move base in
stopbase (); // opposite direction and then give it a
wait1Msec (1000);// second to recover...
}
else if (gyrooutput < lowertippinglimit)
{
moveforward (40); // Same here when the bot tips forward
wait1Msec (700);
stopbase ();
wait1Msec (1000);
}
else
{
holonomicbasecontrol ();// because the base control block is
// not elegant at all as I wrote it as a
// beginner, I'll just skip sharing it...
}
}
if (vexRT[Btn8DXmtr2] == 1) // joystick 2 button 8D enables/disables
// the protection program
{
if (gyrodisabler == 0)
{
gyrodisabler = 1;
wait1Msec (500) ;
}
else if (gyrodisabler == 1)
{
gyrodisabler = 0;
wait1Msec (500) ;
}
}
}
// main control loop
task usercontrol()
{
startTask(TopGyroProcessingBlock) ; // start processing gyro
while (true)
{
basecontrol_antitipplugin();
}
}
After messing around with the debugging stream for a while, I found that the gyroscope’s value varies a lot when the lift is fully raised, depending on how stable the lift is (our lift leans forward when loose), how many cubes the robot is carrying, and how the driver is driving it. Therefore it is kind of difficult to find an absolute threshold of tipping. I wonder if it will be better for me to just put the gyro on the base.
Any experience, thoughts, ideas and critique about gyroscope anti-tipping program, welcome to share.
Use an accelerometer and you will have better luck. We used one and made the robot almost impossible to tip, but it slowed down our speed a bit and we never tried dialing it in to find a happy medium between acceptable acceleration and being completely tip-proof. I think in retrospect that if we made the anti-tip code dependent upon the potentiometer value we could have had it to where it only enabled with the lift up which would have made it faster when just driving with the lift down.
Yes, we thought about only enabling the sensor when the potentiometer value is in certain range. But we had much trouble with potentiometers… if one dies, which they do do sometimes, the robot may turn into a crazy running machine.
Anyway thanks for the info. We will order some accelerometers and experiment.
Okay… this is smart. Why haven’t I thought about it… I’ll start integrating this into the base control block right away. Also I need to do a protection program also… if potentiometers go crazy I still need my full speed. Okay I am running out of buttons on my controllers and I am having trouble remembering what each button does, as I have a disable button for each single feature involving sensors…
Trust your sensors. While they do occasionally give bad readings, it is not very common if they are mounted and wired correctly. With the pots giving bad values, it is usually only at a very specific spot, and you would be extremely unlikely to hit it and stay there.
Also, if a pot is unplugged or faulty it will usually give a reading around 250. Therefore, if you have your code as:
if (potValue > [midHeight])
slow your drive
and so on...
and your pot were to be faulty, it would read ~250, which is less than your mid value anyways, so it treats it as if the lift were at the bottom, and it drives normally.
About the buttons, I would recommend putting those really small round stickers on them, and then you can colour code, label, number, letter, or whatever. Also, if you haven’t already, for sure make a reference sheet.
Thanks very much for the tips. They are really helpful.
The reason I started placing all protections is that after the described malfunction in the first post, we never got the potentiometers right until today. We had matches where the lift would not lower down itself because of a bad reading… which was awkward because the motors and strucures are perfectly fine.
The labling buttons idea is completely awesome! I really like the idea. Sounds very creative and fun. And you look like a pro with all green and red buttons!
for my anti tip code i put the gyro on the drive base there is a problem when you constantly try to tip your robot that the gyro will get a error and be a high number when leveled
while((SensorValue[tilt]>TIPPOINT)||(SensorValue[tilt]<-TIPPOINT))
{
if(SensorValue[tilt]>TIPPOINT)
{
driveSource(HALFSPEED,HALFSPEED);
if(nMotorEncoder[botLift]>0)
{
liftSource(-FULLSPEED);
}//end if
}//end if
if(SensorValue[tilt]<-TIPPOINT)
{
driveSource(-HALFSPEED,-HALFSPEED);
if(nMotorEncoder[botLift]>0)
{
liftSource(-FULLSPEED);
}//end if
}//end if
}//end while
tip point i set at 30 degrees and it should take over your controller till its leveled again and to also help lower the center of gravity it brings the arm down at full speed. i just have this code inside my user control before my controller input.
The pots may have been damaged in some way, which results in the above mentioned problem with incorrect values. To check if they read fine, we just made a simple program that is essentially:
while (bumper switch or button pressed)
Write Debug Stream Pot Value
Wait 50 msec
Then you just move the lift or pot while holding the switch and you can look at the values to find out if they have incorrect or jumping readings.
We never really confirmed this because we have not yet taken the broken pot off the broken sturcture, but very possibly we incorrectly installed the sensor and tuned it in a hurry and thus the lift drove over its range without us knowing it.
After the LCD display screen gets back in stock again, we plan to buy one and let it display all sensor values. Kind of like a debug stream built on the robot. Yeah I am one of two people on our team who are really interested in making robots perform above average and doing cool things.
While they do occasionally give bad readings, it is not very common if they are mounted and wired correctly. With the pots giving bad values, it is usually only at a very specific spot, and you would be extremely unlikely to hit it and stay there.