Seabase II Case Study

Module G

Module G

Wednesday, 30th March, 2005 – Tuesday, 5th April, 2005

Denise sends out a reminder:

The team spends some time trying to “figure things out” about the code, Matlab and the project in general:

[Matlab-Code-Project 3-31.mp.3, 14 min.]

There is discussion on points of contention from their previous discussion with Hank. The team asks themselves the following questions:

Should we be using structs or pass things in vectors as Hank had suggested before?

How does input from the joystick come in? Input values, or vectors or sine wave?

What are multiplexers and how is the code using them?



They also revisit what Hank wants:

[Client Wants.mp3, 2 min.]

The team recaps part of the discussion with Hank about Inverse kinematics

They discuss that they just want command motor. And some discussion is there towards the end about the fact that the sponsors are coming sometime during exam week.

Justin: How come Hank wants us to do those work vectors or whatever, in case we want to recompile it back into C, what is the purpose?

Denise: it took so much work to convert it from C to matlab just to convert it back.

Bob: Maybe that is what the summer job was. That is why he wants us back next summer.

Denise: It better pay very well if we are doing this

(more discussion on code variables)

And revise their responsibilities:

[Team Resp 3-31.mp3, 8 min.]

The team discusses what init does and what solution does. These are different blocks of code.

Solution calculates the input swing, like the pre-init.


Denise: I am not leaving this building for at least 5 hours.

Justin: So we should be passing the structs as vectors? Why cant be pass the structs?

Bob: We cant.

Denise: We cant pass them because S function does not know what a struct is.

Bob: We are putting this code to this block and then that code to that block,how do we know whether it will execute at the right time.

Denise: we are just putting it together and see if it will work.

(more code discussion)

Justin: What is the point of initializing this function?

Denise: It is not initializing them, it is just calling them, and it has a point array which it takes by reference and changes that.

(more code discussion)

Justin: Is solution calling this? Or is solution the last thing on the list that spits it out.

Denise: Yes solution calls it. Solution we are going to try and preserve.

Justin: So what is init doing.

Denise: init is just initializing value.

Justin: So how does solution affect swing angle.

Denise: Solution calls the value and updates the swing angle. Solution is the function in CS which calls everything else.

Justin: So solution is what starts everything off.

Denise: it initializes the control stuff and the analog input

Justin: so, It is kind of like a pre-init. Before the init.

Bob: when time are we meeting next week?

Denise: Do you guys want to meet before meeting with Hank or after meeting with Hank.

(regular banter)

Denise: Alright does everyone have enough stuff to do this weekend?

You can listen in as Denise “takes charge” of the team:

[Taking Charge 3-31.mp3, 7 min.]

What init does, what solution does.

Solution calculates the input swing, like the pre-init

[This is also an excerpt from a previously transcribed conversation]


Denise: I am not leaving this building for at least 5 hours

Justin: So we should be passing the structs as vectors? Why cant be pass the structs?

Bob: We cant.

Denise: We cant pass them because S function does not know what a struct is.

Bob: We are putting this code to this block and then that code to that block,how do we know whether it will execute at the right time.

Denise: we are just putting it together and see if it will work.

(more code discussion)

Justin: What is the point of initializing this function?

Denise: It is not initializing them, it is just calling them, and it has a point array which it takes by reference and changes that.

(more code discussion)

Justin: Is solution calling this? Or is solution the last thing on the list that spits it out.

Denise: Yes solution calls it. Solution we are going to try and preserve.

Justin: So what is init doing.

Denise: init is just initializing value.

Justin: So how does solution affect swing angle.

Denise: Solution calls the value and updates the swing angle. Soltion is the function in CS which calls everything else.

Justin: So solution is what starts everything off.

Denise: it initializes the control stuff and the analog input

Justin: so, It is kind of like a pre-init. Before the init.

Bob: when time are we meeting next week?

Denise: Do you guys want to meet before meeting with Hank or after meeting with Hank.

(regular banter)

Denise: Alright does everyone have enough stuff to do this weekend?

And as they reflect on the project—this term and last:

[Reflections 3-31.mp3, 8 min.]

Discussing if some of this was done last semester, they would have not had to do so much of it.


Bob: I wish you guys were on my team last semester, cause this would have been done. Our partner was never coming to the meetings, and Joann tried, but it took her time to understand the code, and was concerned about getting it finished, but we would have many very long meetings and we would just sit there.

On Thursday, but unrelated to the meeting, Dave responds to a request from Denise:

After the meeting Justin sends:

Then Denise sends:

