Jump to navigation Jump to search
|Year Of Creation||2009-2010|
|Information and Statistics|
|Farthest Distance||196 feet|
|Highest Finish AutoNav||6th|
|Highest Finish Design||20th|
- Distance: 196 feet
- Design Competition Placement: 20th (673 / 1100 points)
- AutoNav Competition Placement: 6th
Mechanical Design & Issues
- Build a full practice course
- This should be prepared as soon as possible so real testing will always be available. It should have all of the things that are on the real course including various colors of traffic barrels, road blocks, speed bumps, white lines, and a ramp. Since we want the course to be near the Tin Building and none of the areas around there will allow us to paint the grass, the white lines should be simulated with painted boards or white tape. The ramp should also be very portable, but sturdy enough for someone to walk on.
- Design and build a new mechanical base
- (TODO: split this into smaller sub-tasks) We would like the new robot to be more off-road capable than Candi. While Candi's ball caster design is great on flat, smooth ground, traversing ramps and gravelly areas caused problems. Building an off-road would also allow us to use it as a platform for other competitions such as RoboCup Rescue and the University Rover Challenge. For this to happen, the new robot would need to have multiple mounting points for other sensors and manipulators used in those competitions but not in IGVC. The new robot should also be water-resistant, as we had issues with rain at the last competition. We would also like the new robot to be smaller than Candi, which had more internal room than we ever used.
- Cable-management system
- In Candi, we often needed to re-route cables, which is really annoying when zip-ties are used to hold them in place. For both robots, we need a more convent way to route and re-route cables.
Electrical Design & Issues
- Motor system for new robot
- Design on this should not begin until mechanical design is well underway. We will need a different, probably smaller, motors for the new robot. The motors we use for Candi are overkill, so they will be far more powerful and expensive than needed for the new, smaller robot. It would be possible to use the same motor controllers (OSMC) as are used on Candi, then the same motor interface board could be used, too. However, the OSMC is fairly expensive and is likely be more powerful than needed. In any case, the new motor controller should be electrically isolated to prevent coupling noise from the motors and possibly damaging the digital electronics. The least expensive solution will be to build or buy a motor controller that meets the motor's power requirements and also has the isolation circuity and a digital interface on-board.
- New E-stop system
- Design on this should not begin until mechanical design is well underway. The new robot will also need a new e-stop. It is fine if it is a copy of Candi's e-stop, so long as a good relay is chosen. If we have the time, it would be nice to find a new wireless transmitter which doesn't require the button to be held down for so long.
- Power supply
- Design on this can begin immediately. Last year, the robot was powered with separate batteries for each device. This worked, but was annoying because each battery had to be charged separately. We should build a power supply that is powered off of the main batteries that provides regulated power to everything on the robot. The supply should be designed so it can be used for Candi and the new robot. This means that each rail should be able to provide more current than needed in case more devices are added to either robot. It is fine to buy this, but it might be difficult to find exactly what we need. A very nice but optional feature is to have the ability to run the robot and charge the batteries off of an AC socket. This will however make the power system harder to design.
- Design on this can begin immediately. This will be the same for Candi and the new robot. Design was begun on this last year, but not finished. It will have 3-axis accelerometers, gyroscopes, and magnetometers.
Software Design & Issues
- Enforce deadlines
- Deadlines and milestones are useless if they aren't enforced. While this is a voluntary club where we can't force anyone to do anything, team leaders can prevent people from doing work by pull funding and other resources from a task. It is the job of everyone in the team to ensure that all of the members are making progress on the work for which they have taken responsibility.
- Obtain an outdoor LIDAR
- Our team is one of the few IGVC teams that have gone without a outdoor LIDAR, mainly because of lack of funding. It has made the tasks of vision and navigation significantly more difficult. Next year, we should try as hard as possible to buy or find someone to donate a LIDAR.
- Create good documentation
- If we want to use the new robot as a platform for other competitions, we have to make a concerted effort to document our design. Traditionally, we have only created designs for our own personal use, but the new robot may be used by many different people. This means that all of the design files (including CAD drawings) should go into SVN and everything should be documented both in SVN and on the wiki.