OKBEST ran across this problem last year, though apparently not to
this degree.  This year, the solution was to 'confiscate' all the keys
from all teams, and then to 'issue' a set of keys to each team as they
took the field just before each match.  My understanding is that they
felt that other teams not competing in fairly close proximity was
generating the interference, when they didn't shut down their robots
between matches.  By keeping all non-competing robot keys away from
the non-competing robots, they eliminated this possible source of
interference.  It seemed to work pretty well during their competition.

After 13 years of preparing teams for the wonderful BEST competition, this
year's competition was an absolute disaster due to linking problems with the VEX
cortex and transmitters.  Our rookie freshman team went in to the competition
with a well-designed and executed robot.  It was capable of caputuring all types
of escaped insects and returning them to all containment areas with food, but
after 14 rounds our score remained at ZERO.  In fact, after the preliminaries,
there were only 5 teams with scores not zero.   That does not reflect the
quality of their robots, but the problems with the system.

At school the systems all worked well, with a tether, all worked well and in the
pit areas all worked well, but 40 feet way from the pit area, in the competition
arena, the lights went red and communications were lost.  Time after time for 14
rounds this happened.  Only during one round was communications held and even in
that round the it was faulty.

The team did everything they knew they could do from reinstalling the firmware,
resetting the cortex, switching from tether to comm-linkage over and over again
to no avail.  It was not just our team either, no team survived all the matches.
The communications was awful and the team's morale was trampled through no fault
of their own.

Survival in rounds depended solely on commucations within the VEX system, it had
nothing to do with 6 weeks of planning, designing, developing, engineering,
re-designing, testing, re-testing, study, practice, construction or any of the
other attributes that makes BEST such a wonderful event.

Our teams should have been given an opportunity to move to another HUB venue if
they so desired, but that was not an option.  All the teams, save the
championship team, dismantled their entries and left the venue with heads hung
low.....it was a long, sad trip home.

I will add that North Houston Hub Director Paul and assistant G.J. did all they
could to help the situation and they bore the brunt of all the teams' anger and
frustrations.  It was totally unfair to them as well.  Over they years, these
two have worked hard to insure the best for our kids.  My apologies to them for
any frustration I may have vented on them.

On to next year!

SA-BEST completed our HUB competition this past Sat, Oct 15, 2011! It was
exciting and spirit filled! Just check out www.sabest.org (and get a peak at
your competiton!) Thanks to each of the SABEST all volunteer crew that made
things so smooth as possible along with St. Mary's Univ staff and students, too.
Also thanks to sponsors and organizations providing awards and scholarships. (1)
What a great experience for our two rookie teams (one each HS and MS) that our
veteran team guided! It was a great experience for us too. Even if our teams did
not qualify for REGIONALS. We all won because we have returning students (to
include our rookie teams!) that want more robotics and they'll tell their
friends and family. (2) One great experience was how the rookie schools had few
tools to cut their consumables into their robot parts.  The HS was invited to
come and learn to cut their parts at our school. While the MS "contracted" with
our team to cut their parts which they assembled. (3) Regarding the
matriculation of qualifying teams from HUB to REGIONAL there once was a document
in the BEST-File Manager - "HUB OPERATIONS" that outlined this process. Or just
contact your HUB. I haven't seen either a similar document for REGIONAL to
"WORLD" (Will it be Disney Land Apr 2012?). (4) Another tricky situation that is
covered in same document is the rubric for selecting which teams do qualify and
move onto REGIONALS / "WORLD". Consider teams with dual placement on BEST Award
and Game results. Hmmm?  It's no longer the top 2 in each category or what we've
understood. (5) Regarding lack of connection. Our team and the MS had not such
problem.  In fact our rookie MS moved onto Semifinals and we cheered them on!
But, our HS team had similar connection problems and with a combined HUB trouble
shooting lead to key and battery charge issues.  Our Hub provided plug-in
adapters for the controllers if the team wanted to.  The team did not use them
for the first three matches. Along with key replacments (that thumb drive device
plugs into Cortex and conroller), it seemed to have solved the problem
afterwards.(6)BEST Blessings to all till next BEST season for us BUT we'll
follow the REGIONALS (awaiting the 2012 game teaser) and slumber till "WORLD".

We also had several problems with 'communication dropping'.  This seemed to be
related to just a few teams.  In all the cases that I troubleshot, either the
Joystick or robot battery lights were red or we found a bad VexNet key.
   I recommend that the backup battery be used.  This provided backup power to
the Cortex and VexNet key should the main robot battery voltage drop under heavy
load (or poor charge).
   The new NiMH batteries don't develop 'memory' nearly as bad as the old NiCd
batteries, but they do need some maintenance to be at peak charge for game day.
   A couple teams neglected their Joystick batteries (yellow or red Joystick
LED).   We had AC adapters on the field for the Joysticks.
   The VexNet keys seem to have some reliability issues.  The keys are not very
secure and do protrude. They can be physically damaged if not protected.  Also,
remember to turn the Joystick power OFF before removing or installed the keys.
Most times you might not damage a key, but there's no guarantee.
   Don't be discouraged. This is only the second year with the Vex system and
we're still learn the quirks.

Mike


--- In bestinc@yahoogroups.com, "ripphyzard" <srippetoe@...> wrote:
>
> So today was the second most frustrating day of BEST I have experienced in the
past ten years. Every round had robots not running because the VEX joystick lost
comm with the Cortex controller, except for one preliminary round. We had comm
in our first semifinal round and half of our second. We only had comm for one
minute in the three rounds of the finals. We only had six out of fourteen rounds
with radio comm for the entire round. To my knowledge, every team experienced
similar issues, though we had our worst problems after the preliminary rounds.
>
> Another team went through all three semifinal rounds without ever having radio
comm. Yet another missed a round of the finals because of the lack of radio
comm. Some rounds only had one of four robots running, all the result of the
radio systems not linking.
>
> After we were finished today, I just could not imagine spending six weeks next
year working with the kids to put a robot together to go through a similar
experience. VEX and BEST need to find a solution. The communication problems are
well documented on the VEX forums.
>
> There is an upside to this disaster. At dinner this evening the team told me
how much they enjoyed the past six weeks.
>

 

So today was the second most frustrating day of BEST I have experienced in the past ten years. Every round had robots not running because the VEX joystick lost comm with the Cortex controller, except for one preliminary round. We had comm in our first semifinal round and half of our second. We only had comm for one minute in the three rounds of the finals. We only had six out of fourteen rounds with radio comm for the entire round. To my knowledge, every team experienced similar issues, though we had our worst problems after the preliminary rounds.

Another team went through all three semifinal rounds without ever having radio comm. Yet another missed a round of the finals because of the lack of radio comm. Some rounds only had one of four robots running, all the result of the radio systems not linking.

After we were finished today, I just could not imagine spending six weeks next year working with the kids to put a robot together to go through a similar experience. VEX and BEST need to find a solution. The communication problems are well documented on the VEX forums.

There is an upside to this disaster. At dinner this evening the team told me how much they enjoyed the past six weeks.

I had previously checked with our school district because of problems we
had using our FIRST driver station. It operates in the 2 GHz range like
VEX. We have no active suppression system. When we switched our FIRST
driver station to a laptop with wireless operating in the 5GHz range,
our problems disappeared.

A search for "VEXnet problems" on the VEX Forum shows this is not an
isolated incident or problem. I remember matches being rerun if it was
determined that the field system had lost communication with a robot
using the Futaba controller system. Not so with VEXnet. Of course, you
can't rerun nearly 30 matches.

We are in the North Houston hub.

--- In bestinc@yahoogroups.com, Michael Carroll <mjcarroll@...> wrote:
>
> I'm surprised to hear this.  Part of the reason for the move to VEX
was to
> reduce radio interference problems that we have had in years past with
the
> old-style Futaba receivers.
>
> Last year at South's BEST, we ran 60 teams through (with up to 8 at a
time
> on-field) with no interference problems.
>
> It sounds like the venue may have had some sort of active Wifi
suppression
> system (I've heard of them, never seen one in action) and perhaps this
was
> the cause of the radio failures?  I can't think of any of our regional
> venues having these sorts of issues.  What hub are you from?
>
> ~mc
>
> On Sat, Oct 15, 2011 at 23:45, ripphyzard srippetoe@... wrote:
>
> > **
> >
> >
> > So today was the second most frustrating day of BEST I have
experienced in
> > the past ten years. Every round had robots not running because the
VEX
> > joystick lost comm with the Cortex controller, except for one
preliminary
> > round. We had comm in our first semifinal round and half of our
second. We
> > only had comm for one minute in the three rounds of the finals. We
only had
> > six out of fourteen rounds with radio comm for the entire round. To
my
> > knowledge, every team experienced similar issues, though we had our
worst
> > problems after the preliminary rounds.
> >
> > Another team went through all three semifinal rounds without ever
having
> > radio comm. Yet another missed a round of the finals because of the
lack of
> > radio comm. Some rounds only had one of four robots running, all the
result
> > of the radio systems not linking.
> >
> > After we were finished today, I just could not imagine spending six
weeks
> > next year working with the kids to put a robot together to go
through a
> > similar experience. VEX and BEST need to find a solution. The
communication
> > problems are well documented on the VEX forums.
> >
> > There is an upside to this disaster. At dinner this evening the team
told
> > me how much they enjoyed the past six weeks.
> >
> >
> >
>

Your problem has been interesting, though very unfortunate. I say interesting
because last year, we had very occasional problems with connections using the
VEX system, to where we we never needed to pursue a solution. This year,
however, ever since we've gotten a working robot two weeks ago, we've had
constant issues with the robot disconnecting from the joystick. Sometimes it
would reconnect, others it wouldn't. Through the troubleshooting process, we
replaced a suspected faulty USB dongle (which disconnected every time it was
tapped), a joystick (which ceased to connect to the computer after repetitively
trying to update the firmware), a battery (which we thought had a bad
connector), and finally a battery adapter/connector (which we finally discovered
was causing problems, as the wire slipped right out while replacing the
battery).

Although we haven't had time to test to see whether the connector was the
problem, I do know that we were still experiencing disconnection problems with a
different battery connector, different battery, different USB dongle, and
different joystick. Finally, at mall day yesterday one of the officials brought
to our attention the fact that the USB dongle is very sensitive, and being so
close to the Cortex where all of the current is being drawn from disrupts the
signal, causing it to randomly disconnect while driving. This year's Cortex's
apparently have raised USB plugs to try to eliminate the issue, but we have an
old one. He suggested shielding the dongle by wrapping aluminum foil or some
other shield around the underside (but not the top) of the USB dongle. The
official BEST solution is apparently using the USB extension cable to move the
USB dongle away from the Cortex. It is also important to make sure it is away
from motors (and probably wires) too, because motors have a strong
electromagnetic field that could easily disrupt the USB dongle. After hearing
about this, we used the adapter to mount the key on our arm; the furthest from
the electronics it could get.

Although the VEX system has brought some good advantages, it has had a lot of
inherent problems, which take a ton of time to work around. The past two years
our largest problem hasn't been a design that can't score, but rather working
around VEX-related issues. For example, last year we burnt out a Cortex and
caused multiple servos to strip by doing the same thing we'd done in past years.
Thankfully, VEX has worked with BEST to solve these issues, and continues to do
so. The BEST competition tends to be very hard on returnable components, much
more so than the VEX Robotics Competition. I don't think VEX quite had a handle
on what they were getting into when they designed components for the BEST
competition.

As a senior, I think the competition has been completely worth it every year
since I joined 6 years ago. Although things have changed a lot, it is still a
great learning experience, with many challenges.

--- In bestinc@yahoogroups.com, "ripphyzard" <srippetoe@...> wrote:
>
> So today was the second most frustrating day of BEST I have experienced in the
past ten years. Every round had robots not running because the VEX joystick lost
comm with the Cortex controller, except for one preliminary round. We had comm
in our first semifinal round and half of our second. We only had comm for one
minute in the three rounds of the finals. We only had six out of fourteen rounds
with radio comm for the entire round. To my knowledge, every team experienced
similar issues, though we had our worst problems after the preliminary rounds.
>
> Another team went through all three semifinal rounds without ever having radio
comm. Yet another missed a round of the finals because of the lack of radio
comm. Some rounds only had one of four robots running, all the result of the
radio systems not linking.
>
> After we were finished today, I just could not imagine spending six weeks next
year working with the kids to put a robot together to go through a similar
experience. VEX and BEST need to find a solution. The communication problems are
well documented on the VEX forums.
>
> There is an upside to this disaster. At dinner this evening the team told me
how much they enjoyed the past six weeks.
>

Anyone else having issues with speed controllers on the drive wheels/big drive
motors burning out while the students are driving the robot? We have had 3 go
out so far. One during competition.

It may be related to freshly charged battery?

I'm surprised that you're surprised.  we competed at auburn and had connection
problems.  our hub even sent an extra wifi key with us because of all the
problems we had before, during, and after the hub competition.  we even received
a penalty during the competition at Auburn due to these problems.  Besides not
having enough money after going to Orlando, that was the main reason we did not
buy the robot kit last year.

Sent from my Verizon Wireless Phone

Michael Carroll <mjcarroll@...> wrote:

>I'm surprised to hear this.  Part of the reason for the move to VEX was to
>reduce radio interference problems that we have had in years past with the
>old-style Futaba receivers.
>
>Last year at South's BEST, we ran 60 teams through (with up to 8 at a time
>on-field) with no interference problems.
>
>It sounds like the venue may have had some sort of active Wifi suppression
>system (I've heard of them, never seen one in action) and perhaps this was
>the cause of the radio failures?  I can't think of any of our regional
>venues having these sorts of issues.  What hub are you from?
>
>~mc
>
>On Sat, Oct 15, 2011 at 23:45, ripphyzard <srippetoe@...> wrote:
>
>> **
>>
>>
>> So today was the second most frustrating day of BEST I have experienced in
>> the past ten years. Every round had robots not running because the VEX
>> joystick lost comm with the Cortex controller, except for one preliminary
>> round. We had comm in our first semifinal round and half of our second. We
>> only had comm for one minute in the three rounds of the finals. We only had
>> six out of fourteen rounds with radio comm for the entire round. To my
>> knowledge, every team experienced similar issues, though we had our worst
>> problems after the preliminary rounds.
>>
>> Another team went through all three semifinal rounds without ever having
>> radio comm. Yet another missed a round of the finals because of the lack of
>> radio comm. Some rounds only had one of four robots running, all the result
>> of the radio systems not linking.
>>
>> After we were finished today, I just could not imagine spending six weeks
>> next year working with the kids to put a robot together to go through a
>> similar experience. VEX and BEST need to find a solution. The communication
>> problems are well documented on the VEX forums.
>>
>> There is an upside to this disaster. At dinner this evening the team told
>> me how much they enjoyed the past six weeks.
>>
>>
>>

In San Antonio, we had 4 motor controllers returned.  On had the case broken
open.  I haven't had a chance to check them out yet.

Mike

--- In bestinc@yahoogroups.com, "Tammie" <tammie.friberg@...> wrote:
>
> Anyone else having issues with speed controllers on the drive wheels/big drive
motors burning out while the students are driving the robot? We have had 3 go
out so far. One during competition.
>
> It may be related to freshly charged battery?
>

Like you, we had problems after we built our robot and tried all the fixes you
described, to no avail.

My hub must not have gotten the "memo" that a usb extension was the official
BEST solution. We asked to do this during our hub competition and were not
allowed to.

--- In bestinc@yahoogroups.com, "seancsnm" <sean@...> wrote:
>
> Your problem has been interesting, though very unfortunate. I say interesting
because last year, we had very occasional problems with connections using the
VEX system, to where we we never needed to pursue a solution. This year,
however, ever since we've gotten a working robot two weeks ago, we've had
constant issues with the robot disconnecting from the joystick. Sometimes it
would reconnect, others it wouldn't. Through the troubleshooting process, we
replaced a suspected faulty USB dongle (which disconnected every time it was
tapped), a joystick (which ceased to connect to the computer after repetitively
trying to update the firmware), a battery (which we thought had a bad
connector), and finally a battery adapter/connector (which we finally discovered
was causing problems, as the wire slipped right out while replacing the
battery).
>
> Although we haven't had time to test to see whether the connector was the
problem, I do know that we were still experiencing disconnection problems with a
different battery connector, different battery, different USB dongle, and
different joystick. Finally, at mall day yesterday one of the officials brought
to our attention the fact that the USB dongle is very sensitive, and being so
close to the Cortex where all of the current is being drawn from disrupts the
signal, causing it to randomly disconnect while driving. This year's Cortex's
apparently have raised USB plugs to try to eliminate the issue, but we have an
old one. He suggested shielding the dongle by wrapping aluminum foil or some
other shield around the underside (but not the top) of the USB dongle. The
official BEST solution is apparently using the USB extension cable to move the
USB dongle away from the Cortex. It is also important to make sure it is away
from motors (and probably wires) too, because motors have a strong
electromagnetic field that could easily disrupt the USB dongle. After hearing
about this, we used the adapter to mount the key on our arm; the furthest from
the electronics it could get.
>
> Although the VEX system has brought some good advantages, it has had a lot of
inherent problems, which take a ton of time to work around. The past two years
our largest problem hasn't been a design that can't score, but rather working
around VEX-related issues. For example, last year we burnt out a Cortex and
caused multiple servos to strip by doing the same thing we'd done in past years.
Thankfully, VEX has worked with BEST to solve these issues, and continues to do
so. The BEST competition tends to be very hard on returnable components, much
more so than the VEX Robotics Competition. I don't think VEX quite had a handle
on what they were getting into when they designed components for the BEST
competition.
>
> As a senior, I think the competition has been completely worth it every year
since I joined 6 years ago. Although things have changed a lot, it is still a
great learning experience, with many challenges.
>
> --- In bestinc@yahoogroups.com, "ripphyzard" <srippetoe@> wrote:
> >
> > So today was the second most frustrating day of BEST I have experienced in
the past ten years. Every round had robots not running because the VEX joystick
lost comm with the Cortex controller, except for one preliminary round. We had
comm in our first semifinal round and half of our second. We only had comm for
one minute in the three rounds of the finals. We only had six out of fourteen
rounds with radio comm for the entire round. To my knowledge, every team
experienced similar issues, though we had our worst problems after the
preliminary rounds.
> >
> > Another team went through all three semifinal rounds without ever having
radio comm. Yet another missed a round of the finals because of the lack of
radio comm. Some rounds only had one of four robots running, all the result of
the radio systems not linking.
> >
> > After we were finished today, I just could not imagine spending six weeks
next year working with the kids to put a robot together to go through a similar
experience. VEX and BEST need to find a solution. The communication problems are
well documented on the VEX forums.
> >
> > There is an upside to this disaster. At dinner this evening the team told me
how much they enjoyed the past six weeks.
> >
>

One burned out on our team during one of the seeding rounds in our hub
competition... I would bet that the 3+ amp stall current that those large motors
pull plus the massive back emf they generate when the robot takes off (everybody
uses the big motors to drive their wheels) is just too much for those poor
little motor controllers...

Are there beefier motor controllers available from vex? If not it may be cheaper
to just allow motor ports 1 and 10 again, rather than having to replace those
motor controllers periodically.

By the way, our motor controller failing in that one round in no way ruined our
day... We all had a great time, and I am very thankful to the guys who volunteer
to get all of these kits together... y'all are doing a great job!


--- In bestinc@yahoogroups.com, "Tammie" <tammie.friberg@...> wrote:
>
> Anyone else having issues with speed controllers on the drive wheels/big drive
motors burning out while the students are driving the robot? We have had 3 go
out so far. One during competition.
>
> It may be related to freshly charged battery?
>

Our team had wifi linking problem after we updated the mastercode. When we
rolled the mastercode back to the version that is on the cd's that our hub
provided, everything worked just fine... the mastercode might be a source of
your problems...

--- In bestinc@yahoogroups.com, Lori Jack <mail4jacks@...> wrote:
>
> I'm surprised that you're surprised.  we competed at auburn and had connection
problems.  our hub even sent an extra wifi key with us because of all the
problems we had before, during, and after the hub competition.  we even received
a penalty during the competition at Auburn due to these problems.  Besides not
having enough money after going to Orlando, that was the main reason we did not
buy the robot kit last year.
>
> Sent from my Verizon Wireless Phone
>
> Michael Carroll <mjcarroll@...> wrote:
>
> >I'm surprised to hear this.  Part of the reason for the move to VEX was to
> >reduce radio interference problems that we have had in years past with the
> >old-style Futaba receivers.
> >
> >Last year at South's BEST, we ran 60 teams through (with up to 8 at a time
> >on-field) with no interference problems.
> >
> >It sounds like the venue may have had some sort of active Wifi suppression
> >system (I've heard of them, never seen one in action) and perhaps this was
> >the cause of the radio failures?  I can't think of any of our regional
> >venues having these sorts of issues.  What hub are you from?
> >
> >~mc
> >
> >On Sat, Oct 15, 2011 at 23:45, ripphyzard <srippetoe@...> wrote:
> >
> >> **
> >>
> >>
> >> So today was the second most frustrating day of BEST I have experienced in
> >> the past ten years. Every round had robots not running because the VEX
> >> joystick lost comm with the Cortex controller, except for one preliminary
> >> round. We had comm in our first semifinal round and half of our second. We
> >> only had comm for one minute in the three rounds of the finals. We only had
> >> six out of fourteen rounds with radio comm for the entire round. To my
> >> knowledge, every team experienced similar issues, though we had our worst
> >> problems after the preliminary rounds.
> >>
> >> Another team went through all three semifinal rounds without ever having
> >> radio comm. Yet another missed a round of the finals because of the lack of
> >> radio comm. Some rounds only had one of four robots running, all the result
> >> of the radio systems not linking.
> >>
> >> After we were finished today, I just could not imagine spending six weeks
> >> next year working with the kids to put a robot together to go through a
> >> similar experience. VEX and BEST need to find a solution. The communication
> >> problems are well documented on the VEX forums.
> >>
> >> There is an upside to this disaster. At dinner this evening the team told
> >> me how much they enjoyed the past six weeks.
> >>
> >>
> >>
>

We checked for connection before the other robots arrived in the pits that
morning. We had connection for about 3 minutes, then it was gone. We lost
connection in 3 of 8 preliminary rounds, 2 of 3 semifinal rounds, and 2 of 3
final rounds.

--- In bestinc@yahoogroups.com, Sean Shenold <sean.shenold@...> wrote:
>
> OKBEST ran across this problem last year, though apparently not to
> this degree.  This year, the solution was to 'confiscate' all the keys
> from all teams, and then to 'issue' a set of keys to each team as they
> took the field just before each match.  My understanding is that they
> felt that other teams not competing in fairly close proximity was
> generating the interference, when they didn't shut down their robots
> between matches.  By keeping all non-competing robot keys away from
> the non-competing robots, they eliminated this possible source of
> interference.  It seemed to work pretty well during their competition.
>

We've had no speed controller issues this year, but we did last year (we wired 2
motors to a single speed controller, overloading the controller). The speed
controllers are, however, quite sensitive. They have a peak amperage of around 3
amps if I remember right, and anything past that for more than a split second
will start to burn the controller out. This peak amperage can accidentally be
exceeded when one of the large motors stalls out.

