One of our teams had a problem this weekend that I am still trying to figure out. They use an LCD with the sample “Code Switcher” program for multiple autonomous. From working with this program in the past, we know that you must select one mode or the robot does nothing. The problem the team had was that about a minute into a match, their LCD would reset. Once this happened, since they couldn’t touch the robot (and press the select button) - it was inoperable for the rest of the match. They were also having an issue where I believe their intake was tripping the PTC. So my question is this: if the PTC trips, will it reset (powre down/power up) the LCD? If so, is there any way to keep this from happening (power expander)?
No, if I remember correctly, all of the electronic pins (including Rx1 & 2) are on different circuits, not on either of the motor PTCs
No, it shouldn’t… Did you have a backup battery, and made sure it’s fully charged? If the backup battery is fully charged, you shouldn’t have an LCD trippage. Another way is by connecting the intake to a power expander so if there’s any high voltage flow, it doesn’t involve the invulnerable CORTEX…
EDIT//: When the CORTEX sends more than 1A of power, then the CORTEX would trip and stop working. So a power expander would help a ton with the over-amperage…
I hope somebody will correct me if I’m wrong, but I think there is a way to detect if the Cortex has reset because of a Cortex power “trip out” (or situations like static discharge, etc.) vs. other commands. I think in RobotC there is a boolean variable that can be used as a flag for this. By putting some code in your competition template, the flag can be read and the entire LCD menu selection process can be skipped so that if the Cortex gets tripped and reboots, it won’t hang up on the LCD menu. But I’m away from my notes and can’t find what that variable is. I think it’s something jpearman taught us about a couple years ago.
I had the same issue with my LCD, my robot kept cutting out at a competition (bad battery connection) and to fix it I add an if statement around my selection code to check if the robot is disabled, if it isn’t it skips the selection process. The only downside is that to select the autonomous you have to be plugged into competition control before turning the robot on, it also won’t exit if you forget to select and auto, but that can be fixed by making it a while loop instead of an if statement. The variable I used was something like bIfiRobotDisabled.
I might be wrong about this but I think if you are using RobotC and you put this line of code
bStopTasksBetweenModes = true;
inside your pre-autonomous section, then your LCD menu selection won’t hang up the entire program if the Cortex resets. You will still get to driver mode if, say, your Cortex reboots and you are in driver control mode.
You need to bypass the LCD code if the robot is enabled, ie. if the robot reboots due to a dip in battery voltage (which with a good backup battery should not happen) you need to check if the bIfiRobotDisabled flag is true and only run the LCD code if it is. There are (fairly complicated) examples of LCD chooser code here.
Thanks, everyone!
Okay, thanks!
One question… why do you need to use the LCD after autonomous? If it’s use as an autonomous switcher, it shouldn’t be a problem in driver control…
If it hangs up during Autonomous, our team uses a really special autonomous switcher. Let me explain:
There’s a potentiometer with an axle through it that has a hand crank on another end of the axle. There’s two standoffs, one on either side of the hand crank. When the hand crank is turning in one direction, it chooses one autonomous. In a different direction, it chooses a different autonomous. This is all done in pre-autonomous. Once the autonomous is chosen, autonomous starts and no matter where the hand crank is, the autonomous that runs is the one that was chosen in pre autonomous. I find this easier to code and for teammates to understand than actually working with the LCD buttons.
I don’t think they really need to use the LCD after autonomous. I think their situation arises when the Cortex power gets interrupted for some reason and then the entire program tries to restart and run from the beginning, in which case it might get stuck waiting for somebody to push the LCD buttons. What jpearman suggests is a technique that allows the code to skip over that LCD selection phase if the robot is supposed to be doing something else, like driver control.
One more (probably really stupid) question. What is the second character in the command: bIfiRobotDisabled
I typed in “bee” “el” “ef” “eye” “robotdisabled” and RobotC did not like it. I’m thinking that the second character is not an “el.”
Capital I (eye) and in “Innovation First International”