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

[marccenter]

OCCRA,
Here's a preliminary Adobe PDF copy of the powerpoint presentation that
I will be delivering on 10/14/09 at Oakland Schools Technical Campus - NorthEast.

[marccenter]

Heres a copy of the preliminary OCCRA 2009 Vex Inspection Sheet to help students keep focused.

[apalrd]

Great. It's nice to know the inspection rules while building

A few questions though:

VGR11 says that EasyC is the recommended programming language, not the required programming language. So are the the EasyC requirements only for teams using EasyC?

What if we must use DI 5 & 6 for analog ins? MPLAB requires that all Analog Ins be sequential starting from 1, and we need a bunch of analog ins. Dosen't the VEXnet field controller handle entering/exiting auton mode?

ALSO - it is confusing why we use crystals at home. VEXnet seems to be working fine so far.

[marccenter]

Andrew,
So, are you able to operate with the VEXnet programming template at your respective high school with the VEX robot? VEXnet is new to me this year as well and I have not experimented with it as much as some students -- like yourself.

The VEX Inspection template was created with EasyC software in mind, hence, digital inputs 5 & 6 for start and stop input,
button switches. I have created a programming example in the basic workshop on how to implement. Can you propose a modification to the MPLAB template for using a digital input for a start and stop switch? That info is not in front of me right now.

Vexnet software does switch between auton and remote control. Using start switch kind of promotes a semi-auton mode,
auton activates, then hit start switch to activate robot. (robot should not activate automatically with this feature ).

[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.