Scioly.org

Personally, I really like the technical documentation requirement, as it has required my students take a step back and analyze their robot a bit more carefully instead of just throwing something together. I have two students who actually became so interested in the technical documentation that they taught themselves Google Sketchup (we don't have any CAD software in our district) and developed impressive documentation...they are as proud of the documentation as they are of their robot, which finished in the top 3 at Wright State last weekend. I would be willing to guess they have put in at least 10-20 hours on the documentation over the past couple of months, and at least 20 hours into the robot, through probably much more. Unfortunately in Wisconsin, Robot Arm isn't an event this year at regionals/state (instead they are doing Sumo Bots again this year...ugh), but my students nonetheless had a blast working on it and are hoping it will be around again next year, including the technical documentation (including in Wisconsin, though I know that is a state-by-state issue, not a national issue).

chalker wrote:

Flavorflav wrote:Chalkers, and any other individuals reading this who have the ability to provide input into next year's rules, would you consider lightening the paperwork requirements? My lead robot guy spent five hours yesterday doing the documentation in preparation for our regional today. That's a lot of time for something that isn't even being graded except as "complete" or "incomplete," and which by its nature has to be done at the end, so doesn't really reflect the design process. It also doesn't prevent Daddy-builts, either, as far as I can tell, which makes it seem like hoop-jumping. Yes, I know it is something that real engineers probably do, but we don't require it in tower where it would be easier and arguably more useful.

5 hours doesn't seem that unreasonable to me.. particularly compared to how much time many students put into various studying events learning various topics, many of which they end up not being tested on at all. In addition, the grading isn't truly 'pass' / 'fail'. If you look at the scoring formula you can have anywhere from a 0% to 30% (in 5% increments) impact on the scores (thus instead of a 2 value grading rubric we essentially have a 7 value rubric).

That said, we are always open to suggestions. We don't want this event to be a pure 'robot building' event, so we need to have some sort of additional component to it. Any ideas what else that could be?

I don't have anything against requiring some documentation, although I admit I'd probably hate it if I had to do it myself. Anyway, maybe instead of requring students to document the final device, we could have them document the process to the final one. What they tried, what worked, what didn't. This would allow them to document as they build. I believe it was boomilever that required something like this at one point. I understand cost is an issue for many teams and I'm not at all saying teams would have to build multiple prototypes of their bots. For example, say I design a bot with a gripper and then I might think "I wonder if a magnet will allow me to complete the task faster and with less error?" Well I'd try it and document the results. Just something that says "We tried x, y, and z. This is what worked well, what didn't." I think documenting the process is more valuable than documenting the final product.

What was your reason for having us document the finished model? If the rules required some sketches, I can see how that would aid in designing the robot, but I don't seen any value in drawing the finished product.

illusionist wrote:What was your reason for having us document the finished model? If the rules required some sketches, I can see how that would aid in designing the robot, but I don't seen any value in drawing the finished product.

This is to model real-life engineering practices. Being an engineer at a company or research institution means you generally spend more time documenting your ideas than playing around in the shop. Every component that we selected to be required is modelled after things real engineers produce every day.

The documents aren't meant to be a final step, but actually an evolving component of the design process. In fact, I would suggest by starting off with the proposed strategy/plan of movement to begin having basic conversations about what your robot will look like. Then, start sketching the design out. I'd suggest using some free computer drafting/design software such as Sketchup, 123D, freecad, or even things like Inkscape. Once you have a rough outline, you can then resolve general issues and have a general plan of attack before stepping foot into a workshop or spending a dollar on materials. You can make modifications to the drawing without rebuilding anything or an incredible amount of effort.

Once again, this is how the real world works and it's a much better way to design/engineer/construct devices than just running off to the shop with a pile of materials and no plan.

chalker7 wrote:

illusionist wrote:What was your reason for having us document the finished model? If the rules required some sketches, I can see how that would aid in designing the robot, but I don't seen any value in drawing the finished product.

This is to model real-life engineering practices. Being an engineer at a company or research institution means you generally spend more time documenting your ideas than playing around in the shop. Every component that we selected to be required is modelled after things real engineers produce every day.

The documents aren't meant to be a final step, but actually an evolving component of the design process. In fact, I would suggest by starting off with the proposed strategy/plan of movement to begin having basic conversations about what your robot will look like. Then, start sketching the design out. I'd suggest using some free computer drafting/design software such as Sketchup, 123D, freecad, or even things like Inkscape. Once you have a rough outline, you can then resolve general issues and have a general plan of attack before stepping foot into a workshop or spending a dollar on materials. You can make modifications to the drawing without rebuilding anything or an incredible amount of effort.

Once again, this is how the real world works and it's a much better way to design/engineer/construct devices than just running off to the shop with a pile of materials and no plan.

I think there is some disconnect between this idea and how things actually happen. Designing before building is the preferred method of building anything, but with the lack of proper materials available it's not practical all the time. From my experience building for SO, the final product depends on what I have available. Sure, I could draw something out and try to make it, but in order to keep the costs low, I need to be surrounded by a bunch of junk and let my imagination run to figure out how I can turn this stuff into a working device. Teams who work in a similar way will find the documentation frustrating and pointless. Yes I understand this isn't the best (not even close) way to build something, but sometimes that's just the way you have to go.

sachleen wrote: I think there is some disconnect between this idea and how things actually happen. Designing before building is the preferred method of building anything, but with the lack of proper materials available it's not practical all the time.

Which is even further reason for us to have a documentation component. It exposes you to aspects of the 'preferred' method of engineering which most teams if left to themselves would never experience.

I find the component list to be the most frustrating. If someone wants to make a tweak of some sort before the competition, they have to go back through and add/delete things from the list.

Flavorflav wrote:Chalkers, and any other individuals reading this who have the ability to provide input into next year's rules, would you consider lightening the paperwork requirements? My lead robot guy spent five hours yesterday doing the documentation in preparation for our regional today. That's a lot of time for something that isn't even being graded except as "complete" or "incomplete," and which by its nature has to be done at the end, so doesn't really reflect the design process. It also doesn't prevent Daddy-builts, either, as far as I can tell, which makes it seem like hoop-jumping. Yes, I know it is something that real engineers probably do, but we don't require it in tower where it would be easier and arguably more useful.

Just a heads-up: my partner and I spent less than an hour on our robot arm documentation for our regionals competition. I'm not proud — not at all — but luckily at the lower levels it's not a horribly significant component that can ruin an otherwise good robot.

We started work on our robot literally last Friday. Don't get me started: invitationals was late this year, it took us a week to get teams together, and then it was midterms week. So our A Team didn't start building until a week before regionals. Entirely our (my?) own fault, but frustrating all the same.

So I agree with both camps on this. With only a week, my partner and I sat down with the Vex kit and modified the Protobot instructions on the fly to create an arm. Then we looked at the thing, decided where to stick a base, looked at it again, and stuck a claw on the end. Which didn't work, so we added wheels to the claw. By Friday night, we had a semi-working robot. Only then did we quickly sketch it up, list components (I had to completely guess at dimensions to save time), and scribble together an operating description. In this instance, developing those technical documents was a useless chore.

For states, though, we have seven weeks to get this thing in shape. I can see the use in modeling it ahead of time, but I probably wouldn't if it weren't part of the event. So I'm glad to have the incentive to sit down with SketchUp or Inventor and draw our robot the way it'd be done professionally.

buzzbuzz wrote:I find the component list to be the most frustrating. If someone wants to make a tweak of some sort before the competition, they have to go back through and add/delete things from the list.

Agreed. I'm still not sure I see the purpose of the component list. If it's to verify safety, can't we just list the dangerous stuff (batteries, compressed air tanks)? If it's to verify we built it, couldn't the supervisor just pick out four objects on the device without a list? Unless it's something else, chalkers?

Primate wrote: I find the component list to be the most frustrating. If someone wants to make a tweak of some sort before the competition, they have to go back through and add/delete things from the list.
Agreed. I'm still not sure I see the purpose of the component list. If it's to verify safety, can't we just list the dangerous stuff (batteries, compressed air tanks)? If it's to verify we built it, couldn't the supervisor just pick out four objects on the device without a list? Unless it's something else, chalkers?

Engineers use things called "bills of materials" all the time. This is essentially an inventory of whatever the device or project includes. One can make a bill of materials that is only a couple of components long for a simple object like a pen or one that has (literally) millions of components if you were to make a full bill of materials for a factory (one of the people on a tech committee's primary job is working with these bills of materials for factories). Any professional bill is much more detailed and is often the most important engineering document you can produce. It includes things like the source and cost for reordering supplies, every measurable feature on the component (in case you need to replace something or during the design process, don't have a physical model to use) and many many other features.
Working with a list of components enables you to start thinking like a professional engineer and also gives you a handy list to reference when packing up for competitions so you don't miss anything or if you want to bring spares in case of the robot breaking (don't forget the batteries!)

chalker7 wrote:

Primate wrote: I find the component list to be the most frustrating. If someone wants to make a tweak of some sort before the competition, they have to go back through and add/delete things from the list.
Agreed. I'm still not sure I see the purpose of the component list. If it's to verify safety, can't we just list the dangerous stuff (batteries, compressed air tanks)? If it's to verify we built it, couldn't the supervisor just pick out four objects on the device without a list? Unless it's something else, chalkers?

Engineers use things called "bills of materials" all the time. This is essentially an inventory of whatever the device or project includes. One can make a bill of materials that is only a couple of components long for a simple object like a pen or one that has (literally) millions of components if you were to make a full bill of materials for a factory (one of the people on a tech committee's primary job is working with these bills of materials for factories). Any professional bill is much more detailed and is often the most important engineering document you can produce. It includes things like the source and cost for reordering supplies, every measurable feature on the component (in case you need to replace something or during the design process, don't have a physical model to use) and many many other features.
Working with a list of components enables you to start thinking like a professional engineer and also gives you a handy list to reference when packing up for competitions so you don't miss anything or if you want to bring spares in case of the robot breaking (don't forget the batteries!)

If you do things in the proper order, I suppose that makes a lot of sense... fair enough!