• Search for:

• Recent Posts

  • The Final Presentation
  • Planning for Implementation
  • Divvying Up Design
  • Website Design
  • Thoughts on the Design Doc

• Blogroll

  • Barnyard Software: Project Free Lunch Farm
  • Smackababy: Business Language Certificate for Software Engineering
  • Software Engineering BLS: BLS Software

• Archives

  • November 2007
  • October 2007
  • September 2007

• Site Stuff

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org

It’ll be 20-30 minutes and covering everything.

We’ve got a Speaking Center appointment at 2 p.m. on Monday, December 3. We’re not rehearsing the whole presentation, just transitions, introductions, etc.

Post thoughts or suggestions here.

Since part of our job is going to be instruction on how to build these modules and others, I think we should plan for certain points to take screenshots of ROBOLAB code so that we have a visual representation for the instructions. Module by module, here’s roughly how I think we should separate these screenshots:

Mindstorms in Motion
1. Since this will be our first module, we should probably just have a screenshot of the wire without anything on it.
2. A screenshot of the wire when the robot is able to move forward indefinitely.
3. A screenshot of the wire when we add functionality to have the robot change speed.
4. A screenshot of the wire when we add functionality for the first turn.
5. Finally, a screenshot of the wire when the module is completed.

Grappling Arm
1. Just to drive it home, let’s re-use the blank wire screenshot at the beginning.
2. A screenshot of the wire when the arm can pivot.
3. A screenshot of the wire when the arm can grasp.

CameraBot
1. A screenshot of the wire with after any new bricks have been added; since this is still a motor module, we may be able to be relatively brief about the programming for this one.

Beep Button
1. A screenshot of the blank wire again.
2. A screenshot of the wire when touch sensor functionality has been added.
3. A screenshot of the wire when the beep command has been added.

Driving into Walls
1. A screenshot of the wire with basic movement functionality already implemented. By now, these bricks should be familiar to the user.
2. A screenshot of the wire when we add a touch-sensor-initiated fork.
3. A screenshot of the wire after we’ve implemented what happens on the fork. The stuff inside the run-into-something path should be mostly familiar to the user, save for the random number, which we can explain.
4. A screenshot of the wire after the jump for the program has been added. This should be the complete module.

Bright Lights
1. A screenshot of a blank wire again.
2. A screenshot of the wire with the light sensor functionality added (though it does nothing yet).
3. A screenshot of the wire when the light sensor has been set-up to record its data, accompanied by a screenshot of the graph produced in ROBOLAB.

Following Lines
1. A screenshot of the wire with basic movement stuff set-up.
2. A screenshot of the wire when the program is set to make the robot move only when it detects a line.
3. A screenshot of the wire when the program is set to make the robot search for a line when it loses sight of it. This should be the complete module.

Twister
1. A screenshot of the wire with basic movement and light sensor set-up.
2. A screenshot of the wire with the fork for the light sensor input set-up, with nothing in it yet.
3. A screenshot of the wire with the first activity on the fork programmed.
4. A screenshot of the wire with all activities programmed. These should all be things that involve bricks the user is familiar with, so a textual explanation should suffice.

Steering Wheel
1. Blank wire again.
2. Rotation sensor added.
3. Beep set-up.

Vernier Probe
We’ll need a couple of screenshots here, including one for LoggerPro, the Vernier probe data collection program, but since the module will not contain any new bricks or methods, we can be fairly arbitrary about where we put the screenshots.

Robot Relay
We’ll definitely need screenshots showing how to set-up communication between robots. Other than that, screenshots of each separate relay module would be a good idea, but since the bricks and methods won’t be new, we don’t have to dissect them.

See you at 3:15.

Yes, I like alliteration.

With the Design Doc due in a week, we need to split the work up and decide on how we’re going to do things otherwise. I suggest we split things up by section initially, then edit the whole ordeal together.

I figure I’ll write the Introduction section again. Brent should do the Module Decomposition, I think, since that will be the one that requires the most knowledge of how Mindstorms and ROBOLAB actually work, and he’s definitely the most fluent in the LEGO stuff. Other than that, we’ll have to do the normal title page and Table of Contents, the Scope section, which is largely diagrams that we’ve more or less gone over but will still be a bit time-consuming (and we’ll want to make sure the diagrams are just right), the Hardware section, which is pretty simple, even considering the extra hardware (that is, the Legos) that we’ll be dealing with, the System Design section, which is mildly peculiar but shouldn’t be too bad (I’d be very willing to write that section if no one has any objections), and, finally, the Appendix.

As far as getting this done goes, I think we should do our parts in Google Docs (despite some of the hiccups we had before, I think that’s still probably an easier option than throwing Word documents around). We can do them separately if we want, but if we do I think we should still give permissions to everyone else to view each doc. I’ll cover main editing and such, at least for grammar and all, but we should all be checking on everyone else’s work and voicing any concerns we have.