To troubleshoot the issue, I'd check a few things.
-Make sure no more than 1 motor is connected to a single speed controller
-Make sure you aren't stalling motors out. If the drive motors are getting
stalled out, it may mean a change needs to be made in driving technique. Small
motors being stalled out shouldn't cause an issue, but it might.
-Double-check your wiring and soldering jobs, especially on the controllers that
are burning out. There may be solder joints touching the motor housing, causing
a partial short circuit. This process may be aided by using a multimeter to test
the amperage running through each circuit when the motor is moving full speed.

Finally, if something is connected or wired improperly, then the increased
amperage of a fresh battery could be causing problems. If everything is done
correctly, a fresh battery won't cause any issues.

--- In bestinc@yahoogroups.com, "Tammie" <tammie.friberg@...> wrote:
>
> Anyone else having issues with speed controllers on the drive wheels/big drive
motors burning out while the students are driving the robot? We have had 3 go
out so far. One during competition.
>
> It may be related to freshly charged battery?
>

I'm pretty sure that ports 1 and 10 on the Cortex have the same chip used in the
external speed controller - the external controllers are  cheap fuses relative
to the cost of the Cortex.

--- In bestinc@yahoogroups.com, "Lucas" <thomas03@...> wrote:
>
> One burned out on our team during one of the seeding rounds in our hub
competition... I would bet that the 3+ amp stall current that those large motors
pull plus the massive back emf they generate when the robot takes off (everybody
uses the big motors to drive their wheels) is just too much for those poor
little motor controllers...
>
> Are there beefier motor controllers available from vex? If not it may be
cheaper to just allow motor ports 1 and 10 again, rather than having to replace
those motor controllers periodically.
>
> By the way, our motor controller failing in that one round in no way ruined
our day... We all had a great time, and I am very thankful to the guys who
volunteer to get all of these kits together... y'all are doing a great job!
>
>
> --- In bestinc@yahoogroups.com, "Tammie" <tammie.friberg@> wrote:
> >
> > Anyone else having issues with speed controllers on the drive wheels/big
drive motors burning out while the students are driving the robot? We have had 3
go out so far. One during competition.
> >
> > It may be related to freshly charged battery?
> >
>

