![]() |
Danger in Disconnected IR Receiver
I've been concerned about the inherent dangers inadvertently introduced by Team Update #6's ruling that the IR Receivers must be physically disconnected from the robot while in the Pit.
The intent is admirable, however, the execution method is dangerous. Every programmer should be aware that a physically disconnected IR Receiver will look to the code as if every IR command has been simultaneously selected. The danger of course is that if your code simply checks to see if a pin is ==1, then you'll begin executing the first command you check. If you plan to use the IR in Teleop mode, then your robot will take off as soon as you turn it on in the pit. If you use IR only in Hybrid mode, then your robot will take off as soon as the Competition Port Auto switch is thrown. Please design your code to check for and reject multiply selected IR commands. P.S. And stand clear of the team in the next pit who won't test this ahead of time and will find out the hard way Thursday morning of the Regional. |
Re: Danger in Disconnected IR Receiver
I already made code that handles this well, and will blink the 4 red LEDs on the OI when the IR receiver is disconnected. I have posted this code in another thread, and have referred to it numerous times. It is really dangerous not to use some sort of safety code if the IR sensor becomes disconnected or it breaks. Here is my code I made:
Code:
//Variables should be declared at the beginning at the program |
Re: Danger in Disconnected IR Receiver
knowing about all the IR jamming etc, i'm almost thinking about not even using IR, but instead doing some kind of deak-reckoning autonomous code, where the IR only modifies what it does. Teams (IMHO) who are thinking of doing teleoperated-like handling with a TV remote should seriously reconsider. I can only imagine the damage some teams will cause because of a robot going out of control because another robocoach is on the same frequency and their robot picks it up....
|
Re: Danger in Disconnected IR Receiver
Thank you for posting the code to help other teams. Just a quick quibble: the line 'printf("Mode 1 %d\r");' does not do what you want as there is no value to substitute for '%d'. You probably meant 'printf("Mode 1\r");'.
Thank you again and good luck. |
Re: Danger in Disconnected IR Receiver
You're right... I'm still new to programming. It doesn't hurt the code at all to have it there, it will only clean it up by taking it out. Thanks for the suggestion.
|
Re: Danger in Disconnected IR Receiver
wow nice catch
every team make sure you have safe code, so a robot doesn't go flying out of the pits (dragging the OI behind) |
Re: Danger in Disconnected IR Receiver
I'm designing IR capability into the code but I'm not counting on it. The last time IR was involved in the game (2004) it was pretty much a failure. If I didn't see IR for another four years it would be okay with me.
Yes, pun intended. |
Re: Danger in Disconnected IR Receiver
Ditto on having it ready but not counting on it. I think it's going to be a bunch of jumbled IR by the time it reaches the robots with so many remotes/bright stage lights pointed all over the place. Ours stops working if we just shine a flashlight somewhere near it, let along one of those tens of spotlights FRC puts on the field. Also, if two remotes are pointed somewhere near the reciever, this also makes it stop working.
Putting a tube on it to confine the beam again renders it almost useless, since you have to have your robot essentially pointing right at you for it to work, and the point of the remote anyhow is to (perhaps) guide the robot back to straight from a misalignment... so you might not get any signal in the first place. *sigh* but that's ok... that adaptive cruise control's starting to work miiiighty good.... :cool: -q |
| All times are GMT -5. The time now is 23:50. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi