What is due next week?

Looking at the assignment we need to come up with the following.

System specifications document- (due 1/14/09)

• Higher level functionality expected by the system.
  
• Document needs to be officially accepted by Dr. Brooks.

System architecture document- (due 1/14/09)

• all system components
  
• class members responsible for implementing each component
  
• deliverables for each group
  
• semantics of each component
  
• Gant chart for each component (shows the implementation time line for that component)

We should also try and make it so one group doesn't interface to all the others. (like described in class)
I was also having trouble thinking of how to come up with the proximity sensing, so maybe we should include that in our plans.
Also maybe a general idea of how the game would be played.

We could have one group for the wi-fi and webpage interfaces, one group for the camera interfacing, one for the nerf dart acuator and sensors. So maybe 3 to 4 groups of 5 or so people each.

Each group could talk to the other 2 groups, creating a circular hierarchy. That may be too much trouble though, but that's the best I can think of.

As for each group's responsibilities:

Webpage group: Come up with an easy to use webpage interface with the two laptops that will allow the user to easily steer the robots, camera and nerf dart acuators.

Camera group: Come up with the best way to use the available cameras and other sensor feeds in Riggs 15. Interface the cameras with the webpage system and communicate with the nerf dart team to come up with a way to synchronize the two systems.

Nerf Dart group: Interface nerf dart acuators with camera and webpage. Come up with a viable sensor solution for the hit detection. Preferably small and not too expensive.

I don't know, but there is probably a much better solution that this for grouping or whatever. Each of the 3 or 4 groups could obviously split themselves up as appropriate.

We are also going to need a group to interface to the rover, tell it go forward, back, etc. But other than that, I can't think of any more obvious divisions for groups.

-Brian Peasley

So how many people are in the class now? Is it like 25 or so?

so you guys were thinking (from what I read)

Webpage group:

Camera group:

Nerf Dart group:

Robot Group:

now where should the sensor people be placed? In another group? I think that might be the hardest part is actually having the dart register as a hit... ideas / suggestions?

We came up with alot of ideas last night about how to register a hit.

RFIDs on the missiles with sensors on the tanks.
Magnets.
Glue.
Paint.
Impact Sensors.
Double sided tape.

just to name a few

I assume the webpage group would also be the server group who sets up the Apache server? We might want to try to make it as easy on the webpage group as possible since they sound like the "hub" group...the webpage controls the robots, controls the nerf guns, displays the sensor feeds, etc. They will be pretty dependent on every other group unless we can think of something really clever.

rbrenan wrote:I assume the webpage group would also be the server group who sets up the Apache server? We might want to try to make it as easy on the webpage group as possible since they sound like the "hub" group...the webpage controls the robots, controls the nerf guns, displays the sensor feeds, etc. They will be pretty dependent on every other group unless we can think of something really clever.

I think the interface for this wouldn't be too bad. All it has to do is talk to the laptop on the rover. So the web group would send a signal via TCP probably over to the laptop saying either up, down, left, right, fire, etc. and the laptop would then send those respective commands to the wheels, nerf gun, camera, etc. And all the web group would need to receive would be a jpg img. The receiving the jpg would be easy enough to do in flash or javascript. As far as sending the command, not quite sure how you would want to do that. Probably a java servlet/applet setup.

-Brian Peasley

How does the laptop know where to send the stuff though? Your solution seems like an app that is running on the laptop and interfaces with everything else. That still poses the same problem of working with every group.

There web controller needs to be able to send the commands to do anything (move left, fire, stop, ...), its just how do we want to send these commands. The exact commands the laptop needs to execute, a simple code that the laptop interprets, or something else entirely?

So adding everything thus far,

Webpage group:

• send a signal via TCP probably over to the laptop saying either up, down, left, right, fire, etc. and the laptop
  receive would be a jpg img

Laptop group:

• laptop would then send those respective commands to the wheels, nerf gun, camera, etc.

Camera group:

• maybe this group could have the image show a drawing on the jpg that shows an area where the bullet would land if it was shot right then

Nerf Dart group:

• driver for the nerf dart machine
  
• some commands that the laptop group can use

Robot Group:

• wheels, and movement
  
