Currently, our team has little to no experience with a smart autonomous system and would like to improve our situation. We have the FRC Gyro & Accel Board, a USB camera, a raspberry pi, an ultrasonic sensor, and two of the encoder kits from FIRSTchoice. Our experience consists of basic LabVIEW knowledge and a possible outlet for help with C++, but no experience using any of the above options.
While we would obviously love to incorporate a little bit of everything into our design, we want to choose one and do it well. Our goal for autonomous is to be able to place a gear on any of the three airship locations.
Out of what I listed (or anything else you believe to be helpful that’s under $100), what do you think is the most effective tool to help make a working autonomous when considering we have 3 weeks to create a system from scratch?
I would suggest starting off by using just the encoders to get you there. Some trial and error but I think that is the easiest for a new team. If you find you still have time, try incorporating vision. If you can set up a vision routing that will find the spring and place the gear you can use it for both auto and teleop.
First things first is you need to be able track your distance to get you there.
Agreed! A bot with just encoders could probably get it done with some moderate figuring and code. I think the Gyro is very handy and simple to set up and use.
You are on the right track. (I hope you didn’t go with mecanums…)
Small steps I think are essential in building a very effective autonomous. Saying “we want to attack gear position 3” sounds like a very monumental task, but “driving forward 3 feet and stop” and “turning 90 degrees” and “drive forward another 3 feet” don’t sound nearly as bad (those distances are entirely made up, but get the point across). This bottom-up approach is really useful for some simpler autonomous routines as you can really focus on some simpler mechanics in great detail and not worry about the bigger picture.
As far as implementation, PID controller and vision are very likely your friends.
You will also need some switches to tell the robot which Autonomous Code to execute (which peg).
The cheapest is to use Smart Dashbord. However, I am not a fan of Smart Dashboard.
Next is to wire 3 switches to the DIO port of the RoboRio. The problem there is if the team forgets to set the switches (or sets them wrong) and you can’t go back onto the field to fix it.
Our team uses a bank of switches via a joystick emulator. That plugs into the Driver Station. It will also work with the First provided Driver Station if yours isn’t working for whatever reason.
The dashboard is a great tool! Use it to the fullest of your ability. We try and throw any variables we might want to tweak up there. The worst thing is having to recompile code and deploy it to the robot at competition. Using the dashboard helps avoid this.
*there is a typo in my previous reply but I cannot edit it for some reason.
Should be “routine” and not “routing”.
Just an FYI: I learned this year that there’s actually a built-in method in the Driver Station class to retrieve the current alliance and the position on the alliance.
Back to actually doing the autonomous, the most important problem to solve is movement, and as the others have mentioned, the encoders and gyro are the tools you should focus on figuring out how to use.
As for “beginners tools” I imagine you mean something along the command based system where you can write code inside a framework provided for you by wpilib and queue such “commands” up. I don’t know of any such tool for labview but I’m sure it exists somewhere.
Even if and when you find one however, I have to say that in my experience the several such systems I have tried have always been less than useful, not because of some shortcoming on the side of the developers, but because by their nature they put another “black box” between your code and the robot.
I would highly recommend writing your own code when creating the “scheduling” of the autonomous components. (drive straight 3 meters, then turn right, etc…) This is both more reliable in my opinion because the student in charge knows exactly what is going on, and it is a valuable learning experience.
You will be a bit more limited in terms of flexibility and convenience compared to using such a tool, however I believe that the pros of working from scratch outweigh the pros of working with a tool like the Command Based system (not necessarily that system itself itself.)
In fact, even once y’all aren’t beginners anymore, I would still recommend writing your own stuff from scratch, except I recommend writing your own tools that make autonomous programs convenient to write, again both due to the learning experience and benefit of comprehending more of the robot’s code.