Programming Preset Heights in ROBOTC for VEX Robotics By George Gillard

Transcription

1 Programming Preset Heights in ROBOTC for VEX Robotics By George Gillard Introduction Programming a button that lifts an arm (or other mechanism for that matter) to a specific preprogrammed point can be a really useful tool for driving. It allows the driver to focus more on the other components of the robot (like driving the drive train) without having to worry about the arm, as it raises itself. These are presets, used across many teams in the VEX Robotics Competition, used for easier and more accurate driving control. In this guide I am attempting to use flowcharts to help illustrate the processes, so please excuse that a lot of space may be taken up by them! This guide is best viewed at a full screen width scale. Picking the right target The idea for a preset height it to be able to press a button and the arm will lift to a preprogrammed height, all by itself. To do this, we first need to recognise whether or not the driver is intending to drive the arm manually (through a joystick, for example), or through the preset control. For this we could use a Boolean variable, with a name such as presetactive, which remembers what we are wanting the robot to do. If the joystick has been moved, make this false, but if the button was pressed, make this true. Then, even if you are not moving the joystick or pressing a button at all, it will remember what you had been doing as the value for presetactive will not change, and so the code will continue that action (i.e. for the preset, if the button was pressed, you won t have to continue holding the button for the preset to still be active).

2 If we have multiple preset heights, we will also need another variable to store what target height we are intending when we press a button. Generally you would have a separate button for each height, but you could also have one button toggle through multiple targets. So, now once one of the preset buttons has been pressed, we need to decide what target we re wanting. So, if Button 1 has been pressed, the target could be a value of 1000, for example. If Button 2 has been pressed, the target could be a value of 2000, for example, and the same process would apply for any additional buttons. See the flowchart on the right. Now let s face it, that looks a bit messy. Instead of detecting if a button has been pressed AND THEN figuring out which button was pressed and therefore which target we re wanting, we can condense that into more simple steps (for example, if Button 1 has been pressed, presetactive = true, and also the target = 1000, all in one step). Additionally, if we re a bit sneaky we can even do away with the presetactive variable entirely, by just giving the value of target an unrealistic value (for example, -1, or even -1000) where presetactive previously would have been false. Later on, we can detect that if the value for target is less than zero, then clearly it s manual control (no preset in its right mind would have a negative value). A nicer, more simple, and more pleasing flowchart that illustrates this follows.

3 This seems a bit better, right?

4 Time to take action So now we should have a value for our target, which lets us know what we re wanting to do, and how high we re wanting to lift to. Time to do something about this now. The theory is quite simple. If the target is below zero (i.e. manual control, as decided in the first section), give the motors the manual control speed. Otherwise, give the motors a speed that will lift the arm towards the target height. A P controller generally works just fine for some teams, but you could use a more complicated controller if you chose to, such as a PID controller. For a P controller, the speed is equal to the error (the distance between where the arm is and where you want it to be), multiplied by a constant, kp. You could either write this as: error = target sensor; Or, more simply: motor = error * kp; motor = (target sensor) * kp; For more information about P and PID controllers, see my guide An Introduction to PID Controllers. You could put this into a function (definitely recommended for more complicated controllers, like a PID controller), or you could just just directly give the motors the speed appropriate for the preset, straight into the driver control code, which works just fine for a simple calculation like that above. If you do use a function, make sure you don t include a loop that refreshes the controller as the robot will get stuck in this, and it is unnecessary since the main driver control loop will do this job for you. So our flowchart (and code) would look a little along these lines:

5 Below is code for ROBOTC that would do the job. task main() is being used but in a competition template this would be task user_control(). A variable target is created to store the target height for the preset. Ch2 is the manual control, and Btn8R and Btn8U are the two preset heights. There are two lift motors here, leftlift and rightlift, and a potentiometer is used as the sensor, named liftpot. The constant term for the proportional control is kp. int target; task main() while (true) if ( abs(vexrt[ch2]) > 20) target = -1; //Manual else if ( vexrt[btn8r] ) target = 1000; //Preset 1 else if ( vexrt[btn8u] ) target = 2000; //Preset 2 if ( target < 0 ) //Manual Control motor[leftlift] = vexrt[ch3]; motor[rightlift] = vexrt[ch3]; else //Preset Control motor[leftlift] = (target SensorValue(liftPot)) * kp; motor[rightlift] = (target SensorValue(liftPot)) * kp; I hope this guide has been helpful, please contact me if you have found any errors, faults, or issues in this. Good luck!