To aid in the development of the software that runs our robot, the ThunderRidge Robotics Club created a small API that handles some of the basic functions that we needed, and we feel that it will be helpful to other teams trying to get their robot's programming finished. So, we decided to release the our code (below). It includes several utility functions and shows how to use them in the code.

It covers...

• Arcade Drive
• Limit Switchs
• Clamping Values
• Reading all of the values from the joystick
• Vector classes
• Updating Inputs and Outputs
• etc...

#pragma config(Sensor, dgtl1,  Digital1,            sensorDigitalIn)
#pragma config(Sensor, dgtl2,  Digital2,            sensorDigitalIn)
#pragma config(Sensor, dgtl3,  Digital3,            sensorDigitalIn)
#pragma config(Sensor, dgtl4,  Digital4,            sensorDigitalIn)
#pragma config(Sensor, dgtl5,  Digital5,            sensorDigitalIn)
#pragma config(Sensor, dgtl6,  Digital6,            sensorDigitalIn)
#pragma config(Motor,  port1,           Motor1,        tmotorNormal, openLoop)
#pragma config(Motor,  port2,           Motor2,        tmotorNormal, openLoop)
#pragma config(Motor,  port3,           Motor3,        tmotorNormal, openLoop)
#pragma config(Motor,  port4,           Motor4,        tmotorServoStandard, openLoop)
#pragma config(Motor,  port5,           Motor5,        tmotorServoStandard, openLoop)
#pragma config(Motor,  port6,           Motor6,        tmotorServoStandard, openLoop)
#pragma config(Motor,  port7,           Motor7,        tmotorServoStandard, openLoop)
#pragma config(Motor,  port8,           Motor8,        tmotorNormal, openLoop)
#pragma config(Motor,  port9,           Motor9,        tmotorNormal, openLoop)
#pragma config(Motor,  port10,          Motor10,       tmotorNormal, openLoop)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

#pragma platform(VEX)

//Competition Control and Duration Settings
#pragma competitionControl(Competition)
#pragma autonomousDuration(20)
#pragma userControlDuration(120)

#include "Vex_Competition_Includes.c"   //Main competition background code...do not modify!

// Some Basic Typedefs
#define TRUE 1
#define FALSE 0
#define true 1
#define false 0

//////////////////////////////////////////////////////////////////////////////////////////
//
//                              Outputs Definitions
//
// Modify these to match the setup of your outputs. The ports match those found on the VEX Unit
//
///////////////////////////////////////////////////////////////////////////////////////////////
#define OUTPORT1DEF unused
#define OUTPORT2DEF left_drive_motor
#define OUTPORT3DEF arm_elevation_motor
#define OUTPORT4DEF brake_servo
#define OUTPORT5DEF gripper_servo
#define OUTPORT6DEF unused2
#define OUTPORT7DEF unused3
#define OUTPORT8DEF arm_extension_motor
#define OUTPORT9DEF right_drive_motor
#define OUTPORT10DEF unused4

//////////////////////////////////////////////////////////////////////////////////////////
//
//                              Digital Input Definitions
//
// Modify these to match the setup of your Inputs. The ports match those found on the VEX Unit
//
///////////////////////////////////////////////////////////////////////////////////////////////
#define INDIGITAL_PORT1DEF min_elevation_limit_switch
#define INDIGITAL_PORT2DEF max_elevation_limit_switch
#define INDIGITAL_PORT3DEF min_extension_limit_switch
#define INDIGITAL_PORT4DEF max_extension_limit_switch
#define INDIGITAL_PORT5DEF unused5
#define INDIGITAL_PORT6DEF unused6

/////////////////////////////////////////////////////////////////////////////////////////
//
//                          Pre-Autonomous Functions
//
// You may want to perform some actions before the competition starts. Do them in the
// following function.
//
/////////////////////////////////////////////////////////////////////////////////////////

void pre_auton()
{
 // All activities that occur before the competition starts
 // Example: clearing encoders, setting servo positions, ...
}

/////////////////////////////////////////////////////////////////////////////////////////
//
//                                 Autonomous Task
//
// This task is used to control your robot during the autonomous phase of a VEX Competition.
// You must modify the code to add your own robot specific commands here.
//
/////////////////////////////////////////////////////////////////////////////////////////

task autonomous()
{
  // .....................................................................................
  // Insert user code here.
  // .....................................................................................

 AutonomousCodePlaceholderForTesting();  // Remove this function call once you have "real" code.
}

/////////////////////////////////////////////////////////////////////////////////////////
//
//                                 User Control Task
//
// This task is used to control your robot during the user control phase of a VEX Competition.
// You must modify the code to add your own robot specific commands here.
//
///////////////////////////////////////////////////////////////////////////////////////

//////////////////////////////////////////////////////////////////////////////////////
//
//                                       Data Choice
// int's are used here for performance reasons. As the motor[], SensorValue[], and vexRT arrays
// are defined by Robot-C as a word sized signed integer. A.K.A an int in ISO-C. Thus no type conversion needs
// to be done, and it remains in the format that the processor can process most efficiently. When operating
// an analog device the values seem to be clamped from -127 to 128+, with overflow being clamped.
// Ex. A value of 255 becomes 128. 128 represents the max in the positive direction while -127 represents the max
// value in the negative direction. Digital sensor values appear to be mapped so that they have a value of 1 when the swictch is
// NOT activated and a value of 0 when the switch is activated.
//
////////////////////////////////////////////////////////////////////////////////////

