[OCCRA]: OCCRA OCT-NE 10/14/09 Basic VEX Workshop PDF

[marccenter]

OCCRA Teams,
Here's the VEX program used in the Basic Workshop that shows how to used a Start Switch with Digital Input 5 and a Stop Switch with Digital Input 6 for your 2009 OCCRA EasyC program.

[brickmaster2]

I am a little confused about the start switch. If we use a program like the one you posted, how are we supposed to start the robot in the actual competition?

When we use the switch program, as soon as auton ends, we have to hit the switch to do anything. If we need the start switch in the competition, the robot will be in the middle the field. How are we supposed to start it in that case?

Would we be allowed to program the robot so that as soon as auton ends, the driver has control, but the robot can be turned off by the stop button and then restarted with the start button?

[marccenter]

Good question, simple answer,
In the autonomous EasyC function, create the start/stop switch program.In Operator Control EasyC function, create the start/stop switch program, but
comment out the start switch function. This will allow the autonomous to operator control transition to eliminate the use of the start switch but will still allow you to "kill" the robot with a stop switch.

[brickmaster2]

Thanks for answering so quick. That makes things much clearer.

[apalrd]

Why not have the VEXnet field controller do its job and switch into autonomous as opposed to having another useless button on a robot (also hogging bumper/limit switches, which we need) . And is this really necessary with such small robots with such low power motors? I can see a stop button on a big robot, where spontaneously entering autonomous can cause the robot to drive really fast and cause a large amount of damage, but for this, seriously? And a start button? Even for home testing, you can map one of the DIO pins to enable autonomous (autonomous_mode = rc_dig_in16;), or buy that thing that enables robots and switches them into autonomous at the transmitter end (by replicating the field controller, equivalent to a competition dongle on the FRC system). It seems to me that this whole start switch is serious overkill. Why semi-auton instead of plain autonomous?

Clarification on the MPLAB sequential analog thing:
MPLAB requires us to call the function "Set_Number_Of_Analog_Channels(SIX_ANALOG);" in user_initialization() of user_routines.c where we replace "SIX_ANALOG" with the number of analog channels we need, just like the FRC controller. The function starts from 1 and sets the sequential IO ports to analog. No changing that, unless we go into the library. We need 3 line sensors (1 follow, 2 line trigger), a pot on the (*classified device*) and a pot for the auton selection. Plus one just to be safe. That makes 6. If we aren't safe, that still makes 5 and is still too many for the start and stop switches. (Not like the field controller will switch us into autonomous or anything)

[marccenter]

Andrew,
You've made some good points but are you able to view your position from the other side and articulate what advantages there may be to having a semi-autonomous switch initiated operation?

1) VEXnet system is new. What happens if many teams have major problems at this Saturday's OCCRA competition. What do we do? Penalize these teams? We can potentially fall back to crystal based templates and have students start the autonomous period simulataneously with Start Switch.

2) VEXnet system is new. I have never operated the system at an OCCRA competition. Don't you think the possibility of having hardware/software glitches may be present. We may be able to accomodate teams with both VEXnet operating and Crystal based templates using the Start Switch concept.

3) Last year we ran into problems with students trying to turn on the robot based on the VEX microcontroller power switch because it was buried in the robot. This year, VEX robots are even larger and it will be more difficult to start by turning on with the VEX power switch. From my perspective, the "Start Switch" is an effective surrogate from having a student turn on the VEX microcontroller based on a power switch that is buried in the robot.

4) Having a Stop or Kill Switch, I think makes sense no matter what size robot.

5) Using a Stop/Start Switch in the programming template is an effective way to demonstrate how to overcome a "typical" student problem associated with reading a switch and "latching" the event in a software variable for future use.

Your thoughts?

[iwanttodunk]

Ok. I agree with what you say. I Believe all Vexnet has caused for us is alot of stress. If we are unable to get vexnet operating saturday, playing the rounds with crystals would be almost required.

If VEXnet FAILS. (im sure it will)

It would be nice to know that we will be using crystals at the first competition.We all have clearly been under alot of stress, caused by vexnet.


I and my team are all for using crystals at saturdays compition. Its almost obvious we have a glitched vexnet because the lights go haywire whenever we do anything. and nothing has worked yet.

The only way we can come in and have a vex robot run is with the crystals.
Im sure most teams are only capable of running with crystals also.

[apalrd]

I followed the directions, and have had no problems at all with VEXnet. It runs just fine. It is the job of the field controller to start autonomous, thus there is no need for a start switch. Even with the crystals, the code should not need a start switch. The whole latching switch thing is why there are tutorials on programming for VEX. At this point, I can pretty much only capable of running with VEXnet without major code modification. Actually, the biggest software problem that I have had so far is that my Vista laptop dosen't like the Prolific USB driver from VEX, so I am using an old laptop with IFI loader to upload the hex files. Why does the position of the power switch matter? The stop switch does make sense; our 2008 FRC robot took off down the hall and turned left because someone hit the autononmous switch (which is under a missile-switch style cover) We still have this problem where we ran out of switches (We had 2 bumper and 2 limit switches, we used both the bumpers on our bumpers and the limit to detect a ball in the robot, leaving one limit switch for a stop switch). Can I just use one of the bumpers to start, then remove its starting duty?

//wait out the non-starting period
while(rc_dig_in11)
       ;

If there are VEXnet problems and crystals are used, will we be required to use crystals or can we still use VEXnet? We can pretty much only run on VEXnet.

iwanttodunk: The lights blink alot when starting up. They will start to blink faster when they find another VEXnet controller, and will turn green when they are linked. Just wait a few seconds. Have you updated the master code and your software? I love all of the new features the VEXnet has to offer, and am glad that we are using it this year. I hope that VEXnet is extended to include computer driver support. that would make me very happy.