So every year our 1 or 2 programmers inevitably have nothing to do and, while we still like for them to show up to meetings, they literally have 0 idea how to build or do strategy and they don’t really want to do that either. What projects should they be working on while the robot is being built?
Build the backbone of the program. Test algorithms. Learn how to do odometry. 90% of the program can be written without an actual robot, it just requires more thought.
Here’s some ideas.
Have them learn about PROS 3, okapiLib, or LGVL (which will eventually come to PROS).
Or they can work on flag tracking for the vision sensor, reliable PID auton functions, Rerun, Gyro Filtering, Motion Profiling, or as above Odometry.
Learn the nuances of C++. Learn how to use VCS and it’s API. Learn RobotMesh’s API. Dig deep with PROS’s API.
Make a velocity PID for an eventual flywheel.
That should keep anyone busy for a bit
Side note ideally your programmer is your chief strategist and is on the line with the driver actively feeding the most relevant info to the driver, that the drive might not already realize. Back on topic they should be planning autons, developing control structures, automation of common tasks, researching the math required and associated tasks for effective gyro and accelerometer (I can’t spell) usage. Ideally the programmer plans for future bots and works on that code when he has free time. Basically the programmer should always be planning ahead, that means he should be involved in robot design so the proper sensors can be planed for and quickly implemented without a rebuild/ redesign of a region of the robot.
Our programmer already knows RobotC inside and out (as far as any of us can tell). I’ve asked him several times to work on PID and the likes but he insists that it is not effective with VEX’s low quality encoders/sensors and apparently has tried before. Considering many people on here talk about that stuff I can’t imagine that being true, so I don’t know what to say to him.
Are you using V5? If so RobotC doesn’t work with V5. Have him learn PROS.
PID is most definitely effective. Tell him to post on here, we’ll help him out.
not sure how willing he’ll be to trying to get help on here because, not that he’s arrogant - he’s not at all, but he seems to really think PID just won’t work. I’ll try to persuade him though, thanks. He probably already knows about the PROS thing since i think he has looked into V5, but I’ll ask him.
Pid is very effective when done right. Most likely he didn’t tune it right, so that it looked worse than timing. Encoders aren’t bad quality, so if you use those, then you’ll be fine. Gyros are a bit trickier to filter, but still make it more accurate.
We’ve had the build team build a base or a simple robot and had them practice programming and learning. A goal should be to learn every sensor. Write a line following routine. Practice lifting an arm to a specified height. Do multiple actions with multiple sensors. See whether a gyroscope or encoders are better for turns. There is more than just PID. Also, anticipate the skills you will need in the upcoming season and have your programmers work toward those strategies. Have you programmers also participate in the Engineering Notebook process. Work on on-line challenges. Plan team outreach.
The programmer’s goal should be to put the driver out of a job. As long as you still need a driver, then there is room for improvement.
Alternatively, they are not going to be the programmer for life, so structuring their code, using good style, commenting, and generally making the code as user friendly to the next person is far from a waste of time.
Even building up a library of useful and efficient functions that don’t necessarily apply to the current robot has a lot of value.
Yes. Code reuse is key! I tell my team that in the professional world a line of code could cost $10, $100 or more. Have a library of well documented* functions (drive straight, turn a certain number of degrees, toggle between two or more states, etc) can save a ton of time in the future. And, in the professional world save money, too.
Feedback loops such as PID have been proven to be useful time and time again in VEX. While the sensors available aren’t the best, they defenitly aren’t the worst either. I’d generally stay away from the gyro in favor of encoders due to drift issues (though I’d recommend testing it yourself), but other then that, you’re probably fine.
Your programmers could always be working on building up a set of useful libraries that your team can use from year to year, or they could be testing different algorithms such as PID on a simple test rig they could build (and yes, programmers can build too) instead of instantly dismissing them. They should get creative, maybe do something like try to constantly track the robot’s position on the field so it can make automatic corrections during autonomous and be more accurate and consistent during long runs, such as autonomous skills.
As others have said before me, any repetitive action that your driver has to do should be automated as much as possible. The less things you have your driver focus on at once, the more consistent they’ll be. Last year, we (and many other teams) automated basically everything; to stack a cone, the driver would just drive up to it and hit a button, to unload a mobile goal, the driver would just drive up to the zone and hit a button, the lift would automatically raise to the right height and unload it, and to pickup a cone against the wall, the driver would just press into it with the front of the robot, and again, hit a button, and it would automatically back up the correct amount and stack it. If you want examples of it in action, most of this can be seen here.
The point is, there are always things for programmers to be working on. They should always be learning and trying new things, and if they think things like a PID feedback loop won’t work, they should be finding a better alternative.