Scripting in Easy C

VEX V5 Technical Support UNOFFICIAL Tech Support
#1

Hello Everyone,
I saw a video on youtube of someone using scripting on their robot to make it easier for the driver to drive. I am stuck trying to include a button from the vex net joystick in an if statement in my easy c v4 program. Do I have to set up each indivudal button somewhere in the program? If so, how do I do this? Thanks.

#2

If you go to the main page of the forum (the portal) and look to the right there is a VEX Code section and the first 2 codes posted are scripting templates you may want to give them a try or take a look at them and they may answer your question.

~DK

#3

Kevin: Not sure if you watched my video on scripting in USER mode using the Mentor Bobcat , but I have a some what detailed explanation on how team 599 does scripting and our template in my blog. As DK mentioned, this code is also in the vex code repository. The template has some overhead which allows a lot of versatility and an auto_debug mode that allows running autonomous scripts in USER mode… but you may not need the versatility and added complexity.

Ie if you just want an auto_lift function that goes to discrete positions with a button push, this can be done with just a function call. Here is some standalone auto_lift RobotC code which can be used to test moving a motor with a pot feedback.

Others have used a task call to run the function.

Although the code is not EasyC you can still follow the logic.

If your only question is how to interface a button in EasyC then there should be some Sample Code in the EasyC directory to do this. If you haven’t solved it yet, then post a snippet of what you want to do.

#4

Chris: I cannot find anything online on how to script in easy c. I would like to push a button such as 8 up on my joystick that causes the robot to automatically put our donut grabber to a certain height. If you could help me out with this, it would be great.
Thanks

#5

Have you tried wading through the RobotC auto_lift function I posted here? This is not really a script, it uses just a function call. The only thing different from EasyC are the motor and joystick calls. The logic is documented there.

However, lets start from the beginning and see where you are stuck:

  1. can you read a button push yet?
  2. do you have a lift position generated by either a potentiometer (pot) or encoder? If using a pot make sure that the lift mechanical stops are inside the pot range. We set the electrical limits within the mechanical limits but usually there is an inertial over shoot and you don’t want the pot taking the impact.
  3. do you have a deadzone on your lift joystick command? I test on this to disconnect the auto_lift if the driver inputs a manual command > 0.

If you are set with these, then we’ll proceed with the code:

Edit… Ok I took a little time to rewrite a portion of the blog code in EasyC for you… but its for V.5 Microcontroller. It tested ok, but there might be a few mislabels on the buttons. Hook a pot up to a motor, make sure positive motor cmd -> increasing pot values and try it out.

auto_lift.BDS
auto_lift.ECP

#6

i also had this issue last season but didnt get enough time to figure it out
i am a bit more ahead of kevin though

what i have already:
HOLD a button (ch5) and the arm will go to a potentiometer height ONLY IF the arm is higher than the set height…

what is preferred:
TAP a button (ch5) and the arm will go to the set height WHETHER higher or lower than the set height

hope i made sense…

#7

Good start… see my edit of my last post for EasyC sample code that works best if the button is not held:)

Edit: 1/7/2011… I fixed a bug in the program and updated it already. The link is still valid.

A note on how to tune the program. The lift is commanded at a fixed rate. This rate will cause an overshoot after the lift_goal is reached. The size of the overshoot depends on the lift inertia, the magnitude of the fixed rate and the motor drag torque. The LIFT_TOL is used to bias the target goal in a direction that anticipates the overshoot and shuts the lift rate off early.
You can get an idea of the overshoot by setting LIFT_TOL = 0 , pushing the select goal button and then looking at the difference between where the lift stopped relative to the lift goal position. Repeat this for both above and below goal starting conditions. You will find that the overshoot is a lot more for the down position due to the assistance of gravity.

Now you can set the LIFT_TOL equal to the overshoot in the up direction. To compensate for the extra overshoot in the down direction, you can increase LIFT_TOL to LIFT_TOL_DOWN =LIFT_TOL*factor. Use LIFT_TOL_DOWN in place of LIFT_TOL in the down direction error test. I.e. if(error <-LIFT_TOL_DOWN)) lift_cmd = -LIFT_RATE.

