We’re making a list of everything we’re using this year, and we’re basically done. I’m kind of curious what everyone else is doing for sensors.
Our current plan is:
UART1: LCD Screen for Autonomous Selection
UART2: LCD Screen for Sensor Outputs (Removed for Competition)
I2C: 10 IMEs Daisy Chained
Analog:
1: Gyroscope
2: Accelerometer
3: Line Tracker
4: Line Tracker
5: Line Tracker
6: Line Tracker
7: Line Tracker
8: Light Sensor
Digital:
1: Ultrasonic Range Finder Input (Front)
2: Ultrasonic Range Finder Output (Front)
3: Ultrasonic Range Finder Input (Back)
4: Ultrasonic Range Finder Output (Back)
5: Ultrasonic Range Finder Input (Left)
6: Ultrasonic Range Finder Output (Left)
7: Ultrasonic Range Finder Input (Right)
8: Ultrasonic Range Finder Output (Right)
9: Limit Switch
10: Limit Switch
11:
12:
Speaker:
1: Speaker
Motors:
1: BuckyBall Intake
2: Arm
3: Arm
4: Arm
5: Arm
6: Drive
7: Drive
8: Drive
9: Drive
10: Large Ball Intake
I’ve also been instructed to ask what we should be doing with the last two Digital Ports. We don’t want to leave them empty if there’s something we should be using that we’re forgetting.
And has anyone had experience using the Light Sensors to detect the color of objects? We wanted to use them during the Autonomous mode as a sort of safeguard against bad programming.
I’ve always wanted to try to use the light sensor to determine what color the ball is. I might try it this year, but it’s probably easier just to drive and program well and don’t derp.
We are using a gyro, some encoders, a couple of ultrasonic sensors, and a potentiometer. We were thinking about line sensors but given our chassis design I don’t think we can get them close enough to the field surface for them to work. If the field is set up as it should be we do not expect problems with picking up the wrong color unless the robot is going haywire where we don’t think color recognition would help. The color recognition is a really neat idea that I would love to see someone do!
Since we are still neophyte programmers I think the sensors we have chosen will push the limits of our current skills and knowledge unless we can recruit a really savvy programmer which is highly unlikely where we live hence the 1 member team.
Does it help if you use a coloured piece of plastic film over the sensor as a filter? It’s explicitly allowed in the manual, but I’ve never tried it.
Why, exactly, do you need so many sensors? You only need 3 line sensors to follow a line (though you can use others for line detection at the same time I guess), unless you’re doing an avoidance routine you don’t really need omni-directional ultrasonic sensing, and if you’ve geared together motors in your drive, you don’t need IME’s on all of them (also, intake motors). It’s definitely going to be a lot of wires even if you can use all of them, but I’m not seeing the point.
We’ve done fine in previous years with 2 optical encoders (with only one wire plugged in for each), a potentiometer, one line tracker and a few jumper pins for autonomous selection. Unless you need the extra sensors for a specific function, I don’t think it’s worth having them.
By the way, accelerometers use 3 analog ports - one for each axis. And, if I’m not mistaken, they can be used to track position by integrating, but I haven’t done it before.
This year, since I get to finally design and build the robot that I will program, I’m going to be a bit more experimental and abandon encoders.
Gyroscope & accelerometer combo for an inertial navigation system. Potentiometer on my elevation mechanism. LCD for autonomous selection. Two limit switches, and perhaps a bumper switch.
It’s been a few years since I’ve had a great autonomous routine due to robot designs and other factors, so I’m glad to get back into the rhythm and make an awesome autonomous.
Yes, the film does help a bit, but it doesn’t help that much and isn’t entirely necessary.
For the accelerometers, yes you can get position by integrating the accelerometer values twice and it can be very useful, but it is a project that ends up requiring a bit of work.
I would advise against this. I’ve done my own testing with this. Because the refresh rate of the accelerometer is so low, it doesn’t capture the accelerations fast enough and ends up drifting meters away very quickly. Think Euler’s method.
Why would you need to have 10 daisy chained IMEs? I only see the use of four with six being absolute max. Unless you were planning on using mecanum wheels, then there would be a reason for another two.
On a more serious note, don’t use all your sensor ports for the sake of using all your sensor ports. Find out which sensors you need to accomplish a task, and then use those. It’s also always a good idea to leave a couple ports empty just in case, unless you actually need to use them all.
For example, you may decide in competition that you need the ability to disable autonomous on the spot. Then you quickly program one of the digital ports to be a “disable autonomous” port and you could put a jumper in there.
We are using Mechanum. One will be on each of those wheels, one on each intake, and one on the Arm is seven at the minimum. We’re probably going to stop there, in reality. I was told last night RobotC will only do a maximum of eight anyway. The Mechanum Drive is also why we have 5 (maybe 6, seeing as the Accelerometer actually takes 3 ports, not one) Line Sensors. It lets you do line following while driving forward and backward, as well as strafing.
To the guy asking about the 4 URF, we use their distances with conditional statements to figure out which starting tile we’re on. Based on the orientation of the robot and the four readings, it can just know that it’s on the “Blue Hanging” or “Red Middle.” We did it last year in Sack Attack for Left/Right. We need 4 this year, because not every program will have the same starting orientation. Yes, there was a manual correction to the tile detection, but in 50+ tests they never needed to use it. With the bonus this year being so significant, we’re making sure our Autonomous Routines are as perfect as possible. Additionally, you can use them at points during an Autonomous Routine to fix any minor errors that have occurred by changing the distance driven based upon the readings.
As for disabling Autonomous, that’s an option on the LCD Screen. It has the side and tile you’re on visible on the first screen, where they can be fixed if the autodetection failed. You scroll around to find the mode you want with the left and right buttons. You press the center button to select it, at which point it takes you to a confirmation screen showing all 3 of the data points you need to check(side, program and color). If they’re wrong, go to the appropriate screen and fix them. Last year, we had 5 programs per side (left versus right), including one that was a simple “Drive forward so you’re under the trough” and a “Do Nothing.” We were really happy with how well that turned out, and plan to do it again this year.
Well I don’t know about everyone else who seem to have already decided they will be using a huge number of sensors, but I’ve always found that the more unnecessary sensors there are, and the more conditions that have to be met for the program to proceed, the slower everything becomes.
We will be using for sure:
2 x quadrature encoders
1 x gyro
1 x bumper
And seeing as we are considering a piston lift, no potentiometer at the moment. Might throw in a few light or ultrasonic sensors as we need them, but only if using encoders and the gyro is inconsistent. I guess we believe that simpler is better, and why have extra sensors if you don’t need them?
Our team has not officially decided, but my hope is…
-----Analog-----
1: Gyroscope
2: Lift Pot
3: Auton select Pot
4: Power Exp voltage
5-6: 2 Line Trackers, middle-edges
7-8: 2 Line Trackers, front-center
-----Digital-----
1-2: Ultrasonic (Front-Left facing left)
3-4: Ultrasonic (Front-right facing right)
5-6: Left Encoder
7-8: Right Encoder
9-12: Pneumatic actuators (IDK what for yet)
-----Motors-----
1-6: drive
7-10: lift
(passive intake; not sure on how it will work yet.)
-----Other-----
UART1: LCD Screen for Menu/Auton select
I2C: Empty. (Had trouble with IMEs.)
Speaker: Speaker. (Obviously.)
Of course, when the bot is built, the specs will most likely change.
The lights for grabbing an object isn’t a bad idea at all. We might use that.
Battery levels are on the second LCD. Before a match, you plug it in and run through all of the screens. It shows you readings for every sensor so you can be sure they are all working. Run all 10 motors after that, and you know you’re good to go. If any of the 3 batteries are low (below 8v), it tells you which one to change. We REALLY like the LCD screens for stuff like this.
We have been having issues tripping the breakers in the Cortex. Is it worth putting half the drive motors in 1-5 and the other half in 6-10. The same with the arm. In theory this would spread the load over two breakers. Hard driving or heavy lifting with the arm could be separated by the driver and simultaneous would still be an option to the driver in moderate situations.
