VEX Radio Range & Loss of Radio Fail Safe?

Does anyone know the answer or approx answer to the following:

  1. What is the range of a VEX TX and RX?

  2. If a robot goes out of radio range, what will the controller do? Will it automatically set the PWM values to 127 or will it remember the last PWM values and lock them in the controller and cause a “run away” condition?

  3. Are there any software checks that can be written like so?

IF radioTX is good
then update PWMs
ELSE
PWMs = 127

You can test pretty easily yourself by just shutting off your transmitter while you’re driving.

When you’re driving via RC and radio communication is lost the PWMs do get set to 127.
You’d have to purposely switch over to autonomous if you really wanted to keep driving.

P.S. I seem to remember a maximum of 150’, but I could easily be mixing my transmitters.
Tested by turning on a robot that waved a flag and walking away, but it was a couple of years ago now and my batteries were new.

I’d love to test myself, except I don’t have one to test.

Asking questions, then purchasing.

So sounds like there is a build in fail safe?

Yes, there is a built in fail-safe.

I’d test it for you, but it’s dark and there are wolves…
I could check range for you tomorrow after work if it’s important.
Range does depend on battery strength [edit]and antenna orientation/interferrence[/edit] of course.

We are wanting to build a community robot and use the VEX controller, but I wanted to make sure we understood the safety of the VEX controller first before we purchase a used or new one for the community project.

Mark - I think we need to clear up whether the microcontroller will be running the default software, or will run custom software.

If they are planning to write their own code, they can certainly (by mistake) write instructions that will tell the Microcontroller to send out non-127 PWM signals for as long as the microcontroller battery is supplying enough energy; regardless of whether the receiver detects a transmitter signal.

Chris - In either circumstance (using the default or custom software), you will be able to have the microcontroller return all PWM outputs to neutral when no transmitter signal is received. However, in the custom code situation, the shutdown’s reliability will depend on the skill of the person who writes those custom instructions. The good news is that it’s not hard to get it right; if the author pays attention…

Blake

It’s pretty safe even if you write your own code. There is a small window for bypassing the fail-safe, but to exploit it involves purposely entering autonomous mode.
Potentially, that autonomous bit in the communication packet can be accidentally overwritten by bad code and prevent fail-safe operation, however, even that’s unlikely as it is usually packed into the first memory block and user code comes after that.

We can only bypass the loss of transmitter override by explicitly informing the master controller that we want to operate in autonomous mode. While in this autonomous mode though we are given the transmission packet from the remote control transmitter with all 127’s. So if we are running solely off the commands from the transmitter we’ll usually be alright.

The only window for error that I know of is if your code sets autonomous while receiving valid transmitter data. In that specific case the GetData packet will retain the last known transmitter values and your code keeps receiving it. The Master doesn’t set the packet to neutral except at the start (auto or not) and unless it’s in tele-op mode and several transmitter packets go missing.

Anyone know of another way to bypass the fail-safe?

Chris,

I just built a 12lb battle bot with a vex controller and it is possible to enter a run away condition. The system seems to retain the last value sent by the controller and if it fails to sync it will send that to the motors. The range was about 15ft for my robot but the motors could have been causing allot of noise. The problem is very easy to fix the controller has flags to catch loss of communication. If you look at my code, I didn’t include a time buffer for loss of communication. I would recommend adding this because it can cause the robot to shudder as communication cuts in and out.

Here is the code for my robot.


// Code for 2008 Fighting Robot Spare Parts v1
// Mabuchi Motors in Banebot 16:1 aka wicked slow

#include "Main.h"

void main ( void )
{
      unsigned char data; 
      unsigned char drumofdoom; 

      SetPWM ( 3 , 0 ) ;  // Arm Brushless Weapon ESC
      Wait ( 5000 ) ;       // Time to Arm ESC
      while ( 1 )
      {
            data = ReceivingData(1);   // Check if RX1 is getting data
            if ( data == 1 )   //If receiving data
            {
                  right_stick = GetRxInput ( 1 , 2 ) ;  // Data from CH2
                  left_stick = GetRxInput ( 1 , 3 ) ;   // Data from CH3
                  SetPWM(1,right_stick);     // Send data to motors             
                  SetPWM(2,left_stick);      //  Send data to motors
            }
            else  // Not receiving Data
            {
                  SetPWM ( 1 , 127 ) ;   // Stop 1
                  SetPWM ( 2 , 127 ) ;   // Stop 2
                  SetPWM ( 3 , 0 ) ;      // Stop 3 ( Brushless ESC 0 Stop)
            } 
      }
}



If you want to see my little guy here is a link: http://www.youtube.com/watch?v=xyfSHu-cpsw

Sweet. Yeah my thinking must be right on. Your code pretty much matches my pseudo code above and confirms what I was nervous of. Thanks for posting.

Adam,

Do you experience the same problem with EasyC Pro and it’s WPI libraries as with V2?

I can check V2, the architecture is different with V2 so it may behave differently. I assumed (which is wrong of me) that most users who would do this type of project would use Pro. Though my program certainly wouldn’t require it.

After some testing, V2 doesn’t seem to be affected like Pro. I was unable to get a v2 robot to run away.

I was using the latest WPILib. Yes, it does run away when you off the controller with controls moving the bot forward. The last received values are still stored. Hence there is no failsafe. WPI probably had an old master code.

Then again, the master code is not opensource so thats kind of irritating.

P.S Anyone has an idea how to have timer3 fire an interrupt at a certain frequency (1-10Khz) using WPILib please do let me know via pm :slight_smile:

So I should either use the OLD version 2.0 instead of PRO. Or I need to write software in PRO like above, on a timer or something to check for a TX/RX. That’s ok, I really appreciate this information.

Use Pro and just make a watch dog timer that makes the robot shutoff if it looses signal. You can use the code I posted directly but adding a timer would help if there is allot of noise.