You can also keep the LIFT_TOL small and just adjust the goal heights. Probably would need separate heights for up and down directions.

If your overshoots are just too large , then you can lower your average rate or make the lift_rate = K*error and limit the rate to -127, 127]. This is essentially a PID loop without the I and D. K is just a gain constant. Sometimes, I also use a little timed speed reversal to assist in the braking of the arm.

#8

or lower than the set height
I told our D team to do this in RobotC-

You use an if statement to detect when the button is pressed first, and you start a timer (I told the programmer roughly 2-3 seconds), and set a value such as programprogram to one.
You then use another if statement to detect when the time is 2-3 seconds and programprogram is set to one.
Within this if statement, you place a while statement (because while statements always loop until true…) saying that while your current state is not at your wanted statement, do a certain function.
Remember to set programprogram to zero when done.

Sorry for my horrible pseudo. This did work for them however. One touch, and the arm raised all the way, until the resistance value was met to their needs.

#9

or lower than the set height
I told our D team to do this in RobotC-

You use an if statement to detect when the button is pressed first, and you start a timer (I told the programmer roughly 2-3 seconds), and set a value such as programprogram to one.
You then use another if statement to detect when the time is 2-3 seconds and programprogram is set to one.
Within this if statement, you place a while statement (because while statements always loop until true…) saying that while your current state is not at your wanted statement, do a certain function.
Remember to set programprogram to zero when done.

Sorry for my horrible pseudo. This did work for them however. One touch, and the arm raised all the way, until the resistance value was met to their needs.

  • Oh, I didn’t read vamfun’s post. :frowning:
#10

O.o
i never thought overshoot was THAT complicated…
when our arm went to the set value, it overshot, so we just fiddled with the value untill its just right (and it wasnt heavy/fast enough to make inertia have a big enough difference)
and i also thought of 2 values of overshoot if we had it going up as well as down

but durring the time the arm is positioning itself, we would still like to drive to the goal and other functions of the robot working
and if you wait 2-3 secs, doesnt that mean that the main control loop will be cut?
(unless that code (drive, ect) is also copied in the 2-3 sec loop)

thanks for all your advise, my team is currently going through the prototyping process again and when we get to the programming stage, ill be sure to check out all my options

#11

You could accomplish this task using a P-Loop using a Pot/Encoder and using an if statement to make the arm jump so many ticks by a button press.

There is a sample “PID Interrupt Service Routine” that does this using a button instead of the transmitter. The code is almost identical for the transmitter. By playing with the gain and max power you should be able to get some very good performance without much oscillation or overshoot.

To setup the code to poll a button you use “Get Joystick Digital” each button must be polled individually.

#12
  • Exactly, if your willing to copy the driver code. If not, then the way to go with less typing would be to place the driver code in a void data type.

I’m not sure how to do so in another way…

#13

If you are willing to have one button do only one thing (eg move arm to specific position) then you don’t need a statemachine or wait statements or loop delays, etc. untested Pseudo code:

while(1){
  do drive and other commands
  // set scripting options for arm based on buttons
  if button1 then   goalvar = highvalue;  script = 1;
  if button2 then   goalvar = lowvalue;   script = 1;
  if button3 then  script = 0; // cancel scripting
  // do scripting options for arm, or RC control if no scripting
  if script==1
    then set motor for arm to move arm feedback pot in direction of goalvar
    else set motor for arm per some RC stick
} //wend

Key features:

  • Multiple buttons (1,2) set the same goal variable to different values
  • Doesn’t care how many times you press the same button, (switch bounce)
  • Releasing the button does not reset the goal variable (single press/release works)
  • Button3 cancels scripting and restores joystick control
  • Very similar to Vamfun’s example auto_lift code, except:
    vamfun has joystick > deadband will override the script
    this version requires button to disable the script and enable joystick
#14