Finally, Dr. Polack has said that she will look at individual sections of the paper, so we don’t have to feel like we need the whole thing done by, like, Friday or something; if we tell her who is responsible for each part, then only one person’s grade will be endangered if someone decides not to avail themselves of her editing services ahead of time. It might still be nice to have a finished product a little ahead of time, but we don’t need to view that as an absolute imperative.

So here’s how I think it’s looking at the moment:

Title Page & Contents - no one yet
Introduction - Me
Scope - no one yet
Hardware - no one yet
Module Decomposition - Brent
System Design - Me (unless someone else really wants it)
Appendix - no one yet

It may also make sense for someone to help Brent with some of the more tedious work in Section 4. I think there are some irritating diagrams and things that we’ll have to do for each module, and there’s no reason to saddle him with all of it. For that matter, we can all pitch in on the diagrams for Section 4, so each person only has to do a few.

So, comment in your thoughts on division of labor and what parts you would be willing and able to do.

Also, who’s doing this presentation? That’s not due until the Monday after we turn in the paper, so you’ll still have almost a week after the paper is finished, but you’ll still want to schedule a Speaking Center visit for sometime next week.

Okay, so we’ve seen everyone’s prototypes. We had some common features - navigation on the left-hand side, for instance - but we need to decide what we are using for the things that are different. I, for one, rather liked Juliette’s color scheme, and we do want video, of course. Elliott’s was really easy to navigate, I thought, and had that handy link to the Mindstorms homepage and suchlike.

We need to have these decisions on paper by Monday, so what parts do you guys want to throw into the final site?

First, the assignment specifies that each person must write at least three pages and also turn in an explanation of what they contributed to the document.

Second, although the robot is described as the user (not the human), I assume some explanation of what we are going to do for the webpage should be given. We did after all turn in a prototype of it.

These are a few sites I referenced while building my prototype:

This site describes accessible HTML coding.
 http://www.webstandards.org/learn/tutori…

I went nuts trying to embed video in my prototype webpage, but eventually was able to get it to work. We could simply use the user’s internet browser to play video, if we have time to record video.
 http://csscreator.com/node/15265
 http://www.ozzu.com/ftopic23407.html
 http://www.w3schools.com/media/media_bro…
 http://community.vietfun.com/showthread….

This was the snippet of code that finally worked:

Okay, so here’s what we’re looking at for the Design Doc. I don’t think it’ll be too bad, but it may prove a bit tedious.

1. Introduction
This shouldn’t be a big deal. It looks like the same basic thing as the introductions to our previous papers.

2. Scope of the System
This one might be a little tricky. Section 2.1 requires a system-level use-case diagram, so we probably want to figure out with Dr. Polack exactly what she wants from us in that regard. I’m not sure how well our project suits a system-level diagram. Section 2.2 isn’t a big deal; that just discusses deliverables, which is easy enough. Section 2.3 is our context diagram, so that’s just a matter of making it based on the one we’ve done in class. Finally, 2.3.3 will be the interrupt-driven system model.

3. Hardware, Software, and Network Specification
This should be another simple section. We’ll need to mention not only the computer requirements, but the Mindstorms stuff itself, but that’s not a big deal. I don’t think we’ll have a network, unless Dr. Polack wants us to count interaction between robots, and between the computer and the robots.

4. Module Decomposition
Here we might have to get a little creative in certain sections, notably 4.2 and 4.3. Everything else will be a little weird, but I suggest we base most of what we do on our individual modules. Then, I think things will work out without too much difficulty.

5. System Design Description
Finally, this section has some parts we may not need (like 5.4: Security Strategy), though we’ll have to clarify that with Dr. Polack to be sure. Section 5.1 will be the coding standards we use for our ROBOLAB modules. For Section 5.2, we might want to ask if Dr. Polack wants a description of the website, or if we should stick to the inputs the robots get.

The last section is another Appendix; we should just make sure that it has what it needs this time around.

-Brandon

My first entry is a neat website foxbox.nl which features various ways to assemble lego mindstorms kits to create robots that perform particular tasks. This site may be useful in the future as it contains quite a few different designs.

 http://www.foxbox.nl/lego/index.asp?FRMi…

Also, anything else I find will be posted as an addendum.

We started writing up the spec on Wednesday. We’ll need to meet several more times to finish it.

Thursday: meet 3:15 p.m. in Trinkle B12 until . . . ?
Friday: meet 11 a.m. in Trinkle B12 until . . . ?

Post on this thread in order to keep everyone updated on progress.

–Juliette Zerick

P.S. I will have to leave briefly at some point to ship out a package.

These are my notes from the meeting on Monday, October 8.

First, we need a disclaimer for teachers to inform them that the modules are sturdy. Maybe not for off-roading, but sturdy enough to survive classroom hazards. Also, there are several modules that were created in previous projects (one on CD, another perhaps done by a CS major for an old honors project).

We have several modules planned for each sensor as well as modules that combine multiple sensors. We will also be suggesting possible project ideas for the student teachers, tying in additional concepts such as ecology, physics, etc.

MOTORS (three modules and two possible tie-in projects):
Description: Several aspects of the motors can be configured: power level, speed, direction, and duration.
Warnings: Don’t attempt the modules with the robots on a table. Gravity happens.

