View unanswered posts | View active topics It is currently Mon Nov 11, 2019 9:41 pm






Reply to topic  [ 4 posts ] 
Stop all motors when the robot drops connection? 
Author Message
Rookie

Joined: Mon Dec 15, 2014 9:48 pm
Posts: 16
Post Stop all motors when the robot drops connection?
Hello, during matches our robot will sometimes drop and continue doing whatever action it last received from the controller. We thought that to prevent this from happening and burning out motors we could write in the code somewhere, something like: if any button on the controller is pressed for more than say five or so seconds just stop all motor movement. This would trick the code into stopping the motor movement when it drops. The problem is I am not really sure how to do this, especially because we use the joysticks to move our robot's drive-train. Can anyone help us with this? Has anyone done this before and were there any problems with doing this? Thanks for any help in advance!! :D


Thu Dec 18, 2014 3:17 am
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1523
Post Re: Stop all motors when the robot drops connection?
It really depends on what caused the robot not to stop. If the cause was losing communication, then this is supposed to be taken care of by RobotC. In JoystickDriver.c, there is code to detect lost of communication by timing the joystick packets. Your laptop is supposed to send joystick packets periodically to the NXT brick. If a timeout period has past and no joystick packet is received, the code in JoystickDriver.c will reset all the values in the joystick packet so in effect releasing all pressed buttons and analog sticks.
However, if the cause is the brick or the motor controllers being hung, then no code can fix this problem because the brick will not run any code at that point (or the motor controllers will no longer respond to any commands). This happens typically when your robot has an ESD (ElectroStatic Discharge). If you search the forums, you will find many threads about this issue. FIRST is aware of the problem for many years that the rubber wheels running on rubber mats will give you a static electricity generator. This is especially acute when your competition day is sunny, dry and cold. Unfortunately, FIRST doesn't really have a unified solution to fix this problem yet. Some local competitions may spray their fields with anti-static sprays between each match. That helps but not a sustained solution. Other teams used ferrite chokes to protect ESD coming into the brick via various I2C and USB cables. But there are so many entry points on the brick and motor controllers that this is almost hopeless. I am hoping the new EV3 is designed to withstand ESD better than the NXT. Even if that's true, all other electronics components must be redesigned to withstand ESD.
To give you a sense how devastating this could be is an example from our competition last Sunday. Our robot was disabled after hitting the field perimeter causing an ESD. You could hear and see the electric arc. We thought no big deal, we had that in occasional matches before. But this time, after the discharge, the brick wouldn't run our software anymore. It kept complaining "A THIRD PARTY SENSOR DRIVER ERROR" on the LCD screen. Unfortunately, we had almost back to back matches that left us no time to diagnose the problem. We were forced to just sit the robot on the platform through the entire two matches. The students were panicking. I knew the problem was probably ESD fried some sensor ports but which port?! (Xander or RobotC folks, please note: It would be nice to report what port failed on the LCD screen than just 3rd party driver error) While the students were competing with the disabled robot on the field, I quickly reconfigured the code by moving all essential sensors from the sensor MUX to the NXT leaving non-essential sensors on the MUX assuming one of the ports on the sensor MUX was fried. That paid off, we were able to revive the robot just in time for the last match of the day. But the damage was already done. Counting the match that the ESD occurred, we were unable to play 3 consecutive matches.


Thu Dec 18, 2014 4:01 am
Profile
Rookie

Joined: Mon Dec 15, 2014 9:48 pm
Posts: 16
Post Re: Stop all motors when the robot drops connection?
MHTS wrote:
It really depends on what caused the robot not to stop. If the cause was losing communication, then this is supposed to be taken care of by RobotC. In JoystickDriver.c, there is code to detect lost of communication by timing the joystick packets. Your laptop is supposed to send joystick packets periodically to the NXT brick. If a timeout period has past and no joystick packet is received, the code in JoystickDriver.c will reset all the values in the joystick packet so in effect releasing all pressed buttons and analog sticks.
However, if the cause is the brick or the motor controllers being hung, then no code can fix this problem because the brick will not run any code at that point (or the motor controllers will no longer respond to any commands).


Thank you for your help! I think this information solves some problems. Just to make sure though, is this code in the joystick driver active while our teleOp is running just by including the driver? Or is there anything we need to put into our code to make it work?


Thu Dec 18, 2014 4:32 am
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1523
Post Re: Stop all motors when the robot drops connection?
As part of your teleop code, you are already including JoystickDriver.c. That code is already active. It's the code that delivers you the joystick structure in getJoystickSettings(). This is the code sniplet from JoystickDriver.c that implements that functionality. It means if the number of missed joystick messages is greater than the limit and if nobody overrides the disabling joystick feature then zero out all the fields in the joystick structure except for the fields that hold the state of the competition so the competition won't start accidentally when communication is lost and also the tophat released state is -1 instead of 0.
Code:
if (nNoMessageCounter > nNoMessageCounterLimit)
{
  hogCPU();
  if (!bOverrideJoystickDisabling)
  {
    bTempUserMode = joystickCopy.UserMode;
    bTempStopPgm = joystickCopy.StopPgm;

    memset(joystickCopy, 0, sizeof(joystickCopy));

    joystickCopy.UserMode = bTempUserMode;
    joystickCopy.StopPgm = bTempStopPgm;
    joystickCopy.joy1_TopHat = -1;
    joystickCopy.joy2_TopHat = -1;
  }
  bDisconnected = true;
  releaseCPU();
}


Thu Dec 18, 2014 4:42 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 4 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.