Does anyone know the answer or approx answer to the following:
What is the range of a VEX TX and RX?
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?
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 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…
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?
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)
}
}
}
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.
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
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.