Modules:
1. We start with a module just with the most basic operations–moving forward, turning, etc.
2. The motors could be configured to form a grappling arm that could pick up objects (or just flex).
3. A more advanced project would involve moving a webcam around; the camera can’t be interacted with through ROBOLAB, so the robot would simply be a carrier. The robot could be piloted on an expedition into the hallway or spy on the classroom nextdoor.

Possible tie-in projects:
1. Physics: Surfaces and friction: robots will move more slowly over bumpy surfaces than smooth.
2. Engineering: Gears and machinery can be explained alongside the completion of the modules.

TOUCH SENSORS (two modules and one tie-in project)
Description: The touch sensors are little buttons.
Warning: The sensors are a bit fragile. Keep the motor speeds low.

Modules:
1. Have the robot beep when the touch sensor is pressed.
2. A more advanced project: have the robot move around and when it hits an object, it turns around in a random direction and moves once more.

Tie-in Project:
1. Physics: How much force does it take to activate the touch sensors of the robot? Suppose that there is a robot sitting at the end of a ramp. If we put a foam block in front of the sensor, how high does the ramp need to be to activate the sensor?

LIGHT SENSORS (five modules and one tie-in project)
Description: The light sensor gives a reading based on the brightness of light hitting it. We’re pretty sure it can detect colors too.
Warnings: Keep the lights low in the classroom to avoid bad readings.

Modules:
1. The simplest project would involve shining a light on the robot and putting objects in front of the light to see how the readings change. An opaque object would block the light, some clear plastic would let the light through, and tracing paper (or something translucent) would give a reading in-between.
2. The robot traces a path (a thick line on a piece of paper), or a maze.
3. The robot “navigates” a piece of paper with multi-colored squares. For example, when the robot hits a red square, it turns left and moves again. If it detects a blue square, it beeps and moves right and goes onward, and so on.
4. The robot moves along and slows down when a light shines in front of it.
5. Skittles (or M&M’s) Sorter.

Tie-in Projects:
1. Ecology/Environmental Science: Evaluate the muddiness of water (turbin…?).

ROTATION SENSOR (two modules)
Description: The user sets up a conditional in ROBOLAB and the robot evaluates whether the condition has been satisfied, based on the sensor reading.

Modules:
1. Move the arm of the robot and see whether the conditional set up is satisfied.
2. Make a “steering wheel” out of the arms; the robot beeps depending on the direction of the movement.

VERNEIR PROBES (one+ tie-in projects)
Description: There are all different kinds. Mostly the robot acts as a carrier. We would want to devote a section to it separately, since there’s a lot that can be done with them. The robot may or may not be controllable in real-time; e.g. we may or may not be able to pilot the robot from the computer.
Warnings: Don’t track the robots through the mud. LEGOs are washable, but the motors may not be.

Tie-in project:
Physics: Temperature of liquids. Attach the Verneir probe to the robot and have it grip a mug containing a liquid and then take the temperature of the liquid using a robotic arm.

ROBOT-TO-ROBOT COMMUNICATION (one module)

Description: It’s probably a simple sychronization problem. Odds are the robots use message-passing.
Warnings: The robots have to be close to each other and in the line-of-sight in order to receive the messages.

Module:
1. Robot Relay. This module is open. We could have the robots complete a miniature obstacle course. Suppose the first robot follows a line along and when it hits the next robot, tells it to go on. The next robot follows a light moved around by a student until it gets near the near robot. The next robot bounces against the walls of a pathway and eventually gets to the end. At that point, the next robot in line sings. No cigar necessary.

TIMELINE:

Wednesday: Meet from 2 p.m. until . . .? Elliott is going to the Speaking Center at 3 p.m. and we will accompany him there. After that, we can go back to working on the spec.

Thursday: I will have Dr. Polack look over the spec.

Friday: If the spec is still not done, we will meet in the afternoon.

Fall Break: Hopefully by this point we can simply tweak the spec on Google Documents, which everyone should have access to.

Tuesday (Fall Break): Meet if necessary to fix things.

Wednesday (after Fall Break): Deliver the document.

If I missed anything, leave a comment on this post.

– Juliette Zerick

Juliette, Brent, and I met with Dr. Meadows this afternoon to iron out some items for the specification document. In short, we determined that several of the components in the LEGO Mindstorms kit should be given priority, because these are the components that every kit has. Other components are currently on our “wish list,” but because they won’t be used as often, they are not requirements for the project at the moment.

Required Modules
touch sensors
light sensors
motors

“Wish List” Modules
rotation sensors
Vernier probes

With this determined, we will probably do several modules per sensor, to really give a good introduction on the variety of things you can do with them. We’ll also be taking some time to introduce, within these modules, different code structures of which ROBOLAB is capable.

We’ll be meeting with Dr. Meadows again, this time with the whole team, after class on Monday. At that meeting, we will discuss in detail what the different modules will do so that we can move on to use-case models and the like. We’ll update again with the results of that meeting next week.

keep looking »