Quote:
Originally Posted by alecmuller
Agile was made for software development, but most of the 12 points translate pretty well for robotics.
The biggest challenge is estimating what level of design complexity your team can squeeze into each system integration cycle (i.e. combining the software, the electrical hardware, and the mechanical hardware, then testing and debugging them as a system).
At a minimum you want to be able to do one design iteration (with time for testing!) in the 45-day build season, but I'd argue it's not really Agile with 1 iteration. Ideally you'd shoot for 2 or 3 design iterations in that time. The key is keeping the design simple enough that your team can execute it (design, fab, assemble, test) in 2 weeks, but still sophisticated enough to play the game. Off-the-shelf components go a long way toward keeping it simple.
My team (~40-50 students last year, nearly 50% of them 1st-year) did a good job of keeping it simple last year. We had a robot that drove - and only drove - by day 4 (it really helps to have old robots you can take apart & rebuild), a wood/metal robot that could drive and lift totes by day 17, and our real competition robot started testing on day 31. [We did the driving-only robot because it was our first time with mecanum - this year we'll probably skip that iteration unless we think we really need a weird new drivetrain.]
It's also worth noting that building a 2nd robot helps A LOT. Last year was our first year doing this, and we saw a number of benefits: Less down-time during the build season because software & mechanical weren't competing for time with the same robot (as much). More student engagement in fabrication and assembly. More driver practice with a clone of the competition bot. We think the marginal cost for the 2nd robot was about $2k - nothing to sneeze at for a team with a tight budget, but still small compared to entry fees.
|
Definitely agree about the second robot; our team built a second base last season for the first time, and although it came around a little late, it really helped with allowing everyone to work.
As for design complexity, our team's complex situation might keep us from accessing some of our usual machining capabilities, but not so much as to prevent us from building altogether, although we might have to use more off-the-shelf parts than usual.
You mentioned having a working robot in two weeks; how did you decide the design by then, especially considering your large number of rookies? Did you get a large number of members just building by then? Our team usually has had tedious design meetings that can extend into the second or even third week which involve everyone sitting and debating different design ideas (which is part of the reason why we are looking at agile).