////////////////////////////////////////////////////////////////////////////////////
//
//                                 Processor Info
// The Vex appears to be using an ARM Cortex M3 or ARM Cortex M4 processor in 16 bit mode, as the word size
// is 2 bytes. The M3 does not have any hardware floating point support and the M4 has an optional FPU, so it is best
// to just avoid floats. The M4 has an 8 lane 16 bit SIMD unit which may be accessible...
typedef struct
{
  int x;
  int y;
  int z;
}Vector;
typedef struct
{
  int up;
  int down;
  int left;
  int right;
}Digital;
typedef struct
{
  Vector right_joystick;
  Vector left_joystick;
  Vector accelerometer;
  Digital left_trigger;
  Digital right_trigger;
  Digital pad7;
  Digital pad8;
}Joystick;
typedef struct
{
  int OUTPORT1DEF;
  int OUTPORT2DEF;
  int OUTPORT3DEF;
  int OUTPORT4DEF;
  int OUTPORT5DEF;
  int OUTPORT6DEF;
  int OUTPORT7DEF;
  int OUTPORT8DEF;
  int OUTPORT9DEF;
  int OUTPORT10DEF;
}Outputs;
typedef struct
{
  int INDIGITAL_PORT1DEF;
  int INDIGITAL_PORT2DEF;
  int INDIGITAL_PORT3DEF;
  int INDIGITAL_PORT4DEF;
  int INDIGITAL_PORT5DEF;
  int INDIGITAL_PORT6DEF;
}Inputs;
void update_joystick(Joystick*joy)
{

    static int xac = 0;
    static int yac = 0;
    static int zac = 0;
    joy->right_joystick.x= vexRT[0];
   joy->right_joystick.y= vexRT[1];
   joy->left_joystick.y=vexRT[2];
   joy->left_joystick.x=vexRT[3];
   xac = joy->accelerometer.x = vexRT[AccelX]*0.9 + xac*0.1;
   yac = joy->accelerometer.y = vexRT[AccelY]*0.9 + yac*0.1;
   zac = joy->accelerometer.z = vexRT[AccelZ]*0.9 + zac*0.1;

   joy->left_trigger.up=vexRT[Btn5U];
   joy->left_trigger.down = vexRT[Btn5D];
   joy->right_trigger.up = vexRT[Btn6U];
   joy->right_trigger.down = vexRT[Btn6D];
   joy->pad7.up=vexRT[Btn7U];
   joy->pad7.down=vexRT[Btn7D];
   joy->pad7.left=vexRT[Btn7L];
   joy->pad7.right=vexRT[Btn7R];

   joy->pad8.up=vexRT[Btn8U];
   joy->pad8.down=vexRT[Btn8D];
   joy->pad8.left=vexRT[Btn8L];
   joy->pad8.right=vexRT[Btn8R];
}
int clamp_analog_safe(int value)
{
  if(value<-127){value=-127;}
  if(value>128){value=128;}
  return value;
}
void update_outputs(Outputs*out)
{
  motor[Motor1]= clamp_analog_safe(out->OUTPORT1DEF);
  motor[Motor2]= clamp_analog_safe(out->OUTPORT2DEF);
  motor[Motor3]= clamp_analog_safe(out->OUTPORT3DEF);
  motor[Motor4]= clamp_analog_safe(out->OUTPORT4DEF);
  motor[Motor5]= clamp_analog_safe(out->OUTPORT5DEF);
  motor[Motor6]= clamp_analog_safe(out->OUTPORT6DEF);
  motor[Motor7]= clamp_analog_safe(out->OUTPORT7DEF);
  motor[Motor8]= clamp_analog_safe(out->OUTPORT8DEF);
  motor[Motor9]= clamp_analog_safe(out->OUTPORT9DEF);
  motor[Motor10]= clamp_analog_safe(out->OUTPORT10DEF);
 
}
void update_inputs(Inputs* inputs)
{
  inputs->INDIGITAL_PORT1DEF = !SensorValue[dgtl1];
  inputs->INDIGITAL_PORT2DEF = !SensorValue[dgtl2];
  inputs->INDIGITAL_PORT3DEF = !SensorValue[dgtl3];
  inputs->INDIGITAL_PORT4DEF = !SensorValue[dgtl4];
  inputs->INDIGITAL_PORT5DEF = !SensorValue[dgtl5];
  inputs->INDIGITAL_PORT6DEF = !SensorValue[dgtl6];
}

//Converts a vector to two values used for arcade driving
void arcade_drive(int& left_motor, int & right_motor, Vector& v)
{
  left_motor = v.y+v.x;
  right_motor = v.y-v.x;
}
void motor_play(int x , int y)
{
  motor[Motor8] = 0;
  motor[Motor3] = 0;
  motor[Motor2] =0;
  motor[Motor1] = 0;
  if(x>1200)motor[Motor3] =clamp_analog_safe(x/8);
  else if(x>1000)
    motor[Motor8] = clamp_analog_safe(x/8);
  else if(x>500)
    motor[Motor1] =clamp_analog_safe(x/8);
    else
   motor[Motor2] =clamp_analog_safe(x/8);

}
// A function that handles the work of the limit switch
void limit_switch(int min_switch, int max_switch, int& value)
{
  if(min_switch&& value<0)value = 0;
  if(max_switch&&value>0)value = 0;
}
//////////////////////////////////////////////////////////////////////
//
//                        Mission Impossible
//
// Attempts to play the Mission Impossible theme using servos and motors
void MissionImpossible()
{
  //        100 = Tempo
  //          6 = Default octave
  //    Quarter = Default note length
  //        10% = Break between notes
  //
  motor_play(  880,    7); wait1Msec(  75);  // Note(D, Duration(32th))
  motor_play(  933,    7); wait1Msec(  75);  // Note(D#, Duration(32th))
  motor_play(  880,    7); wait1Msec(  75);  // Note(D, Duration(32th))
  motor_play(  933,    7); wait1Msec(  75);  // Note(D#, Duration(32th))
  motor_play(  880,    7); wait1Msec(  75);  // Note(D, Duration(32th))
  motor_play(  933,    7); wait1Msec(  75);  // Note(D#, Duration(32th))
  motor_play(  880,    7); wait1Msec(  75);  // Note(D, Duration(32th))
  motor_play(  933,    7); wait1Msec(  75);  // Note(D#, Duration(32th))
  motor_play(  880,    7); wait1Msec(  75);  // Note(D, Duration(32th))
  motor_play(  880,    7); wait1Msec(  75);  // Note(D, Duration(32th))
  motor_play(  933,    7); wait1Msec(  75);  // Note(D#, Duration(32th))
  motor_play(  988,    7); wait1Msec(  75);  // Note(E, Duration(32th))
  motor_play( 1047,    7); wait1Msec(  75);  // Note(F, Duration(32th))
  motor_play( 1109,    7); wait1Msec(  75);  // Note(F#, Duration(32th))
  motor_play( 1175,    7); wait1Msec(  75);  // Note(G, Duration(32th))
  motor_play( 1175,   14); wait1Msec( 150);  // Note(G, Duration(16th))
  motor_play(    0,   27); wait1Msec( 300);  // Note(Rest, Duration(Eighth))
  motor_play( 1175,   14); wait1Msec( 150);  // Note(G, Duration(16th))
  motor_play(    0,   27); wait1Msec( 300);  // Note(Rest, Duration(Eighth))
  motor_play( 1398,   14); wait1Msec( 150);  // Note(A#, Duration(16th))
  motor_play(    0,   14); wait1Msec( 150);  // Note(Rest, Duration(16th))
  motor_play(  784,   14); wait1Msec( 150);  // Note(C, Duration(16th))
  motor_play(    0,   14); wait1Msec( 150);  // Note(Rest, Duration(16th))
  motor_play( 1175,   14); wait1Msec( 150);  // Note(G, Duration(16th))
  motor_play(    0,   27); wait1Msec( 300);  // Note(Rest, Duration(Eighth))
  motor_play( 1175,   14); wait1Msec( 150);  // Note(G, Duration(16th))
  motor_play(    0,   27); wait1Msec( 300);  // Note(Rest, Duration(Eighth))
  motor_play( 1047,   14); wait1Msec( 150);  // Note(F, Duration(16th))
  motor_play(    0,   14); wait1Msec( 150);  // Note(Rest, Duration(16th))
  motor_play( 1109,   14); wait1Msec( 150);  // Note(F#, Duration(16th))
  motor_play(    0,   14); wait1Msec( 150);  // Note(Rest, Duration(16th))
  motor_play( 1175,   14); wait1Msec( 150);  // Note(G, Duration(16th))
  motor_play(    0,   27); wait1Msec( 300);  // Note(Rest, Duration(Eighth))
  motor_play( 1175,   14); wait1Msec( 150);  // Note(G, Duration(16th))
  motor_play(    0,   27); wait1Msec( 300);  // Note(Rest, Duration(Eighth))
  motor_play( 1398,   14); wait1Msec( 150);  // Note(A#, Duration(16th))
  motor_play(    0,   14); wait1Msec( 150);  // Note(Rest, Duration(16th))
  motor_play(  784,   14); wait1Msec( 150);  // Note(C, Duration(16th))
  motor_play(    0,   14); wait1Msec( 150);  // Note(Rest, Duration(16th))
  motor_play( 1175,   14); wait1Msec( 150);  // Note(G, Duration(16th))
  motor_play(    0,   27); wait1Msec( 300);  // Note(Rest, Duration(Eighth))
  motor_play( 1175,   14); wait1Msec( 150);  // Note(G, Duration(16th))
  motor_play(    0,   27); wait1Msec( 300);  // Note(Rest, Duration(Eighth))
  motor_play( 1047,   14); wait1Msec( 150);  // Note(F, Duration(16th))
  motor_play(    0,   14); wait1Msec( 150);  // Note(Rest, Duration(16th))
  motor_play( 1109,   14); wait1Msec( 150);  // Note(F#, Duration(16th))
  motor_play(    0,   14); wait1Msec( 150);  // Note(Rest, Duration(16th))
  motor_play( 1398,   14); wait1Msec( 150);  // Note(A#, Duration(16th))
  motor_play( 1175,   14); wait1Msec( 150);  // Note(G, Duration(16th))
  motor_play(  880,  108); wait1Msec(1200);  // Note(D, Duration(Half))
  motor_play(    0,    7); wait1Msec(  75);  // Note(Rest, Duration(32th))
  motor_play( 1398,   14); wait1Msec( 150);  // Note(A#, Duration(16th))
  motor_play( 1175,   14); wait1Msec( 150);  // Note(G, Duration(16th))
  motor_play(  831,  108); wait1Msec(1200);  // Note(C#, Duration(Half))
  motor_play(    0,    7); wait1Msec(  75);  // Note(Rest, Duration(32th))
  motor_play( 1398,   14); wait1Msec( 150);  // Note(A#, Duration(16th))
  motor_play( 1175,   14); wait1Msec( 150);  // Note(G, Duration(16th))
  motor_play(  784,  108); wait1Msec(1200);  // Note(C, Duration(Half))
  motor_play(    0,   14); wait1Msec( 150);  // Note(Rest, Duration(16th))
  motor_play(  932,   14); wait1Msec( 150);  // Note(A#5, Duration(16th))
  motor_play(  784,   14); wait1Msec( 150);  // Note(C, Duration(16th))
  return;
}
// Converts a digital Pad on the Controller into a Vector type
void digital_to_analog(const Digital & d, Vector &analog)
{

  if(d.up) analog.y = 128;
  else if(d.down) analog.y = -127;
  else analog.y = 0;

  if(d.left) analog.x = 128;
  else if(d.right) analog.x = -127;
  else analog.x = 0;

}