Prior to the meeting with Hank, Justin posts an updated model:

Which he immediately amends:

Denise sends a progress report:

And Bob apologizes shortly before the meeting:

The meeting with Hank begins with the CS team searching for definition of some terms and what those terms ‘do’—deadman leads, how the controller “jumps in the middle’ at about 7 minutes in, followed by an explanation of encoders:

[Defining Terms & Functions 4-5.mp3, 18 min.]


There is a discussion about the parameters dead man vs dead man old and corresponding modes control mode vs control mode old. They also discuss with Hank that another parameter pedestal wont change but one needs to have it in the code. They then move on to discuss an object or struct for the ship parameters and values. Hank asks if the team has examined where these variables are used.

Hank then moves on to describe the role of encoders, in that encoders are measuring the boom angle. He asks if this gets calculated somewhere in the code.

There is more discussion about the parameters and values used in the code. At one point in the discussion Hank comments that Denise knows this code better than anyone.

The discussion moves on to other topics like how Inverse kin is called according to where you want the ship to be based on the crane position. Hank explains how joystick and nominal crane position work together. They talk about a crane limited version of inv kin, like a command for where u want the crane to be. Hank demonstrates how an encoder works, and explains what the dead man is.


They are aided once again by one of Denise’s drawings:

[Crane 2\Crane 2 Drawings\Drawing4-3.pdf]

 

Hank checks the team’s progress, showing more appreciation as he does:

[Checking Progress 4-5.mp3, 9 min.]

 

They are looking at the diagram which Denise is explaining.

Hank:Are u able to pass structures?

Denise explains how init runs and affects other S functions.

Hank asks what some of the functions do. Specially init.

Hank: Oh that is sweet! That makes sense now. So when this one is high, that value becomes high and this one goes low, that value is low. I finally get it.

Hank: What is setup?

Denise explains what setup is.

Hank: I love it. I love it! The beauty of something like this is that I can understand it. Someone with a high level of knowledge of how the code or the function works can look at it and completely understand it.


Denise: How does simulink use static variables.?

Hank: It is a C question, let us separate simulink and C here. Is it how C does it?

Denise: I know how C would do it, but I wanted to know if it can be done the same way in C.


(more discussion on updating static variables in simulink and C)


Hank: We have a couple of minutes, let us test that. We could write a small piece of C code and we could try the same thing in simulink. But I think it cant be done.

Denise: Yeah, I guess cause I know how malloc does it, but I don't know how simulink would do it.

Do we still want to try writing the code quickly now.


(more code discussion)


Denise: So we might have to change all of our structs into vectors, because passing structs might be a issue.


Hank: So what timeline is there for next week.

Denise: We might have an adjustable model, not a working piece. We will have most of the functions ready except solution. Solution is going to take more time.

Hank: I'm not sure what the issue is with solution.

Denise: It is like 3 pages of stuff that checks dead man vs dead man old and control mode vs control mode old.

Bob: And that is another issue, we dont know how many inputs solution takes.

Hank: I dont know

