Anything and everything. We generally use the speedcontroller objects (e.g. ControlLease<CANTalon>).
The ControlLeases themselves replace what would usually be in your robotmap class. Instead of “static CANTalon *myTalon” it would be “static ControlLease<CANTalon> myTalon”. You can still access the object without a lease (e.g. reading encoder values or whatever) by calling .Get() without a preceeding .IsMine(). Lease objects are per-system that wants access to the object.
The 100ms timeout is more of a safety system than anything. If, for example, a command forgets to call .Release() when it finishes, or if a thread crashes, it doesn’t lock up the system out of control.
Our code for 2017 right now is under private. We’ve recruited a new programming team this year so we’re in the process of doing some code cleanup and documentation before we do an official release. I can, however, provide some snippets in the gists below.
We employed something similar in 2k16 with what I call Control Strategies. They worked alongside Control Leases such that strategies had an implicit hold of a lease. The leases were primarily used by background tasks or commands, where switching out the entire strategy was unwise.
This was very similar to one of the earlier forms of control management I looked at. It was fast, simple and elegant.
I decided to switch to control leases because the one disadvantage of this system is the information isn’t pushed out immediately. This isn’t very important for most cases of .Set, but if you look at the gist in my reply 2 above this one (sorry I’m on mobile), you’ll notice that we also need access to other functions unique to the talon srx. This is the advantage of control leases for my use case, they give you access to the whole object, not just the stuff you pass to Set. Sure, you could just call the main objects functions, but then you’re fighting for contention again. Correct me if I’m wrong, but I believe commands are sent to the SRX when you call them, and are not buffered, which is the main reason I didn’t go for a system similar to the one you described.
Something to note is that Control Leases are in a way similar. If a priority 10 has ownership of the lease, but later in the same loop, a priority 100 wants the lease, both will trigger, but on subsequent loops only the 100 priority will trigger until released. A caveat with control leases is that it doesn’t matter where the loop starts or ends, it’s all kind of 1 straight timeline. This is a drawback in some cases, but an advantage in others
That is very important. Last year a code change worked fine in teleop but it screwed up our transition from auto to teleop and we weren’t able to shoot for a match I think.
Anothing thing teams may miss: When programming the red alliance versus blue alliance autonomous modes, if you test a blue auto mode and change values make sure to save those values for the red side as well. We have our code set up so that the red/blue auto values are connected (eg change the red auto turn 1 angle, and the blue angle is changed as well), and we have the data in a file, for example “ScoreMiddleGearData”, so that values can be changed in one place.
Also, when adjusting PID values / other things on the SmartDashboard when testing, be sure to save them in the code. Or use something like this: Saving preferences from the SmartDashboard
One thing I like to do is program a “hardware test” mode into the test mode area. It’s a simple program that simply exercises each actuator on the robot.
So, this year, it might run the flywheel, activate the ball mixer (conveyor, fan, whatever you are using to feed balls to the shooter), pickup mechanism, gear placer, turn on the LEDs, etc. Before each match, you put the thing on blocks in the pits, and run each actuator. The purpose of this is to watch the robot and make sure everything moves, and moves in the right direction, when it is supposed to. In other words, it is a check to make sure the pit crew didn’t leave anything disconnected or plugged into the wrong port while working on the robot between matches. If you have sensors that detect position of actuators, use those to verify everything.
It’s a simple thing, and I’m sure the really good teams have at least one method of doing it, and probably more, but some of the less “polished” teams probably just let a student play with the joystick for a minute and call it good.
One other thing that people forget:
Before showing up at the event, make sure you have all the required version numbers on your rio, driverstation, etc. Those things can change after kickoff. Which reminds me…where can I find the required version numbers for the rio, driverstation, etc?
Do you happen to remember what the code change was that “screwed” up your transition from auto to teleop? We had the same thing going on at our 2nd regional this season and are still not sure what’s causing it.
In a nutshell we have a DIO port that we’re checking for a high/low (IR sensor) to create an action. Off the field it works fine and even works normally running Practice Mode, however on the field it immediately fails when Autonomous starts - we have visible lights on the bot to confirm and said lights come back on at the end of the match.
Our programmers have made changes that they’d rather not revert before Champs, and the function the IR sensor provides is not Game Over but we’d love to figure it out.
Semicolons
Watch 2067 at 2015 Hartford qualifications match 60 and you’ll see us slam into the wall during auto, if I remember correctly the robot was programmed to move at 40,000% speed to the side
They’re in the game manual (e.g. the DS version is under R96), but they’re usually easier to find on the inspection checklist (under “Firmware Versions”).
We had an encoder slowly fail on us at our second event - the ring started to slip, at first only a little, but eventually got completely loose - so our auto got worse and worse as the event went on, and it took a few matches to figure out what was really going on. At first we slipped only a few inches and we thought it was a difference between red and blue airship positions, but eventually the robot was doing, uh, dramatic things and we found the problem.
We now have a process where as soon as the robot is unbagged and the hardware is good to go, the software team will deploy our latest code and do a full sensor checkup including recalibrating the drivetrain encoders. If it moves, we move it. If it senses, we make sure it is sensing correctly.
Our next step is to put together a test mode that we can run in the pits and maybe another that we can run on a practice field or at home. For example, one idea I had was to have a test mode that drives the robot out X distance, 180, return back, turn 180 again. If you run the test program and it returns to its exact starting position, then you know encoders/gyro are working and all auto commands are tuned.
Our code has built-in diagnostics run in test mode. We run the full diagnostics periodically to make sure everything is in working order. Here is our test mode code.
We first run the drive motors test. This test spins each wheel of the drive train with low power for 5 seconds. From reading the encoder values at the end, we will know if any of the wheels may have mechanical problems. All encoders should have approx. same reading. If one has substantially less, that wheel has a problem. Then we run sensors test. This test reads all sensors and displays their values on the Smart Dashboard. Since FrcTest extends FrcTeleOp, our sensors test mode has full teleop capability, meaning that we can operate the entire robot when running sensors test as if we are running in TeleOp mode. This allows us to actuate anything on the robot when doing sensors test.
The rest of the tests are for tuning the robot including PID constants.