task usercontrol()
{
 // User control code here, inside the loop
  Joystick controller;
  Outputs outputs;
  Inputs inputs;
  int x =0;

 while (true)
 {
   update_joystick(&controller);
   update_inputs(&inputs);

   // This is the main execution loop for the user control program. Each time through the loop
   // your program should update motor + servo values based on feedback from the joysticks.

   // .....................................................................................
   // Insert user code here. This is where you use the joystick values to update your motors, etc.
   // .....................................................................................

   arcade_drive(outputs.left_drive_motor,outputs.right_drive_motor,controller.left_joystick);
    if(controller.right_trigger.up &&controller.right_trigger.down)MissionImpossible();

    if(abs(outputs.arm_elevation_motor)>5)
    {
      outputs.brake_servo = -127;
    }else{
    outputs.brake_servo = 128;
  }

    outputs.gripper_servo = clamp_analog_safe(outputs.gripper_servo);
   Vector v;
   digital_to_analog(controller.pad8, v);
   outputs.arm_elevation_motor = v.y;
   outputs.arm_extension_motor = v.x;

   if(controller.left_trigger.up){
     outputs.gripper_servo = -120;
   }
   if(controller.left_trigger.down)
   {
     outputs.gripper_servo=120;
   }
    limit_switch(inputs.min_elevation_limit_switch,inputs.max_elevation_limit_switch,outputs.arm_elevation_motor);
    limit_switch(inputs.min_extension_limit_switch,inputs.max_extension_limit_switch,outputs.arm_extension_motor);

    update_outputs(&outputs);
 }
}

We were there this past Saturday in North Houston. We had connection 1 time out
of the 8 preliminary rounds. The parts replacement area had us tried out 4 sets
of VexNets before the last set finally synched. Even then, we had to calibrate
the joystick every time we turned on the robot. We got linkage for all the semi
and final rounds by doing this. We did end up winning the game but also realized
that things could have turned out differently.

My students had a wonderful experience in getting the robot built, working as a
team and coming up with solutions to ideas that didn't quite work out the way
they envisioned.

Many thanks to Paul Lutes, GJ Snyder and all the volunteers for hosting this
event. They were all very helpful and on hand to replace parts and assist in any
way they could.


--- In bestinc@yahoogroups.com, "ripphyzard" <srippetoe@...> wrote:
>
> We checked for connection before the other robots arrived in the pits that
morning. We had connection for about 3 minutes, then it was gone. We lost
connection in 3 of 8 preliminary rounds, 2 of 3 semifinal rounds, and 2 of 3
final rounds.
>
> --- In bestinc@yahoogroups.com, Sean Shenold <sean.shenold@> wrote:
> >
> > OKBEST ran across this problem last year, though apparently not to
> > this degree.  This year, the solution was to 'confiscate' all the keys
> > from all teams, and then to 'issue' a set of keys to each team as they
> > took the field just before each match.  My understanding is that they
> > felt that other teams not competing in fairly close proximity was
> > generating the interference, when they didn't shut down their robots
> > between matches.  By keeping all non-competing robot keys away from
> > the non-competing robots, they eliminated this possible source of
> > interference.  It seemed to work pretty well during their competition.
> >
>

Just a quick update on our issue: Since we replaced the faulty battery connector
and mounted the WiFi adapter on our arm, we've had zero connection issues in
about 4-6 hours worth of practice. Two other variables have changed as well
though. 1)We wrapped our USB extension cable in aluminum foil, in a far-fetched
attempt to shield it from interference. 2) We moved driver practice from a
Church into our team garage. I've got a feeling that the latter solved the
problem since there has been WiFi issues there, but It may be worth wrapping
your USB extension in foil, since I believe it is legal (no modification of
returnable parts, and using optional consumable material).

Anyways, I hope teams can get this problem solved.

