Quote:
Originally Posted by Michael Corsetto
1. Are there any other team's that don't use sensors? Why? With what results?
2. Should FIRST provide bigger incentives within game design to utilize sensor feedback systems? For instance, 2005 had the random-placed vision tetras, 2007 had the rotating rack, Big Ball placement in 2008, etc. In recent years (2009-now) though, there has been little "randomness" in game design that would require advanced sensor utilization. What would a change in "emphasis" mean for FIRST teams? How much stretching in this area is appropriate?-Mike
|
Mike,
I mentor a couple of different teams in my area besides by "home" team so I'll share with you some mixed view points.
One team tends to avoid using sensors as it makes it complex to program as in your case. They do use some, but, would rather not if they don't have to. They believe manual operator by the drivers is good enough. They do fairly well competitiveness wise.
A 2nd team, believes that sensors are important and are making strides to incorporate them into their designs. They believe that with sensors working properly they can automate many functions. By having the machine do it for them faster and more accurately than by human operator control. This team has up and downs competitiveness wise, but, they accept them as growing pains. They believe as long as they improve over last season they are progressing.
Yet a 3rd team believes sensors would be an enormous improvement for them, but alas they simply don't have the funding to invest a few hundred dollars for sensors like, encoders, pots, CAN, etc... They can barely scape together the 5K needed to compete. So they are mostly manual mode operations. They struggle to compete, but, they too are constantly improving.
Disclaimer.....
My own personal "dream" would be to design a machine with the proper sensors, the proper software and the proper control system that has only 2 Joysticks for the driver, and 2 buttons for the manipulator operation.
1) Drive to area near game piece
2) Press button one to acquire game piece(s) (time approx. 0.25 seconds)
3) Drive to scoring area
4) Press button two to score game piece(s) (time approx 0.50 seconds)
This would require lots of automation. BTW Automation doesn't always mean complex code either.
Now to answer about pushing the needs for sensors...
I've always believed their should be 3 tiers of challenges for autonomous mode.
Tier 1 - Basic primitive, something a moderately skilled rookie team could succeed at.
Bonus 1X
Tier 2 - Some sensors required, fairly simple code. The start or end points or goal locations change just before autonomous starts.
Bonus 3X
Tier 3 - Some sensors, lots of code. Complex, a real reach. Something very challenging like the targets move, and/or change color during autonomous.
Bonus 5X