• this could be either click then move a certain amount(digital) or click and it moves till you stop clicking (analog)

Sensor Group:

• self explanatory

we will also need a flow chart of some kind that shows who works with each group and get group names and people in each group in order

ALSO i can keep updating this first post with what we have so far.
That will make it easier to know what has happened without rereading everything

cdabbott316 wrote:How does the laptop know where to send the stuff though? Your solution seems like an app that is running on the laptop and interfaces with everything else. That still poses the same problem of working with every group.

There web controller needs to be able to send the commands to do anything (move left, fire, stop, ...), its just how do we want to send these commands. The exact commands the laptop needs to execute, a simple code that the laptop interprets, or something else entirely?

I'm not sure what you mean by, "How does the laptop know where to send the stuff though?". Those laptops have code that can interface with everything on that robot, except for the nerf gun of course. And somewhere along the road your going to need one group talking to everyone else, the laptop should act as an arbiter between the hardware and the web page.

And the type of command to send, that could be any number of things, what I was thinking would be the best way to do would be something along these lines:
(Say we only have forward, back, left, right for now)
Send one byte: 0xPR
P:(Prismatic Motion) 1000 where the 1 would mean enable and the next 3 bits would tell it forward or back (4 would mean stop, 0 would mean full back, and 7 would mean full forward)
R:(Rotational Motion) 1000 where the 1 would mean enalbe and the next bit would be left or right (1 = left, 0 = right) and the 2 LSB would denote speed of rotation

-Brian Peasley

I think these things are not things that are pertinent right now. :-) (saying this in the nicest way possible)
Right now we just need to come up with groups and a structure for the groups. (as in who interfaces with who)
So I think we would be better off sticking to that and not worry about specifics at the moment.
If you would like to talk about that stuff move it to a different topic and discuss there.

-David

Missile team (4-5 people)
Responsibilities:
Backwards engineers the dart aiming and shooting mechanism.
Create a coder friendly interface to the missile launcher, remembering there are two robots.

Interfaces with:
Web team, Sensor team


Web team (4-5 people)
Responsibilities:
Sets up server to retrieve/send data from the robot and webcam.
Sets up website to display and interface the robot controls.

Interfaces with:
Missile Team, Robot team, Sensor team



Robot team (4-5 people)
Responsibilities:
Create a coder friendly interface to the robots, remembering there are two robots.
Auto play team from other thread.

Interfaces with:
Web team, Dart team


Sensor team (4-5 people)
Responsibilities:
Researches and buys and implements sensor for hit detecting.
Create a coder friendly interface to the webcams on the robots, remembering there are two robots.
(Optional) Enemy detection.

Interfaces with:
Web team, Dart team

Honestly these are the only four teams with enough responsibility for the whole semester. 20-16 people total

Ok, here is my thoughts on how the architecture should be set up, very simliar to making's but with a slight differences:
1.) Added camera group
2.) Sensor team does not interface to web team
3.) Robot team does not interface with dart team and interfaces with sensor team
(I meant to draw the laptop inside the web team box)


text on btm right that is cut off is "on hit detection"

First off, I just checked the class roll. There are currently 19 people enrolled in the class.

Secondly, I could see either Peasley's or making's setup working. We may need to worry about splitting the groups up too much. It would probably be best not to have more than 5 groups, which is what we have right now.

Lastly, when you guy's refer to the laptop as an 'arbiter,' do you mean a central piece of software that interprets commands and resends them to the other hardware? If so, and it's possible to have a generic wi-fi read type function, we may not actually need the 'arbiter' as a separate group. As in the web interface group sends out a signal, and all the other groups read that signal separately and decide if it's meant for them, and then do it.

I didn't intend to have the laptop as a different group, but should be included with the web interface group. And yes I meant to use the laptop as a interpreter of commands received from the web team, determine which group the command is meant for, and send that command off to the group for it is intended.

-Brian Peasley

One thing to keep in mind is that it will be necessary to have the camera and the nerf gun aiming to work in tandem (unless we plan on using something else to determine the location of the enemy robot). Whether they should be moved at the same time or controlled separately is something that will influence whether there should be one or two groups for these parts.

Sorry but I have little else to contribute at this time.
- Joshua Hilley

