My team has used pneumatics in the past, but we still have questions about them.
We know that the the single acting piston uses air to extend, and a spring to retract. The question is, if we had a button which when its pressed the piston will extend, but when it is not pressed the piston will just retract due to the spring, then are we wasting air if we are pressing the button down, to keep the piston extended.?
During the Frc game Ultimate Ascent, I know of teams who had after the buzzer hangs using pneumatics. They have pistons which they extend up before the match is over, then they drive into the level 1 hanging bar. Once the power is cut (Match ends), the piston retracts pulling the robot up. I know it may not be possible to use the Vex pistons for hanging like this, but I was wondering if it is possible programming wise. If it is possible, then would it have to be single acting or double acting?
Yes, possible, at least with ROBOTC, It may be with EasyC but they handle competition control in a weird way. ROBOTC has control over the digital IO ports even when competition control disables the motors and joysticks.
Thank you for the response. My team uses Robot C. How would one accomplish retracting a piston once the power is cut during a match? I’m not sure how to program in robot c to be able to tell that the match is going to end, or sense that power is cut.
Have a task running (make sure bStopTasksBetweenModes is false) and then monitor the flags bIfiRobotDisabled and bIfiAutonomousMode to detect when driver control ends.
Start a timer at the beginning of the driver control period and then trigger the pneumatics just before driver control ends.
Of course you could just manually activate the pneumatics near the end of the driver control period as well.
This code could be used for case 2.
task monitorCompetition()
{
// wait here until driver control ends
while (!bIfiRobotDisabled)
wait1Msec(50);
// trigger pneumatics (perhaps it needs to be 0)
SensorValue dgtl1 ] = 1;
// task ends
}
void pre_auton()
{
bStopTasksBetweenModes = false;
}
task autonomous()
{
// Auton code
}
task usercontrol()
{
// disable pneumatics
SensorValue dgtl1 ] = 0;
// start monitor task
StartTask( monitorCompetition );
// User control code here, inside the loop
while (true)
{
// driver control code here
wait1Msec(10);
}
}
This code could be used for case 3
task usercontrol()
{
// disable pneumatics
SensorValue dgtl1 ] = 0;
ClearTimer(T1);
// User control code here, inside the loop
while (true)
{
// monitor time 1:45 = 105 seconds = 105000mS
if( time1[T1] >= 104000 )
// enable pneumatics just before end
SensorValue dgtl1 ] = 1;
// driver control code here
wait1Msec(10);
}
}
Does it matter what type of piston we should use for case 2 and case 3?
I know that using the wait1Msec command in robot c is bad, because the performance would vary with voltage. That is why encoders are helpful, because you don’t have to rely on time. For case 3, would starting a timer at the beginning of driver control be bad because of varying voltage?
Lastly, besides the air needing to extend the single acting piston, why wouldn’t leaving the piston extended, require air?
Using wait1Msec in control loops is not bad, in fact, I would argue that it should be mandatory.
You are mixing time based autonomous, where motor power (and thus distance travelled) is proportional to battery voltage, with delays that allow the multi-tasking functionality of ROBOTC to work efficiently.
Most loops in ROBOTC should use wait1Msec to yield time back to other tasks, take a look at the series of posts in the ROBOTC programming tips thread on multi-tasking.
Timers do not vary with voltage, they are counters that increment under CPU control. All timing in the CPU is based on a quartz oscillator.
It requires air pressure, once activated the pressure should remain as long as there are no leaks.