Module F
Module F
Story
Wednesday, 23rd March, 2005 – Tuesday, 29th March, 2005
On the Wednesday before their regular meeting, Bob sends:
Date: Wed, 23 Mar 2005 15:23:56 -0500
From: Bob
To: Crane Team <crane-cs-l@mtu.edu>
Can you guys please look at it and let me know if I need to add anything. We can touch it up tomorrow at our meeting if it's nothing too important.
-Bob
Attachment Converted: "Crane 2\Attach\mtucm.jpg"
Attachment Converted: "Crane 2\Attach\navy_logo.jpg"
Attachment Converted: "Crane 2\Attach\presentation.ppt"
Attachment Converted: "Crane 2\Attach\presentation.sxi"
This meeting was held in a computer lab in Rekhi Hall, and the recording quality was less than optimal. But you can listen in, and hear the team discuss their questions of what Hank wants:
[Client Wants 3-24.mp3, 2 min.]
There is some discussion within the team about why new code is needed and why the old code cannot be used more extensively.
And who on the team will be responsible for which tasks:
[Team Resp 3-24, 2 min.]
Denise suggests that they start making code, there is some discussion over the presence of static variables and their behavior within the existing code. The team decides when to meet next as suggested by Denise.
Then after the meeting Bob sends out the final draft of the presentation:
Date: Thu, 24 Mar 2005 12:43:34 -0500 (EST)
Subject: Presentation Final
From: Bob
To: crane-cs-l@mtu.edu, Hank
Here is the final presentation.
Attachment Converted: "Crane 2\Attach\presentation1.ppt"
Before their meeting with Hank, Justin explains his absence:
Date: Mon, 28 Mar 2005 19:39:39 -0500
From: Justin
To: crane-cs-l@mtu.edu
Subject: Meeting tomorrow
Hey guys,
I just found out I have an interview tomorrow at noon, so I won't be able to make the meeting. I'm still going through exactly what we can do with the .H files.
-Justin
During the meeting on the 29th, Hank again checks the teams progress on Matlab, as well as the difficulty in getting a response from the ME team:
[Checking Progress 3-29.mp3, 16 min.]
Hank: Is everyone here that is going to be here? What happened?
Bob: Well, I played with the globals a little bit. I can define them in the workspace, and then I tried to use them in a block and it says it cannot allow that. Then I played with the .hs a little bit, and created like an int, but it says upsert value 1. I dont know if it allows the .hs to do that. It is saying it couldn't run it in the loop. Something about configuration cranberes.
Hank: Are you saying you could run that or something? Or wouldnt let you do that or something.
Justin: It says something about ...(list of codes here).. and then an ss error.
Hank: You dont have like a continuous state.. or something like that. Well the last time we met, we divided up things to do, and I cant remember who was supposed to do what.
Denise: Well the last time we met, Justin was supposed to look at the .h files and
And me and him both wrote down stuff in the control functions and normal functions. We are going to move them all into input shaping, and then only pass the things that are needed into inverse kinematics.
Hank: Certainly some of those variables are not even ever used in input shaping.
Denise: yeah, we … some aren't used at all. But we thought we would have the values set and pass only the ones that are needed.
Hank: I see what you are trying to do but..I think... what about the notion of having another S function which initializes those things , sets them and distributes them
Denise: We are just trying to minimize s functions and passing.
Hank: Cause later if someone is looking at this stuff, they wouldn't know what those functions are really doing.
Denise: Right... Ok, cause that is how we had originally decided, Stuff to initialize input shaping and schematics. This is how we have it broken down now and we cannot basically change it.
Hank: Yeah, well I think you need to get more a description at least between the 2 of them. Your solution to it is fine, but … the data and signals have to flow. If times going this way, and under one move you want the flow to go like this, and another move the line would move this way.
Denise: We were thinking about dividing it up into 2 blocks and have a flag between the two.
Hank: Well, that could also be a problem, cause the output of damping needs to go into the damping. And the output of one needs to go into another, and how will you distinguish about which ones to use.
It just doesn't seem very clean.
Denise: So 1 would be damping and 2 would be inverse kinematics.
Hank: this way the lines are clean and when there is a delay, it knows what to do and take which data at one time step delay.
(more discussion on code)
The process is helped along by using a drawing Denise created:
[Crane 2\Crane 2 Drawings\Drawing3-29.pdf]
And you can hear Denise getting more assertive:
[Asserting 3-29.mp3, 13 min.]
Denise asserts her idea of what to move into input shaping and says that damping and input shaping should be done in a certain way, She suggests that they move damping schematics into 'input shaping'
Hank says that he can see what they are saying and s uggests having another S function which does that?
Denise says that they wanted to minimize S functions.
Hank suggests using a vector as a parameter in the S functions.
[this is an excerpt of another transcript]
Denise: Well the last time we met, Justin was supposed to look at the .h files and
And me and him both wrote down stuff in the control functions and normal functions. We are going to move them all into input shaping, and then only pass the things that are needed into inverse kinematics.
Hank: Certainly some of those variables are not even ever used in input shaping.
Denise: yeah, we … some aren't used at all. But we thought we would have the values set and pass only the ones that are needed.
Hank: I see what you are trying to do but..I think... what about the notion of having another S function which initializes those things , sets them and distributes them
Denise: We are just trying to minimize s functions and passing.
Hank: Cause later if someone is looking at this stuff, they wouldn't know what those functions are really doing.
Denise: Right... Ok, cause that is how we had originally decided, Stuff to initialize input shaping and schematics. This is how we have it broken down now and we cannot basically change it.
Hank: Yeah, well I think you need to get more a description at least between the 2 of them. Your solution to it is fine, but … the data and signals have to flow. If times going this way, and under one move you want the flow to go like this, and another move the line would move this way.
Denise: We were thinking about dividing it up into 2 blocks and have a flag between the two.
Hank: Well, that could also be a problem, cause the output of damping needs to go into the damping. And the output of one needs to go into another, and how will you distinguish about which ones to use.
It just doesn't seem very clean.
Denise: So 1 would be damping and 2 would be inverse kinematics.
Hank: this way the lines are clean and when there is a delay, it knows what to do and take which data at one time step delay.
Hank: How about using a vector as a parameter in the S functions.
Denise says that they dont want to compile anything in CFG
Denise talks about init section
they do not want to use the init part of the init function and move it into other places.
Hank says that is fine but to be careful of the flow, and also we need to be able to switch between modes.
Hank tries running input shape code of different types.
Questions:
- At the [Checking Progress 3-29.mp3, 16 min.] meeting, Bob starts off by asking Hank questions about the code.
- Compare the way Bob structures his questions with the way Denise normally does?
- How does Hank react to both?
- In technical communication, do you think it is important to ask well structured questions?
- Hank and Denise have a difference of opinion in what is the best way to deal with one of the code blocks.
- Do the other team members share their views on it, during the meeting?
- How does Hank respond to Denise's suggestions about the code?
- How does Denise respond to Hank's suggestions?
- What gets decided in the end?
- Would you consider this to be a healthy exchange of ideas, or an argument?
- How would you have dealt with the situation?
Wednesday, 23rd March, 2005 – Tuesday, 29th March, 2005
On the Wednesday before their regular meeting, Bob sends:
Date: Wed, 23 Mar 2005 15:23:56 -0500
From: Bob
To: Crane Team <crane-cs-l@mtu.edu>
Can you guys please look at it and let me know if I need to add anything. We can touch it up tomorrow at our meeting if it's nothing too important.
-Bob
Attachment Converted: "Crane 2\Attach\mtucm.jpg"
Attachment Converted: "Crane 2\Attach\navy_logo.jpg"
Attachment Converted: "Crane 2\Attach\presentation.ppt"
Attachment Converted: "Crane 2\Attach\presentation.sxi"
This meeting was held in a computer lab in Rekhi Hall, and the recording quality was less than optimal. But you can listen in, and hear the team discuss their questions of what Hank wants:
[Client Wants 3-24.mp3, 2 min.]
There is some discussion within the team about why new code is needed and why the old code cannot be used more extensively.
And who on the team will be responsible for which tasks:
[Team Resp 3-24, 2 min.]
Denise suggests Denise clearly in charge of what direction the team takes.
Then after the meeting Bob sends out the final draft of the presentation:
Date: Thu, 24 Mar 2005 12:43:34 -0500 (EST)
Subject: Presentation Final
From: Bob
To: crane-cs-l@mtu.edu, Hank
Here is the final presentation.
Attachment Converted: "Crane 2\Attach\presentation1.ppt"
Before their meeting with Hank, Justin explains his absence:
Date: Mon, 28 Mar 2005 19:39:39 -0500
From: Justin
To: crane-cs-l@mtu.edu
Subject: Meeting tomorrow
Hey guys,
I just found out I have an interview tomorrow at noon, so I won't be able to make the meeting. I'm still going through exactly what we can do with the .H files.
-Justin
During the meeting on the 29th, Hank again checks the teams progress on Matlab, as well as the difficulty in getting a response from the ME team:
[Checking Progress 3-29.mp3, 16 min.]
Hank: Is everyone here that is going to be here? What happened?
Bob: Well, I played with the globals a little bit. I can define them in the workspace, and then I tried to use them in a block and it says it cannot allow that. Then I played with the .hs a little bit, and created like an int, but it says upsert value 1. I dont know if it allows the .hs to do that. It is saying it couldn't run it in the loop. Something about configuration cranberes.
Hank: Are you saying you could run that or something? Or wouldnt let you do that or something.
Justin: It says something about ...(list of codes here).. and then an ss error.
Hank: You dont have like a continuous state.. or something like that. Well the last time we met, we divided up things to do, and I cant remember who was supposed to do what.
Denise: Well the last time we met, Justin was supposed to look at the .h files and
And me and him both wrote down stuff in the control functions and normal functions. We are going to move them all into input shaping, and then only pass the things that are needed into inverse kinematics.
Hank: Certainly some of those variables are not even ever used in input shaping.
Denise: yeah, we … some aren't used at all. But we thought we would have the values set and pass only the ones that are needed.
Hank: I see what you are trying to do but..I think... what about the notion of having another S function which initializes those things , sets them and distributes them
Denise: We are just trying to minimize s functions and passing.
Hank: Cause later if someone is looking at this stuff, they wouldn't know what those functions are really doing.
Denise: Right... Ok, cause that is how we had originally decided, Stuff to initialize input shaping and schematics. This is how we have it broken down now and we cannot basically change it.
Hank: Yeah, well I think you need to get more a description at least between the 2 of them. Your solution to it is fine, but … the data and signals have to flow. If times going this way, and under one move you want the flow to go like this, and another move the line would move this way.
Denise: We were thinking about dividing it up into 2 blocks and have a flag between the two.
Hank: Well, that could also be a problem, cause the output of damping needs to go into the damping. And the output of one needs to go into another, and how will you distinguish about which ones to use.
It just doesn't seem very clean.
Denise: So 1 would be damping and 2 would be inverse kinematics.
Hank: this way the lines are clean and when there is a delay, it knows what to do and take which data at one time step delay.
(more discussion on code)
The process is helped along by using a drawing Denise created:
[Crane 2\Crane 2 Drawings\Drawing3-29.pdf]
And you can hear Denise getting more assertive:
[Asserting 3-29.mp3, 13 min.]
Denise asserts her idea of what to move into input shaping and says that damping and input shaping should be done in a certain way, She suggests that they move damping schematics into 'input shaping'
Hank says that he can see what they are saying and s uggests having another S function which does that?
Denise says that they wanted to minimize S functions.
Hank suggests using a vector as a parameter in the S functions.
[this is an excerpt of another transcript]
Denise: Well the last time we met, Justin was supposed to look at the .h files and
And me and him both wrote down stuff in the control functions and normal functions. We are going to move them all into input shaping, and then only pass the things that are needed into inverse kinematics.
Hank: Certainly some of those variables are not even ever used in input shaping.
Denise: yeah, we … some aren't used at all. But we thought we would have the values set and pass only the ones that are needed.
Hank: I see what you are trying to do but..I think... what about the notion of having another S function which initializes those things , sets them and distributes them
Denise: We are just trying to minimize s functions and passing.
Hank: Cause later if someone is looking at this stuff, they wouldn't know what those functions are really doing.
Denise: Right... Ok, cause that is how we had originally decided, Stuff to initialize input shaping and schematics. This is how we have it broken down now and we cannot basically change it.
Hank: Yeah, well I think you need to get more a description at least between the 2 of them. Your solution to it is fine, but … the data and signals have to flow. If times going this way, and under one move you want the flow to go like this, and another move the line would move this way.
Denise: We were thinking about dividing it up into 2 blocks and have a flag between the two.
Hank: Well, that could also be a problem, cause the output of damping needs to go into the damping. And the output of one needs to go into another, and how will you distinguish about which ones to use.
It just doesn't seem very clean.
Denise: So 1 would be damping and 2 would be inverse kinematics.
Hank: this way the lines are clean and when there is a delay, it knows what to do and take which data at one time step delay.
Hank: How about using a vector as a parameter in the S functions.
Denise says that they dont want to compile anything in CFG
Denise talks about init section
they do not want to use the init part of the init function and move it into other places.
Hank says that is fine but to be careful of the flow, and also we need to be able to switch between modes.
Hank tries running input shape code of different types.