yea this is true, what we could do is have a button in the interface that locks/unlocks the camera to the rotation of the nerf gun. But I could see combining the camera and nerf gun group.

-Brian Peasley

So I think we need to start making some decisions on the groups we are going to be using. 4 of them are definite it seems: web, gun, rover, sensor. The only one that seems to be in the air is the camera group. So do u guys want to have the camera group or do u want to put it in with the nerf gun? It would be nice if we could get everybody into groups during this weekend so that we can have some time to work through how our individual groups are going to do there thing.

I think we should keep camera and nerf gun seperate.

-Brian Peasley

I think a camera group should be absorbed into another group definatly, simply because the only thing that group would be doing is interfacing a web cam with well documented drivers to which ever other team needs it. Thats not much work for one entire semester, and why in my group specification i merged them with the sensor group. The sensor group only has the responsibility to purchasing a sensor and backwards engineering it. There is no interfacing they would need to do at all as their product will work off the shelf if they can reverse the commands to get it to work.

19 people / 5 teams = 4 people/group
Webpage group: 4 people
interfaces with laptop and sensor and camera
making this look and feel well designed would be great because this is what the user sees

Laptop group: 5-7 people (including the robot group since the robot is already controlled by the laptop by classes in the past)
interfaces with everyone besides sensor (that's why i added more people)

Camera group:4 people
interfaces with laptop and webpage.

Nerf Dart group:3-4 people
interfaces with sersor and laptop
reverse engineering this might take a while

Sensor Group:3-4 people
interfaces with camera and nerf
I think this group would have plenty to do if we had this group interface with the camera group and figure out a way to draw on the images and show where the dart will land if the user were to shoot right at that moment.


this sounds like a cool medium between groups
I also believe that if we were to have nothing to do in a group come mid semester then we could have groups help each other out.

Also anyone that hasn't added their input I am guessing does not have one and/or dos not care.

making wrote:I think a camera group should be absorbed into another group definatly, simply because the only thing that group would be doing is interfacing a web cam with well documented drivers to which ever other team needs it. Thats not much work for one entire semester, and why in my group specification i merged them with the sensor group. The sensor group only has the responsibility to purchasing a sensor and backwards engineering it. There is no interfacing they would need to do at all as their product will work off the shelf if they can reverse the commands to get it to work.

Ummm there is going to be more to it than that. They will have to paint stuff on the screen such as where the area in which the nerf dart will land and will also have to get it to pan/tilt/zoom. And there is nothing saying that once a group is done with there stuff there members can't be redistirbuted to other teams.

I think we need to go ahead and start signing up for groups since it seems that we have a pretty good idea of what is going to be interfacing to what. Though I still think it makes more sense to have the web team only interface to the laptop, and the laptop/rover team interfaces with camera, nerf gun. And the sensor team will interface to camera and laptop.

I personally would like to be on the camera group, and if it gets absorbed into another group then I'll be on that group instead.

-Brian Peasley

Peasley wrote:

making wrote:I think a camera group should be absorbed into another group definatly, simply because the only thing that group would be doing is interfacing a web cam with well documented drivers to which ever other team needs it. Thats not much work for one entire semester, and why in my group specification i merged them with the sensor group. The sensor group only has the responsibility to purchasing a sensor and backwards engineering it. There is no interfacing they would need to do at all as their product will work off the shelf if they can reverse the commands to get it to work.

Ummm there is going to be more to it than that. They will have to paint stuff on the screen such as where the area in which the nerf dart will land and will also have to get it to pan/tilt/zoom. And there is nothing saying that once a group is done with there stuff there members can't be redistirbuted to other teams.

I think we need to go ahead and start signing up for groups since it seems that we have a pretty good idea of what is going to be interfacing to what. Though I still think it makes more sense to have the web team only interface to the laptop, and the laptop/rover team interfaces with camera, nerf gun. And the sensor team will interface to camera and laptop.

I personally would like to be on the camera group, and if it gets absorbed into another group then I'll be on that group instead.

-Brian Peasley

The pan-tilt-zoom feature would be as simple as interfacing to a driver included with the camera software, and painting the hit area and all that is entirely optional on this project, much like auto play.