--- In bestinc@yahoogroups.com, "Lucas" <thomas03@...> wrote:
>
> Our team had wifi linking problem after we updated the mastercode. When we
rolled the mastercode back to the version that is on the cd's that our hub
provided, everything worked just fine... the mastercode might be a source of
your problems...
>
> --- In bestinc@yahoogroups.com, Lori Jack <mail4jacks@> wrote:
> >
> > I'm surprised that you're surprised.  we competed at auburn and had
connection problems.  our hub even sent an extra wifi key with us because of all
the problems we had before, during, and after the hub competition.  we even
received a penalty during the competition at Auburn due to these problems. 
Besides not having enough money after going to Orlando, that was the main reason
we did not buy the robot kit last year.
> >
> > Sent from my Verizon Wireless Phone
> >
> > Michael Carroll <mjcarroll@> wrote:
> >
> > >I'm surprised to hear this.  Part of the reason for the move to VEX was to
> > >reduce radio interference problems that we have had in years past with the
> > >old-style Futaba receivers.
> > >
> > >Last year at South's BEST, we ran 60 teams through (with up to 8 at a time
> > >on-field) with no interference problems.
> > >
> > >It sounds like the venue may have had some sort of active Wifi suppression
> > >system (I've heard of them, never seen one in action) and perhaps this was
> > >the cause of the radio failures?  I can't think of any of our regional
> > >venues having these sorts of issues.  What hub are you from?
> > >
> > >~mc
> > >
> > >On Sat, Oct 15, 2011 at 23:45, ripphyzard <srippetoe@> wrote:
> > >
> > >> **
> > >>
> > >>
> > >> So today was the second most frustrating day of BEST I have experienced
in
> > >> the past ten years. Every round had robots not running because the VEX
> > >> joystick lost comm with the Cortex controller, except for one preliminary
> > >> round. We had comm in our first semifinal round and half of our second.
We
> > >> only had comm for one minute in the three rounds of the finals. We only
had
> > >> six out of fourteen rounds with radio comm for the entire round. To my
> > >> knowledge, every team experienced similar issues, though we had our worst
> > >> problems after the preliminary rounds.
> > >>
> > >> Another team went through all three semifinal rounds without ever having
> > >> radio comm. Yet another missed a round of the finals because of the lack
of
> > >> radio comm. Some rounds only had one of four robots running, all the
result
> > >> of the radio systems not linking.
> > >>
> > >> After we were finished today, I just could not imagine spending six weeks
> > >> next year working with the kids to put a robot together to go through a
> > >> similar experience. VEX and BEST need to find a solution. The
communication
> > >> problems are well documented on the VEX forums.
> > >>
> > >> There is an upside to this disaster. At dinner this evening the team told
> > >> me how much they enjoyed the past six weeks.
> > >>
> > >>
> > >>
> >
>

We asked but were not allowed to use a usb extension at our hub competition.

You have solved the problem as far as pratice is concerned. If wifi is the
issue, the problem may return when you get to your hub competition. In a message
I sent to the Texas BEST Regional Director and the Executive Director of BEST, I
suggested that competition venues be thoroughly checked for wireless
interference. May I recommend that you try to test your robot at your
competition site as soon as you can. If wifi is a problem you might be able to
get it disabled during the competition.

--- In bestinc@yahoogroups.com, "seancsnm" <sean@...> wrote:
>
> Just a quick update on our issue: Since we replaced the faulty battery
connector and mounted the WiFi adapter on our arm, we've had zero connection
issues in about 4-6 hours worth of practice. Two other variables have changed as
well though. 1)We wrapped our USB extension cable in aluminum foil, in a
far-fetched attempt to shield it from interference. 2) We moved driver practice
from a Church into our team garage. I've got a feeling that the latter solved
the problem since there has been WiFi issues there, but It may be worth wrapping
your USB extension in foil, since I believe it is legal (no modification of
returnable parts, and using optional consumable material).
>
> Anyways, I hope teams can get this problem solved.
>
> --- In bestinc@yahoogroups.com, "Lucas" <thomas03@> wrote:
> >
> > Our team had wifi linking problem after we updated the mastercode. When we
rolled the mastercode back to the version that is on the cd's that our hub
provided, everything worked just fine... the mastercode might be a source of
your problems...
> >
> > --- In bestinc@yahoogroups.com, Lori Jack <mail4jacks@> wrote:
> > >
> > > I'm surprised that you're surprised.  we competed at auburn and had
connection problems.  our hub even sent an extra wifi key with us because of all
the problems we had before, during, and after the hub competition.  we even
received a penalty during the competition at Auburn due to these problems. 
Besides not having enough money after going to Orlando, that was the main reason
we did not buy the robot kit last year.
> > >
> > > Sent from my Verizon Wireless Phone
> > >
> > > Michael Carroll <mjcarroll@> wrote:
> > >
> > > >I'm surprised to hear this.  Part of the reason for the move to VEX was
to
> > > >reduce radio interference problems that we have had in years past with
the
> > > >old-style Futaba receivers.
> > > >
> > > >Last year at South's BEST, we ran 60 teams through (with up to 8 at a
time
> > > >on-field) with no interference problems.
> > > >
> > > >It sounds like the venue may have had some sort of active Wifi
suppression
> > > >system (I've heard of them, never seen one in action) and perhaps this
was
> > > >the cause of the radio failures?  I can't think of any of our regional
> > > >venues having these sorts of issues.  What hub are you from?
> > > >
> > > >~mc
> > > >
> > > >On Sat, Oct 15, 2011 at 23:45, ripphyzard <srippetoe@> wrote:
> > > >
> > > >> **
> > > >>
> > > >>
> > > >> So today was the second most frustrating day of BEST I have experienced
in
> > > >> the past ten years. Every round had robots not running because the VEX
> > > >> joystick lost comm with the Cortex controller, except for one
preliminary
> > > >> round. We had comm in our first semifinal round and half of our second.
We
> > > >> only had comm for one minute in the three rounds of the finals. We only
had
> > > >> six out of fourteen rounds with radio comm for the entire round. To my
> > > >> knowledge, every team experienced similar issues, though we had our
worst
> > > >> problems after the preliminary rounds.
> > > >>
> > > >> Another team went through all three semifinal rounds without ever
having
> > > >> radio comm. Yet another missed a round of the finals because of the
lack of
> > > >> radio comm. Some rounds only had one of four robots running, all the
result
> > > >> of the radio systems not linking.
> > > >>
> > > >> After we were finished today, I just could not imagine spending six
weeks
> > > >> next year working with the kids to put a robot together to go through a
> > > >> similar experience. VEX and BEST need to find a solution. The
communication
> > > >> problems are well documented on the VEX forums.
> > > >>
> > > >> There is an upside to this disaster. At dinner this evening the team
told
> > > >> me how much they enjoyed the past six weeks.
> > > >>
> > > >>
> > > >>
> > >
> >
>

Good Morning,

The guys would like to operate a server using one of the push buttons on the
front of the controller...  Push the button, the servo activates, release the
button, the servo returns to it's prior position... May need to look at full
travel, half travel, etc... Did not see pre-built module so assume must be
custom.  Would like to be able to work from specific channel and motor output so
understanding how the code fits and is put together is the help we are seeking.

In other word, we really need a fishing lesson more than a fish... Willing to
look up on websites and reseach.

Thanks,

S
Sent via BlackBerry by AT&T

Yes, they mated them over and over again while they frantically tried to get
their robots to connect while the head referee went ahead and started the round.
If they did get lucky enough to finally get a connection, they had to wait 20
seconds before they could start driving. That is proper procedure per the BEST
rules but it was still sad because it wasn't the fault of the teams that they
could not connect.

With so many robots losing connection or unable to connect, I thought the
competition might get cancelled. I didn't know how they would be able to run it
without robots connecting. In hindsight, maybe they should have stopped it and
rescheduled at a different location. The teams did not get a fair opportunity to
compete.

--- In bestinc@yahoogroups.com, Lee Brownell <lee_brownell@...> wrote:
>
> I'm wondering if the teams mated the receivers and the controllers. That might
cause this sort of problem.
>
> On Oct 15, 2011, at 11:45 PM, "ripphyzard" <srippetoe@...> wrote:
>
> > So today was the second most frustrating day of BEST I have experienced in
the past ten years. Every round had robots not running because the VEX joystick
lost comm with the Cortex controller, except for one preliminary round. We had
comm in our first semifinal round and half of our second. We only had comm for
one minute in the three rounds of the finals. We only had six out of fourteen
rounds with radio comm for the entire round. To my knowledge, every team
experienced similar issues, though we had our worst problems after the
preliminary rounds.
> >
> > Another team went through all three semifinal rounds without ever having
radio comm. Yet another missed a round of the finals because of the lack of
radio comm. Some rounds only had one of four robots running, all the result of
the radio systems not linking.
> >
> > After we were finished today, I just could not imagine spending six weeks
next year working with the kids to put a robot together to go through a similar
experience. VEX and BEST need to find a solution. The communication problems are
well documented on the VEX forums.
> >
> > There is an upside to this disaster. At dinner this evening the team told me
how much they enjoyed the past six weeks.
> >
> >
>

What you're asking for is actually somewhat easier than what we've posted here,
but you might want to try something like this on for size... it's the code from
our robot this year (UETM #34), but it's the same idea we've been using for
years (sorry for the formatting issues... you'll need to re-indent it):

// Constants to represent current gripper position
const short GRIPPER_POSITION_1  = 1;
const short GRIPPER_POSITION_2  = 2;
const short GRIPPER_POSITION_3  = 3;
const short SERVO_VAL_1         = -127;
const short SERVO_VAL_2         = -30;
const short SERVO_VAL_3         = 127;

// Variables to store button and gripper state
char gripperPosition      = GRIPPER_POSITION_1;
char gripperBounce        = 1;

while(true)
{

...

if (vexRT[Btn8U] && (gripperBounce)) {
       gripperBounce = 0;
		   if (gripperPosition == GRIPPER_POSITION_1) {
		     gripperPosition = GRIPPER_POSITION_2;
		     motor[gripperLeft] = SERVO_VAL_2;
		     motor[gripperRight] = -SERVO_VAL_2;
		   } else if (gripperPosition == GRIPPER_POSITION_2) {
		     gripperPosition = GRIPPER_POSITION_3;
		     motor[gripperLeft] = SERVO_VAL_3;
		     motor[gripperRight] = -SERVO_VAL_3;
		   }
		 } else if (vexRT[Btn8D] && (gripperBounce)) {
		   gripperBounce = 0;
		   if (gripperPosition == GRIPPER_POSITION_3) {
		     gripperPosition = GRIPPER_POSITION_2;
		     motor[gripperLeft] = SERVO_VAL_2;
		     motor[gripperRight] = -SERVO_VAL_2;
		   } else if (gripperPosition == GRIPPER_POSITION_2) {
		     gripperPosition = GRIPPER_POSITION_1;
		     motor[gripperLeft] = SERVO_VAL_1;
		     motor[gripperRight] = -SERVO_VAL_1;
		   }
		 } else if (!vexRT[Btn8D] && !vexRT[Btn8U]) {
		   gripperBounce = 1;
		 }
	 }

Hope that helps!

--- In bestinc@yahoogroups.com, tx_junkman@... wrote:
>
> Good Morning,
>
> The guys would like to operate a server using one of the push buttons on the
front of the controller...  Push the button, the servo activates, release the
button, the servo returns to it's prior position... May need to look at full
travel, half travel, etc... Did not see pre-built module so assume must be
custom.  Would like to be able to work from specific channel and motor output so
understanding how the code fits and is put together is the help we are seeking.
>
> In other word, we really need a fishing lesson more than a fish... Willing to
look up on websites and reseach.
>
> Thanks,
>
> S
> Sent via BlackBerry by AT&T
>

MathWorks provided software, "BEST Simulink Library", could be used to
achieve this behavior very easily. You could program a digital button
to turn your servo to desired angle positions. You could also program
multiple buttons to control a single servo for different angle
positions i.e button 5 up gives 45 degrees, 5 down gives 60 degrees,
button 6 up give -45 degrees etc. I have attached a simple sample
Simulink file that can be used to control a motor and a servo using
digital buttons. If you are not familiar with the software, please
look look at these tutorial videos as a starter:
http://www.mathworks.com/academia/best-robotics/index.html?sec=resources
In a 2-3 days, this link will also have a video that explains the idea
of using buttons to control motors/servos. Let me know if you have
more questions on this @ shiremat@...

Please contact your Hub Director to get access to our software DVD.

We also have our weekly online training that you can register to from
the BEST home page: http://www.bestinc.org/   (On the left-side column
on this page).

Good Luck!
Sandeep

We just finished hub competition. Our robot only disconnected in one round out
of 9 total, and that issue may have been a battery problem (since it was finally
discovered to have an unreliable connector). Unfortunately, for quite a few
rounds, a good number of other teams went through several rounds with motionless
robots, but it was unclear why. For a large number of these cases, at least the
teams we helped, the issues should have been taken care of well in advance (one
team had faulty USB keys from kickoff, another team had its programming software
expire, etc.). There was no evidence that WiFi was the issue - robots either
didn't move, or they ran fine the entire round. Considering how many other hubs
have had issues, I think we were very fortunate not to have any.

The gym the competition was held in was the same one used last year. Although
the college had WiFi campus-wide, it was password-protected, so the only WiFi
Internet connection was streaming the game.

I do think that they competition location should be pre-checked with at least a
few VEX systems to assure that there is no interference. There were no
connection issues at Texas regionals last year, but as it will be held at a new
location this year, it should probably be checked beforehand.

--- In bestinc@yahoogroups.com, "ripphyzard" <srippetoe@...> wrote:
>
> Yes, they mated them over and over again while they frantically tried to get
their robots to connect while the head referee went ahead and started the round.
If they did get lucky enough to finally get a connection, they had to wait 20
seconds before they could start driving. That is proper procedure per the BEST
rules but it was still sad because it wasn't the fault of the teams that they
could not connect.
>
> With so many robots losing connection or unable to connect, I thought the
competition might get cancelled. I didn't know how they would be able to run it
without robots connecting. In hindsight, maybe they should have stopped it and
rescheduled at a different location. The teams did not get a fair opportunity to
compete.
>
> --- In bestinc@yahoogroups.com, Lee Brownell <lee_brownell@> wrote:
> >
> > I'm wondering if the teams mated the receivers and the controllers. That
might cause this sort of problem.
> >
> > On Oct 15, 2011, at 11:45 PM, "ripphyzard" <srippetoe@> wrote:
> >
> > > So today was the second most frustrating day of BEST I have experienced in
the past ten years. Every round had robots not running because the VEX joystick
lost comm with the Cortex controller, except for one preliminary round. We had
comm in our first semifinal round and half of our second. We only had comm for
one minute in the three rounds of the finals. We only had six out of fourteen
rounds with radio comm for the entire round. To my knowledge, every team
experienced similar issues, though we had our worst problems after the
preliminary rounds.
> > >
> > > Another team went through all three semifinal rounds without ever having
radio comm. Yet another missed a round of the finals because of the lack of
radio comm. Some rounds only had one of four robots running, all the result of
the radio systems not linking.
> > >
> > > After we were finished today, I just could not imagine spending six weeks
next year working with the kids to put a robot together to go through a similar
experience. VEX and BEST need to find a solution. The communication problems are
well documented on the VEX forums.
> > >
> > > There is an upside to this disaster. At dinner this evening the team told
me how much they enjoyed the past six weeks.
> > >
> > >
> >
>

Sorry, I failed to mention we use RobotC. I have no idea how it would be done
using Mathworks if that's what you're using...

--- In bestinc@yahoogroups.com, tx_junkman@... wrote:
>
> Good Morning,
>
> The guys would like to operate a server using one of the push buttons on the
front of the controller...  Push the button, the servo activates, release the
button, the servo returns to it's prior position... May need to look at full
travel, half travel, etc... Did not see pre-built module so assume must be
custom.  Would like to be able to work from specific channel and motor output so
understanding how the code fits and is put together is the help we are seeking.
>
> In other word, we really need a fishing lesson more than a fish... Willing to
look up on websites and reseach.
>
> Thanks,
>
> S
> Sent via BlackBerry by AT&T
>

Sent via BlackBerry by AT&T