Module D
Module D
Sunday, 27th February, 2005 – Saturday, 5th March, 2005
Date: Mon, 28 Feb 2005 15:24:33 -0500 (EST)
Subject: No meeting this week
From: Hank
To: crane-cs-l@mtu.edu
Denise,
I'm out of town this week, but, I can check my email.
I can't meet instead please send me a short update, and any questions you folks have. Also, please let the other people know (including the monitor) that we won't be meeting.
Thanks,
-- Hank
So Denise replies:
Date: Tue, 1 Mar 2005 17:24:33 -0500 (EST)
Subject: Re: No meeting this week
From: Denise
To: Hank
Cc: crane-cs-l@mtu.edu
Hank,
We are continuing code decomposition and design of the MatLab model this week. We met Sunday evening to discuss how to implement the new PCS code, including deciding which functions we felt were no longer necessary. We also cleared up some design ideas about MatLab and Bob gave us his report from the meeting he had with the platform team on Thursday. Sounds like the platform team is going to be behind schedule, which may impact our real-world testing, and they also do not have any better idea of the ranges of inputs that we will be taking in in our program.
This leads to some questions about the code in the main function, since
that code not only takes in the serial data about the current movement and crane state, it also does some calculations on it in functions like
EstimateShipMotion, Estimate_Slope, and FilterShipMotion. Will the data we are taking in going to be the same values that this old program took in, so we will need to do the same calculations? Or will we be getting data that is already estimated, filtered, etc?
At the end of the while loop in the main function there is a call to
data_log, which writes the current state and operations to a log on
separate machine. Are we keeping that in?
We have also generated some questions about implementation in MatLab, such as in all of the simulations we have looked at so far we give a specified run time length, how will the new program continue executing as long as the user's wish it to?
The team is meeting on Thursday to do a similar re-design of CONTROL1, so I am sure we will have many more questions for you after that.
We will see you for the next meeting on March 15,
--Denise
Prior to their regular meeting on Thursday, Denise sends out a reminder:
Date: Wed, 2 Mar 2005 20:16:31 -0500 (EST)
Subject: Crane Meeting Reminder
From: Denise
To: "Crane Team" <crane-cs-l@mtu.edu>
Just a reminder to crane team members we are meeting Thursday, 11 am, in Rehki 114 to do some more code decomposition. And make the powerpoint if I dont get around to it tonight :)
--Denise
During the meeting, they wrestle with the existing code, including trying to determine what “deadman” does and what initial values they will have as input:
[Code Decomp 3-3.mp3, 11min.]
[Denise explains how she went about trying to make sense of the code, by categorizing ways in which parameters were used and passed. Also that she discovered that some parameters are not used at all. The biggest problem is the switch statement and the team discuss what options they have. Bob and Justin make suggestions about how the switch case statements can be implemented and how parameters can be used within the inverse kinematics block. They then discuss “deadman” and hypothesize what its physical relevance could be based on where it is declared, defined an d used. They then discuss some of the .h functions and try to determine the significance of some of them.]
and how that raises more Matlab issues[Matlab Issues 3-3.mp3, 6min.]
They also try to resolve some design issues, again discussing the input values and trying to define some terms
[Design Issues 3-3.mp3, 13min.]
[We can see that the discussion is mainly led by Denise based on her understanding of the code. She also informally takes updates from the rest of the team.]
Denise: If we took out the rider block stuff and the input shape block, that should be the place to start. Have you done any work on that thing this week Bob?
Bob: Not really.
Denise: I was …..
[Denise checking the list of S functions to see whether they have been dealt with in the team]
Bob: Why are there so many? Before, we had like 11 and now there are 25. Why do we need a crane sensor? Wont that be determined by the ship motion.
Denise: A lot of these functions seem the same.
Bob: The crane team never sends anything out, I am on their mailing list and they never send anything out. The six degrees guys send out emails like 4 times a day.
Denise: The six degrees are the platform guys?
Bob: yeah, but nothing from the crane guys. Something like, I have no idea how the crane is built. I dont know whether the crane will have a platform underneath it like hydraulics which keep it balanced, or whether the crane moves with the ship and the arm controls the motion
Denise: Yeah, yeah, yeah, I want to know if we are supposed to mimic the platform or the ship motion. I don't know if we control the platform or we control the frame. That is a pretty big question. Do you know the answer to that?
Bob: No.
Denise: But you know what I am asking, right?
Bob: Yeah I know what you mean.
Denise: I kind of wish I had been here last semester.
Bob: We did well, but I was surprised, because we did not accomplish anything.
Justin: Like a lot of values will change.
Denise: Yes, a lot of the values are things like distance of arm between crane and platform. If they are designing a new crane, we need the new values. We cannot test the design against the wrong crane or just any crane.
Justin: {mumbles}
Denise: What do all the static input variables
Justin: We are supposed to be regularly updating our risk document right?
Denise(smiling): A good risk would be crane team does not finish crane, platform team does not finish platform. We also need to create a timeline document. Bob, if you want to look at that.
Bob: how are there six coordinates on this? The operator has... oh wait, there are two joysticks, but what do those terms mean.
Denise: the operator manages the ships and the crane is supposed to … well then operator... the current state and the desired state.
Bob: Crane config is what is going on. We fix the crane thing, the operator moves the crane, and we try to balance the motion He is moving at this speed, or swinging as much due to the motion, so we have to balance the motion.
Justin: But I don’t understand why there are 6 still.
Bob: Well there is that material but it does not give me all these answers.
Denise: Lets hope our crane looks like that one. But he hands it to you and you do not check whether it has what you need.
Bob: Where do the 6 values come from.
Denise: Well there is up and down on the pulley
Justin: But that should be like one.
Denise: well pulley up pulley down, right and left...
Bob: Well there is also roll pitch and motion
Denise: What is roll and pitch.. And are they gps coordinates? It seems lieke there are too many coordinates going. There is the calculation on the global, and then the local and then the globals and then local again.
Bob: I think it means initially, there is dh and dl, hoist and lower it says initially, and then the ones without the i's are the current.
Justin: Maybe it uses the initial to find out the current.
Denise: But the i-variables are not used again in the control function. Why not just have one variable though, it seems like one variable. Maybe it is used in some sort of loop, but I don’t think there is any loop in he control function. Oh wait there it is, it IS used again.
Bob: But those are ds not ls
Denise: Oh yeah, I forgot there are two sets.
(more discussion on variables and their potential uses)
Bob: Didn’t he mention something about a tagline for moving that line.
Denise: But I thought hoist was up and down.
Bob: Look(gesticulates) here, this is the pulley, hoist is for the pulley motion, and the tagline is this other motion.
Denise: ohh... small victory. Write this stuff down so you dont forget it.
and realize that they are not communicating well with Hank, and have to “go back” to him for answers
[Communication 3-3.mp3, 9min.]
This is an excerpt from the Design issues transcript, present before, where they are discussing where the 20 plus values are coming from and again hypothesizing what the different values signify. This is a discussion where all three team members actively contribute and try to brainstorm so that their understanding of the code is clear.
You can also hear them discuss how to update their risk document,
[Risk Doc 3-3.mp3, 9min.]
[This is also an excerpt which is present before as part of the transcript for the Design issues, where the team remembers that they have to update their risk document and they realize that their results are significantly dependent on the other ME teams, as they will not be able to test any of their software's functionality if the simulators are not working]
which Bob posts after the meeting:
Date: Thu, 3 Mar 2005 12:29:17 -0500 (EST)
Subject: Week 8 version of Risk Document.
From: Bob
To: crane-cs-l@mtu.edu
Cool beans
Attachment Converted: "Crane 2\Attach\Risk Analysis1.doc"
And Justin offers a revised existing code flowchart:
Date: Thu, 03 Mar 2005 12:50:44 -0500
From: Justin
To: crane-cs-l@mtu.edu
Subject: Revised Existing Code Flowchart
Attachment Converted: "Crane 2\Attach\software control flowchart.jpg"
Questions:
- Denise sends an email meeting reminder to the team about the next meeting, and an update to Hank on the team's progress. She later takes verbal updates from the team during their internal meeting.
- Why do you suppose Hank asked Denise directly for a team progress update and not any other member of the team?
- Should Denise have had to send out a meeting reminder to the rest of the team members? Do you suppose it had something to do with attendance issues in the past or was it just good practice?
- Are these duties appointed to Denise, or are they things that Denise had taken on, on her own?
- At Week 5, the Seabase II team is holding internal meetings and working on understanding the intricacies of the code. Compare with Seabase I and see where the team was at this point, chronologically. What do you think is the primary difference in approach?
- What type of work do you think internal team meetings are good for?Do you think brainstorming is a common and useful approach in design projects
- Do all members appear equally involved? Are all members just as equally active in front of Hank as they are in the internal meetings? What do you suppose is the reason for that?
Sunday, 27th February, 2005 – Saturday, 5th March, 2005
Date: Mon, 28 Feb 2005 15:24:33 -0500 (EST)
Subject: No meeting this week
From: Hank
To: crane-cs-l@mtu.edu
Denise,
I'm out of town this week, but, I can check my email.
I can't meet instead please send me a short update, and any questions you folks have. Also, please let the other people know (including the monitor) that we won't be meeting.
Thanks,
-- Hank
So Denise replies:
Date: Tue, 1 Mar 2005 17:24:33 -0500 (EST)
Subject: Re: No meeting this week
From: Denise
To: Hank
Cc: crane-cs-l@mtu.edu
Hank,
We are continuing code decomposition and design of the MatLab model this week. We met Sunday evening to discuss how to implement the new PCS code, including deciding which functions we felt were no longer necessary. We also cleared up some design ideas about MatLab and Bob gave us his report from the meeting he had with the platform team on Thursday. Sounds like the platform team is going to be behind schedule, which may impact our real-world testing, and they also do not have any better idea of the ranges of inputs that we will be taking in in our program.
This
leads Another instance where Denise demonstrates how well structured and specific questions should be asked.
that code not only takes in the serial data about the current movement and crane state, it also does some calculations on it in functions like
EstimateShipMotion, Estimate_Slope, and FilterShipMotion. Will the data we are taking in going to be the same values that this old program took in, so we will need to do the same calculations? Or will we be getting data that is already estimated, filtered, etc?
At the end of the while loop in the main function there is a call to
data_log, which writes the current state and operations to a log on
separate machine. Are we keeping that in?
We have also generated some questions about implementation in MatLab, such as in all of the simulations we have looked at so far we give a specified run time length, how will the new program continue executing as long as the user's wish it to?
The team is meeting on Thursday to do a similar re-design of CONTROL1, so I am sure we will have many more questions for you after that.
We will see you for the next meeting on March 15,
--Denise
Prior to their regular meeting on Thursday, Denise sends out a reminder:
Date: Wed, 2 Mar 2005 20:16:31 -0500 (EST)
Subject: Crane Meeting Reminder
From: Denise
To: "Crane Team" <crane-cs-l@mtu.edu>
Just a reminder to crane team members we are meeting Thursday, 11 am, in Rehki 114 to do some more code decomposition. And make the powerpoint if I dont get around to it tonight :)
--Denise
During the meeting, they wrestle with the existing code, including trying to determine what “deadman” does and what initial values they will have as input:
[Code Decomp 3-3.mp3, 11min.]
[Denise explains how she went about trying to make sense of the code, by categorizing ways in which parameters were used and passed. Also that she discovered that some parameters are not used at all. The biggest problem is the switch statement and the team discuss what options they have. Bob and Justin make suggestions about how the switch case statements can be implemented and how parameters can be used within the inverse kinematics block. They then discuss “deadman” and hypothesize what its physical relevance could be based on where it is declared, defined an d used.
They then discuss This is clearly a team meeting where Denise is established as the strongest technical member of team.
and how that raises more Matlab issues[Matlab Issues 3-3.mp3, 6min.]
They also try to resolve some design issues, again discussing the input values and trying to define some terms
[Design Issues 3-3.mp3, 13min.]
[We can see that the discussion is mainly led by Denise based on her understanding of the code. She also informally takes updates from the rest of the team.]
Denise: If we took out the rider block stuff and the input shape block, that should be the place to start.
Have you done Denise is clearly in charge of the team now, and one can see her taking updates, although with a friendly tone of voice, but she is making sure that they live up to Hank's expectations as a team, specially considering the fact that she has had to answer to Hank for the team's shortcomings on occasions before.
Bob: Not really.
Denise: I was …..
[Denise checking the list of S functions to see whether they have been dealt with in the team]
Bob: Why are there so many? Before, we had like 11 and now there are 25. Why do we need a crane sensor? Wont that be determined by the ship motion.
Denise: A lot of these functions seem the same.
Bob:
The crane team Bob highlights problems with being able to coordinate with the other ME teams, due to their lack of response. This turns out to be a significant issue later.
Denise: The six degrees are the platform guys?
Bob: yeah, but nothing from the crane guys. Something like, I have no idea how the crane is built. I dont know whether the crane will have a platform underneath it like hydraulics which keep it balanced, or whether the crane moves with the ship and the arm controls the motion
Denise: Yeah, yeah, yeah, I want to know if we are supposed to mimic the platform or the ship motion. I don't know if we control the platform or we control the frame. That is a pretty big question. Do you know the answer to that?
Bob: No.
Denise: But you know what I am asking, right?
Bob: Yeah I know what you mean.
Denise:
I kind of wish I had been here Denise demonstrates her confidence her abilities to have done a better job in the previous semester. This is a far more confident stance than the first meeting with Hank, where the team and specially Denise did not seem too sure.
Bob:
We did well, but I was surprised, Bob attempts to defend their efforts in the previous semester in the face of Denise's remark.
Justin: Like a lot of values will change.
Denise: Yes, a lot of the values are things like distance of arm between crane and platform. If they are designing a new crane, we need the new values. We cannot test the design against the wrong crane or just any crane.
Justin: {mumbles}
Denise: What do all the static input variables
Justin: We are supposed to be regularly updating our risk document right?
Denise(smiling):
A good risk Denise expresses her doubts about the other teams keeping up with the schedule. Denise feels comfortable assigning tasks and responsibilities within the team, as she has assumed the implicit role of leader.
Bob: how are there six coordinates on this? The operator has... oh wait, there are two joysticks, but what do those terms mean.
Denise: the operator manages the ships and the crane is supposed to … well then operator... the current state and the desired state.
Bob: Crane config is what is going on. We fix the crane thing, the operator moves the crane, and we try to balance the motion He is moving at this speed, or swinging as much due to the motion, so we have to balance the motion.
Justin: But I don’t understand why there are 6 still.
Bob: Well there is that material but it does not give me all these answers.
Denise: Lets hope our crane looks like that one. But he hands it to you and you do not check whether it has what you need.
Bob: Where do the 6 values come from.
Denise: Well there is up and down on the pulley
Justin: But that should be like one.
Denise: well pulley up pulley down, right and left...
Bob: Well there is also roll pitch and motion
Denise: What is roll and pitch.. And are they gps coordinates? It seems lieke there are too many coordinates going. There is the calculation on the global, and then the local and then the globals and then local again.
Bob: I think it means initially, there is dh and dl, hoist and lower it says initially, and then the ones without the i's are the current.
Justin: Maybe it uses the initial to find out the current.
Denise: But the i-variables are not used again in the control function. Why not just have one variable though, it seems like one variable. Maybe it is used in some sort of loop, but I don’t think there is any loop in he control function. Oh wait there it is, it IS used again.
Bob: But those are ds not ls
Denise: Oh yeah, I forgot there are two sets.
(more discussion on variables and their potential uses)
Bob: Didn’t he mention something about a tagline for moving that line.
Denise: But I thought hoist was up and down.
Bob: Look(gesticulates) here, this is the pulley, hoist is for the pulley motion, and the tagline is this other motion.
Denise: ohh... small victory.
Write this stuff down Even though it is said with a jovial tone, Denise is now giving direct instructions to her teammates, again asserting her place as leader, but very subtly.
and realize that they are not communicating well with Hank, and have to “go back” to him for answers
[Communication 3-3.mp3, 9min.]
This is an excerpt from the Design issues transcript, present before, where they are discussing where the 20 plus values are coming from and again hypothesizing what the different values signify. This is a discussion where all three team members actively contribute and try to brainstorm so that their understanding of the code is clear.
You can also hear them discuss how to update their risk document,
[Risk Doc 3-3.mp3, 9min.]
[This is also an excerpt which is present before as part of the transcript for the Design issues, where the team remembers that they have to update their risk document and they realize that their results are significantly dependent on the other ME teams, as they will not be able to test any of their software's functionality if the simulators are not working]
which Bob posts after the meeting:
Date: Thu, 3 Mar 2005 12:29:17 -0500 (EST)
Subject: Week 8 version of Risk Document.
From: Bob
To: crane-cs-l@mtu.edu
Cool beans
Attachment Converted: "Crane 2\Attach\Risk Analysis1.doc"
And Justin offers a revised existing code flowchart:
Date: Thu, 03 Mar 2005 12:50:44 -0500
From: Justin
To: crane-cs-l@mtu.edu
Subject: Revised Existing Code Flowchart
Attachment Converted: "Crane 2\Attach\software control flowchart.jpg"