Hank: (looking at Denise's pages of notes about solution)This is cool. Denise you know this code probably better than anyone at this point.

After this they were checking through the list of functions and whether they are done.

Then they discussed what Denise Justin and Bob were doing, who took which functions.

They established that the helper functions are not complete. And that they need to be putting it together,

We could run a test to see if simulink understands static variables.

 

After the meeting, Denise fills Bob in:

 

Questions:

  1. The team discusses Hank's suggestions about the input shaping variables.
  • At this point, did the team simply implement what the client wanted?
  • Do you think in typical software projects, there is often a difference between what the team wants to implement and how the client wants things done?
  • How would you deal with such a situation?
  • How would you assess the Seabase team's method of dealing with it?
  1. “Bob: Bob recanting his experience from last semester, and comparing how pleased he was with the current team, and the progress that was being made. I wish you guys were on my team last semester, cause this would have been done. Our partner was never coming to the meetings, and Joann tried, but it took her time to understand the code, and was concerned about getting it finished, but we would have many very long meetings and we would just sit there.”
  • Would you agree with Bob's assessment of the first Seabase project?
  • Do you think Bob could have done things differently in the first attempt of the Seabase project, to be a more effective team member?
  • Compare Bob's behavior in the two Seabase projects. How much do you think his involvement affected both projects?
  • Do you think it is important for all team members to be actively involved in the project continuously for a positive outcome?
  • In the event of a less than favorable outcome, should all project members be considered equally responsible or just the more active and vocal ones?
  1. Hank expresses appreciation for Denise's chart.
  • Do you suppose all work products or communication artifacts are equally useful?
  • Should the usefulness of an artifact be weighed against the time and effort invested in creating it?
  • Do you suppose there could be a situation where a project has artifacts that take time to create but are not used enough to justify their existence? Should creating work products be a careful decision?

Module G

Wednesday, 30th March, 2005 – Tuesday, 5th April, 2005

Denise sends out a reminder:

The team spends some time trying to “figure things out” about the code, Matlab and the project in general:

[Matlab-Code-Project 3-31.mp.3, 14 min.]

There is discussion on points of contention from their previous discussion with Hank. The team asks themselves the following questions:

Should we be using structs or pass things in vectors as Hank had suggested before?

How does input from the joystick come in? Input values, or vectors or sine wave?

What are multiplexers and how is the code using them?

We see the change in how structured and productive the internal team meetings are. The team members appear more focused than they have been in the past, and appear to be more aligned with their goals.



They also revisit what Hank wants:

[Client Wants.mp3, 2 min.]

The team recaps part of the discussion with Hank about Inverse kinematics

They discuss that they just want command motor. And some discussion is there towards the end about the fact that the sponsors are coming sometime during exam week.

Justin: How come Hank wants us to do those work vectors or whatever, in case we want to recompile it back into C, what is the purpose?

Denise: it took so much work to convert it from C to matlab just to convert it back.

Bob: Maybe that is what the summer job was. That is why he wants us back next summer.

Denise: It better pay very well if we are doing this

(more discussion on code variables)

And revise their responsibilities:

[Team Resp 3-31.mp3, 8 min.]

The team discusses what init does and what solution does. These are different blocks of code.

Solution calculates the input swing, like the pre-init.


Denise: I am not leaving this building for at least 5 hours.

Justin: So we should be passing the structs as vectors? Why cant be pass the structs?

Bob: We cant.

Denise: We cant pass them because S function does not know what a struct is.

Bob: We are putting this code to this block and then that code to that block,how do we know whether it will execute at the right time.

Denise: we are just putting it together and see if it will work.

(more code discussion)

Justin: What is the point of initializing this function?

Denise: It is not initializing them, it is just calling them, and it has a point array which it takes by reference and changes that.

(more code discussion)

Justin: Is solution calling this? Or is solution the last thing on the list that spits it out.

Denise: Yes solution calls it. Solution we are going to try and preserve.

Justin: So what is init doing.

Denise: init is just initializing value.

Justin: So how does solution affect swing angle.

Denise: Solution calls the value and updates the swing angle. Solution is the function in CS which calls everything else.

Justin: So solution is what starts everything off.

Denise: it initializes the control stuff and the analog input

Justin: so, It is kind of like a pre-init. Before the init.

Bob: when time are we meeting next week?

Denise: Do you guys want to meet before meeting with Hank or after meeting with Hank.

(regular banter)

Denise: Alright does everyone have enough stuff to do this weekend?

You can listen in as Denise “takes charge” of the team:

[Taking Charge 3-31.mp3, 7 min.]

What init does, what solution does.

Solution calculates the input swing, like the pre-init

[This is also an excerpt from a previously transcribed conversation]


Denise: I am not leaving this building for at least 5 hours

Justin: So we should be passing the structs as vectors? Why cant be pass the structs?

Bob: We cant.

Denise: We cant pass them because S function does not know what a struct is.

Bob: We are putting this code to this block and then that code to that block,how do we know whether it will execute at the right time.

Denise: we are just putting it together and see if it will work.

(more code discussion)

Justin: What is the point of initializing this function?

Denise: It is not initializing them, it is just calling them, and it has a point array which it takes by reference and changes that.

(more code discussion)

Justin: Is solution calling this? Or is solution the last thing on the list that spits it out.

Denise: Yes solution calls it. Solution we are going to try and preserve.

Justin: So what is init doing.

Denise: init is just initializing value.

Justin: So how does solution affect swing angle.

Denise: Solution calls the value and updates the swing angle. Soltion is the function in CS which calls everything else.

Justin: So solution is what starts everything off.

Denise: it initializes the control stuff and the analog input

Justin: so, It is kind of like a pre-init. Before the init.

Bob: when time are we meeting next week?

Denise: Do you guys want to meet before meeting with Hank or after meeting with Hank.

(regular banter)

Denise:

Denise appears to be very comfortable about blatantly appearing as the leader. One can see become an authority figure, like Hank.

Alright does everyone have enough stuff to do this weekend?

And as they reflect on the project—this term and last:

[Reflections 3-31.mp3, 8 min.]

Discussing if some of this was done last semester, they would have not had to do so much of it.


Bob:

Bob recanting his experience from last semester, and comparing how pleased he was with the current team, and the progress that was being made.

I wish you guys were on my team last semester, cause this would have been done. Our partner was never coming to the meetings, and Joann tried, but it took her time to understand the code, and was concerned about getting it finished, but we would have many very long meetings and we would just sit there.

On Thursday, but unrelated to the meeting, Dave responds to a request from Denise:

After the meeting Justin sends:

Then Denise sends:

Prior to the meeting with Hank, Justin posts an updated model:

Which he immediately amends:

Denise sends a progress report:

And Bob apologizes shortly before the meeting:

This is another meeting which Bob is unable to attend. However, this time he remembers to inform beforehand.

The meeting with Hank begins with the CS team searching for definition of some terms and what those terms ‘do’—deadman leads, how the controller “jumps in the middle’ at about 7 minutes in, followed by an explanation of encoders:

[Defining Terms & Functions 4-5.mp3, 18 min.]


There is a discussion about the parameters dead man vs dead man old and corresponding modes control mode vs control mode old. They also discuss with Hank that another parameter pedestal wont change but one needs to have it in the code. They then move on to discuss an object or struct for the ship parameters and values.

The nature in which Hank inquires into the team's understanding this time, is far less in the nature of assessing them, and reflective of the greater amount of confidence he has in them at this point. He asks about the team's understanding here only to decide how far he needs to explain the concept to them, and not so much to judge their efforts.

Hank asks if the team has examined where these variables are used.

Hank then moves on to describe the role of encoders, in that encoders are measuring the boom angle. He asks if this gets calculated somewhere in the code.

There is more discussion about the parameters and values used in the code. At one point in the discussion Hank comments that Denise knows this code better than anyone.

The discussion moves on to other topics like how Inverse kin is called according to where you want the ship to be based on the crane position. Hank explains how joystick and nominal crane position work together. They talk about a crane limited version of inv kin, like a command for where u want the crane to be. Hank demonstrates how an encoder works, and explains what the dead man is.


They are aided once again by one of Denise’s drawings:

[Crane 2\Crane 2 Drawings\Drawing4-3.pdf]

 

Hank checks the team’s progress, showing more appreciation as he does:

[Checking Progress 4-5.mp3, 9 min.]

 

They are looking at the diagram which Denise is explaining.

Hank:Are u able to pass structures?

Denise explains how init runs and affects other S functions.

Hank asks what some of the functions do. Specially init.

Hank:

Examining the chart, Hank has a small epiphany about part of the code. He appears highly impressed with the chart, and expresses his praise for it rather profusely.

Oh that is sweet! That makes sense now. So when this one is high, that value becomes high and this one goes low, that value is low. I finally get it.

Hank: What is setup?

Denise explains what setup is.

Hank: I love it. I love it! The beauty of something like this is that I can understand it. Someone with a high level of knowledge of how the code or the function works can look at it and completely understand it.


Denise: How does simulink use static variables.?

Hank: It is a C question, let us separate simulink and C here. Is it how C does it?

Denise: I know how C would do it, but I wanted to know if it can be done the same way in C.


(more discussion on updating static variables in simulink and C)


Hank: We have a couple of minutes, let us test that. We could write a small piece of C code and we could try the same thing in simulink. But I think it cant be done.

Denise: Yeah, I guess cause I know how malloc does it, but I don't know how simulink would do it.

Do we still want to try writing the code quickly now.


(more code discussion)


Denise: So we might have to change all of our structs into vectors, because passing structs might be a issue.


Hank: So

Hank taking his regular update, but this time, his tone is far less formal.

what timeline is there for next week.

Denise: We might have an adjustable model, not a working piece. We will have most of the functions ready except solution. Solution is going to take more time.

Hank: I'm not sure what the issue is with solution.

Denise: It is like 3 pages of stuff that checks dead man vs dead man old and control mode vs control mode old.

Bob: And that is another issue, we dont know how many inputs solution takes.

Hank: I dont know

Hank: (looking at Denise's pages of notes about solution)This is cool. Denise you know this code probably better than anyone at this point.

After this they were checking through the list of functions and whether they are done.

Then they discussed what Denise Justin and Bob were doing, who took which functions.

They established that the helper functions are not complete. And that they need to be putting it together,

We could run a test to see if simulink understands static variables.

 

After the meeting, Denise fills Bob in:

Department of Computer Science | MTU

www.cs.mtu.edu