8/2/06 (Wednesday)

Nathan: The final paper and presentation are due on Friday, August 4th @ 9AM in room 211 of FGH. Today we are putting the finishing touches on the poster, final report and the powerpoint presentation.

8/1/06 (Tuesday)

Nathan: For the most part of the day the main goal was to get a finished product of the poster for our project. Tomorrow there will be a meeting with Dr. Karsai @ 9am and he will critique our poster and get an update on our progress on our projects. The poster is for the most part finished and in the poster we have an : Introduction, Three tank setup, Data Collection, model progression, Model Based control, Fault Diagnosis, results from our various experiments and future work.

7/31/06 (Monday)

Nathan: The majority of the day was spent looking over the material with of the entire project and beginning to discern what needs to be spoken about on the poster, presentation and the final report. The controller was run and the data collected from it will be put onto the poster along with a real-time experiment of the fault diagnoser.

7/28/06 (Friday)

7/27/06 (Thursday)

Nathan: The majority of the day was trying to figure out what method could be used to alter a graphing class that I found to use in a graphical user interface for the three tank system. The GUI could be used to monitor the system while it is reading the data from the system. After that I ran the current controller on the system again and the results seemed to be better than that of the past. The controller will maintain the tanks at their various heights but the lower the intial value you start out with the longer it may take the controller to reach the heights in which it is trying to maintain the tanks.

7/26/06 (Wednesday)

Nathan: The controller is still function properly but it was suggested that possibly the a Matlab script would need to be written to show how the system behaved if a fault was introduced and to observe the valve settings in the different modes that the system is able to be in. 

7/25/06 (Tuesday)

Nathan: In the morning the parameters were estimated again to assure that they have not varied from the previous days, the parameters were different but still close to other estimations that we have performed in the past. The new parameters were input in to the C++ controller model and run on the physical three tank system. The system behaved as it should of, mantaining the heights of tank 1, tank 2 and tank 3 at 40cm, 30cm, 15cm respectively. Improvements on the controller still need to be made but for the most part it works quite well according to the results. I still am working at a GUI for the three tank system I have found some information about some online and will continue to work on this.

7/24/06 (Monday)

Nathan: After close observation we noticed that the three tank system may of changed as far as the flow rates and the transfer resistances. During the re-estimation process it was apparent that other problems with the system arose. Tank 1's sensor reading was always outputting "80.7218" , we later found out that one of the wires for the sensor was loose so when we secured the connection the sensors worked fine. Also the filter began go take its effect of the system because the flows rates dropped to about a third of what they once were when we first changed the filter. See that a reasoned that the parameters may need to be checked daily and to assure consistancy and accuracy of the model and the test that we would be running on the model. The parameters were re-estimated and where now different from what they once were.

7/21/06 (Friday)

7/20/06 (Thursday)

Nathan: In the morning Brian found that possibly the parameters needed to be re-estimated for the transfers and the draining. Those parameters were re-estimated but the models have not been updated to reflect that. I continue to look at how to write a GUI and graph data. Marty came in later on in the day and we found a source on the internet that allows up to update the graphs on visual and produce nicer graphs. So far we cannot get the code to know about the graphic files that were downloaded for the internet. The goal now is to see if Microsoft Visual can recognize these files and then draw a picture, when the picture is drawn we will see how to adapt the graphs for graphing the data in real time on the three tank system.

7/19/06 (Wednesday)

Nathan: For the first part of the day I read a book which contain details about creating a dialog with a GUI that allows you to draw, because one of the goals for me is to create a GUI that graphs the real time 3 tank system. Tank 3 draining resistance was adjusted and had to be re-estimated. All of the models and code also had to be updated to include the new draining resistance. Wu Jian and I implemented the controller on the real three tank system. The goal of the controller is to maintain tank 1 at 40cm, tank 2 at 30cm and tank 3 at 20 cm. The first experiments the values were a little lower than they needed to be but through adjusting the system it now is acceptable but work still need to be done on the controller so that it can be more accurate.

7/18/06 (Tuesday)

Nathan: All of the flow rates for each mode that the filling is able to transition to had to be re-estimated since the water filter for the tank had to be cleaned and replace. Now all of the eight flow rates for the system was re-restimated and they appear to be greater than what they once where. All of the models and code that had the older flows had to be replaced. The simulation of the 3 tank system still is precise even though the flow rates have been changed.

7/17/06 (Monday)

Nathan: There was a problem with the speed of the flow from the pipe because they begun to get slower and slower, Brian looked and found that the filter for the pump was dirty so he cleaned it. Now that the pump is clean it means that the parameters for the pump in different settings must be re-estimated. The pump flow is now higher than what it once was. Now that the pump flows had to be re-estimated ever source of code that we have that involves the flows of the pump speeds need to be changed as well.

7/14/06 (Friday)

7/13/06 (Thursday)

Trip to NASA in Huntsville

7/12/06 (Wednesday)

Nathan: Spent the majority of the day reading tutorials online on how to create GUI using C++ and C#. The method of creating these GUIs are a little involved but it is just know what the proper syntax is to setup the type of user interface that is needed. My goal is to find something that will somehow futher explain how to code a graph inside of the GUI. For the project we will need to be able to read in data and plot  the data on a graph and make it visible to the user and update the plot in real time.

7/11/06 (Tuesday)

Nathan: In the lab there was no up to date version of Microsoft Visual studio. It was installed and then I created another type of GUI on the more up to date version of Microsoft Visual Studio. Since the GUI in Visual gives an outline of functions I tried to define each part of the GUI and then declare variables. After declaring the variable the goal was to be able to give them initial values and get values from those input variables. This will be helpful because in the future the user will be able to set certain parameters for the real-time and simulation experiments for the three tank system. 

7/10/06 (Monday)

Nathan: Research the internet to try and find a method, tutorial or example of how to construct a graphical user interface (GUI) for the three tank system. Marty came and help me to try and get a grasp on the coding method for creating GUIs. So far I know that when defining a GUI you can use a dialog and the dialog is the "outline" for how you would like your GUI to function. A dialog will create the setup of different function but the functions still need to be defined by the coder or from what the user inputs into thg GUI.

7/9/06 (Sunday)

Nathan: Came in the lab in the morning at 9am, and double checked the adjacenty matrix for the three tank system. Also double checked all of the code that was done on Saturday. The adjacenty matrix will represent all of the different trajectories and mode transistions that the controller will be able to function in. Also the Graphical User Interface (GUI) needs to be made using C++ for the three tank system, research will be conducted to make sure that the method of constructing the GUI is accurate and user friendly.

7/8/06 (Saturday)

Nathan: Various task were given to me to complete be the end of Saturday.

1. Test all of the modes of the system using a for loop to represent the time, using an mfile.
2. Test the simulink block model pump for all three speeds (0 - off, 2 - low, 3 - high) and make sure they work properly. for all of the modes that the simulink model is able to go to.
3. Include the numeric adjacenty matrix in the mfile "adjmatrix".
4. Double check the model control table for accuracy.
5. Know how to use the "travel function" which describe the trajectories of the three tank system.
6. double check the adjacenty matrix to ensure there are no transition errors.

7/7/06 (Friday)

Nathan: Tested all of the model of the system modes for all of the various types of pump speeds and mode changes. The model seems to have the right type of behavior that was expected. The model can go through all of the 17 modes and represent them in the right manner.

7/6/06 (Thursday)

Nathan: spent the majority of the day creating the three tank models behavior in an mfile on Matlab. The mfile will represent what modes the system needs to be in depending on the current state of the system.

7/5/06 (Wednesday)

Nathan: I was to read all of the previous work that was done with the controller and get familiar with the method of creating a controller for the three tank system, this information is vital because it explains in detail the methodology of how the controller works.

7/4/06 (Tuesday)

Fourth of July Off.

6/30/06 (Friday)

Nathan: Midsummer Presentations @ ISIS 10am.

6/29/06 (Thursday)

Nathan: Took the time to finish writing the midsummer report research paper on what we have done so far on the three tank system fault diagnosis project. Later on in the day we all met with the graduate assistants to practice on our presentation. After that the finishing touches were added to our presentation. 

6/28/06 (Wednesday)

Nathan: We continued to work on the presentation for the midsummer presentation on Friday. The finishing touches were put on it. The presentation will be a progress report on what we have done so far, and will also discuss the overall steps that we have taken to reach the point that we are currently are. After that was done we discuss how the report (paper) will be setup and what needs to be discussed in the report. The paper will have an abstract, introduction, modeling the system, software integration, the problems and solutions, data validation, and then the conclusion.

6/27/06 (Tuesday)

Nathan: I still continued to work on the presentation and put the finishing touches and in the afternoon we met with Wu Jian and he gaves up some tips and what to improve. There will be a practice run presentations on Thursday with the rest of the students that are a part of the SIPHER program. This is important because for the majority of the presentation we will be speaking and the presentation is just a reference. Also the paper is also due on our work is due on Friday so it is important that is finished as well.

6/26/06 (Monday)

Nathan: The majority of the day was to work on the presentation and make sure that everything is in order because we will present on Friday for about 20 minutes about the work that we have done thus far in our research project. The things  in which I will discuss during the presentation are:

1. Hybrid Bond Graphs and BGs
2. Discrete time equations
3. How to implement the model (GME, m-file, simulink block model)
4. Data Validation
5. Results
6. Future work and Conclusions
   

6/23/06 (Friday)

Brian: The bug was a fairly simple mistake, but I spent two hours trying to track it down.  Around lunch time, I met with Nag to talk about the next steps.  I spent the afternoon implementing the changes we discussed.

1. read() method which abstracts the dataset structs from the developers writing controllers or using the client class
2. DataClient now dumps oldest dataset from the buffer rather than overflowing and crashing
3. wrote example client to demonstrate use of the functions for accessing and processing data from the system

I also updated the controller templates to use the new method and updated the README.  The example client replaces the udpdump project for debugging the multicast connection.  I updated the installer with the new projects/files and
passed along the final version to Nag.  We will be meeting on Monday to get FACT listening online.

Nathan: I continued to still work on completing the Simulink block model to get a running model. The part with the S-Function which account for delay was taken out, because the delay was already accounted for as a part of the input from the experiments. The model began to work and I was too put the test data as input and compare the output from the Simulink block model to the real behavior of the three tank system. The output of both the model and the real system had the same behavior so the next step was  to the calculate the average absolute error to see how close to the real data the model was. The results showed that the Simulink block model is sufficiently accurate and the most accurate out of all of the models.  (Automatically generated GME, m-file, Simulink block)

6/22/06 (Thursday)

Nathan: The majority of the day was spent working with simulink in an attempt to model the three tank system with Simulink blocks. All of the equations and all of characteristics of the physical system (with the except of delay for now) were to be represented in the simulink model. All of the states (17 states for our purposes) were to be modeled on simulink. The main issue with modeling this is to account for the "pump" setting. Unlike the other inputs the pump setting has 3 modes off(0), low(2) and high(3). This differs from the test of the inputs which only have to modes, on(1) and off(1). As of the now the model runs without the "S-Function" (which incorporates pump delay), but for some reason it is not proceeding to the next states as it should when tested with a simple controller. I will troubleshoot this issue until the problem is fixed.

Brian: Today I finished integrating config files into the various applications.  By the end of the day, most of the system configuration was done through files.  Everything was also tested with varying numbers of NCAPs and at different rates.  I added in a couple new projects (udpdump -- for debugging udp multicasting, manual controller -- for controlling the system from the command line).  I also made sure that each component could start(), stop() and reset() properly.  I still need to add support for setting buffer sizes from config files.  In addtion, the controller development documentation still needs to be updated.  However, there are still some issues.  NCAPs are generating an allocation error.  I think I may have accidently changed something in the Data Processor while I was cleaning things up.

6/21/06 (Wednesday)

Nathan: The first part of the day was spent looking over past notes and past methods of modeling the system from other's work on how the three tank system was modeled in the past. It would appear that in the past that others did not take into account the various pump speed, but only model the pump as on or off. I reviewed other's method to try and get an idea of adapting their methods but adding various speeds for the pump. After gaining some short background I begin trying to model the system on Simulink, and tried to model it specifically for own purposes.

Brian: During the morning, I tested the ConfigReader class with a test project.  By 10:45, it was working properly. I started intergrating with the server program.  It only took a couple hours to get it working with a configuration file.  The rest of the day I spent integrating config files into the interface class.  Most of the time was spent getting the NCAP objects to read their config file to set the appropriate channels and ipAddresses automatically.  By the end fo the day, config files were integrated int o ncaps,interface, and data server.  The Client and Logger were next for Thursday.

6/20/06 (Tuesday)

Nathan: The day was spent in the lab working on M-files on Matlab and generating an output which were to be compared witht the physical data. All of the equations that were written on Monday were to be used in the M-file. The code for the M-file was writing a serious of for loop and if statements. e.g. (for (mode == 2 & pump == 3) fill tank 1 at high speed). The same type of coding was done for all 17 modes of the system and the code was then compare to the logged data from earlier. This was done to see which out of the two methods were more precise; M-file data generation or the Simulink model that was automatically generated by an interpreter from the hybrid bond graph created on GME. The M-file seemed to be more accurate for tank 2, but a little less accurate for tank 3.

Brian: I spent the first half of the morning finishing the intergration.  I had to refactor a few parts of the code in preparation for the network layer.  For example, I had to move the mapping functionality into the InterfaceClass (From the Processor) because network clients won't have a DataProcessor object available.  I added an abstract DataSource class os the clients (logger, controller, fact) can be built independent of the source of data (network,local, etc.).  After lunch I started working on config files.  To make config file intergration simpler, I wrote a simple ConfigReader class which takes a config filename and allows the program to make calls such as  while(NextSection()) or while(NextKey()) to parse through the config file.  By the end of the day, I had the class complete, but wasn't able to finish testing.

6/19/06 (Monday)

Nathan: Everyone meet at 9AM for the meeting with Dr. Karsai for an update on what has been going on lately with everyone's project. He also reminded us that we could use either this week or next week to begin to prepare for our mid-summer presentations which are on 6/30/06. After the meeting I went into the lab and began to write the equations for the 17 states that the system will be in. After I finished I sent them in an email to Wu Jian. After that I went back to the experimental data that was collected and calculated the average absolute percent error. The largest was average was about 0.77 cm off when comparing the Simulink model the test data collected from the system.

Brian:  Over the weekend, I finished the prototype by switching to dumping binary datasets through the sockets and using them on the receiving end.  Most of today was spent testing the system with variable numbers of NCAPs/Channels.  There were a number of problems, but they were mostly fixed by lunch.  In the afternoon, I started integrating the udp multicasting code into the project.  This created a number problems.  I was able to get the code into the project, but it really depended on config file support so I wasn't able to actually test it. 

6/16/06 (Friday)

Nathan: Today I spent most of the day comparing the data that was collected from a logger from experiments that I performed on the three tank system. The data collect from the logger was compared to the Simulink model. Most of the simulink outputs for the system behavior was very close, but a way to validate this data still needs to implemented. i thought of possibly applying the R^2 function to show how close the two sets of data are but that will not work when you have two separate sets of data. The plan is to use an average absolute error to validate the whole set of data by analyzing the data at each specific point.

Brian: Today I started working on the issues Nag and I discussed on Thursday.  Almost all of my time today was spent workign on udp multicasting.  After a few hours of reading, I started working on a prototype/proof of concept project to work out the bugs.  By the end of the day, I had a workign project which dumped text over udp and I had a client which received the strings and dumped to the screen.

6/15/06 (Thursday)

Nathan: Today the data collection from Wednesday was tested on the Simulink model with the physical model of the three tank system. The behavior of the simulink model was correct for tanks 1 and 2 filling and transferring but the draining resistance for tank 3 was incorrect. Therefore, the draining resistance for tank 3 had to be re-estimated.

Brian: Today I continued where I left off yesterday with the documentation and controller development.  I finished a README file for controller development and tested it myself.  I also used Visual Studio to create an installer which includes the binaries and headers necessary to use the code or develop controllers for the system.  I put together a release candidate package with things mostly working and tested it on another machine.  In the evening, I met with Nag and we talked specifics on what still needs to happen before integrating with FACT.  There were a few things that still needed to happen:

1. Config Files - All the components should be able to read their configuration from files
2. Testing with only certain NCAPs/Channels enabled (this should work, but hasn't been tested since the changes)
3. UDP Multicasting (for multiple consumers)

6/14/06 (Wednesday)

Nathan: I spent the all day in the lab collecting data of how tanks 1 and 2 transfer into tank three. Then the data was saved with a logger and various variables were defined on Matlab. The variable will later be used to model the systems physical behavior vs. time on the Simulink model of the three tank system. After the variables are used in the simulink model they will be compared to the actual data collected and this will determine if the model is accurate enough or not. If not then the parameters may need to be re-estimated or the pipe resistances re-estimated.

Brian: The code from yesterday was working at the lowest level, but I still needed to make some changes in the higher level tools to get them working properly.  There were a number of minor changes that needed to be made to allow the logger and controller programs to get information properly.  I spent most of the day testing thoroughly and fixing minor bugs.  I also cleaned up the project to get it in a state where it could compile on other machines.  This included moving headers to a common folder and switching all the projects to including on a relative path.   I also created template controller code and began documenting how to build a controller to work with my code.

6/13/06 (Tuesday)

Nathan: I still was doing some data collection because I noticed that when one attempt to fill both tanks at the same time that tank 2 fills up faster than tank 1. And with tank 1 splashing occurs and this at time can throw off the data collection. For example the splashing in tank 1 may cause the sensor to think the water height is higher than what it truly is so if the height of the tank is 14 cm than the splash may cause the sensor to read 20 cm for that one specific data collection point. The points which are caused by "random splashing" can throw off data in calculating the flow rate of each tank in each mode. It is important to get an accurate set of data so that it can be compared to the model generated on simulink and the two sets of data can be compared to one another for preciseness and accuracy. When doing the data collection for the filling of tanks 1 and 2 simultaneously, on pump speed 2, tank 1 has a faster flow rate than tank 2. And when filling simultaneously on pump speed 3, tank 2 has a faster flow rate than tank 1.

Brian: Today was spent fixing bugs and thoroughly testing the different parts of the software.  With more testing, I found that tank 3 always responded about 300ms after the other NCAPs.  To fix the problem, I added another timer to the thread.  After the main timer fired, I polled tank 3.  Then after delaying 300ms, I sampled the other tanks.  This resulted in a set of data which appears to be very accurate.  The rest of the day was spent rewriting the data processing code for the new data collection method and reintegrating the controller and logger to the system.  By the end of the day, I was able to successfully run the controller and log at 3Hz with minimul buffers for over 15 minutes.

6/12/06 (Monday)

Nathan: My main task for this day was to collect data and observe the behavior of the three tank system when they were being filled with water. I was too calculate the various flow rates of each mode the system can be in (e.g. fill tank 1, fill tank 2 and fill both tanks 1 and 2), this was done at too various speeds "low speed" which is 2 (on a scale of 1-10 pump speed) and again on "high speed" which is a 3 (on a scale of 1-10 pump speed). A logger program was run that sampled the water heights of the each of the tanks, the pump speed, and the time in which it was taken. The data collection from the logger can be used to calculate the different flow rates of the water in different modes of the system.

Brian: I spent today working on getting a version of the code working with Win32 waitable timers.  I started with the most basic level and tested thoroughly to be sure that the samples were being taken accurately.  By the end of the day, it was sampling correctly, but there were still some problems because tank 3 responds significantly slower than the other NCAPs.  This should be fixed tomorrow.

6/9/06 (Friday)

Nathan: The hybrid bond graph that I created Thursday was to be put into the bondgraph paradigm and then tested for it's accuracy. Then I was to use the parameter estimation for the pipe resistance estimation. Then the bond graph was put through an interpreter and a model was generated on simulink. The output from the model responded as expected for all three tanks. The next test is to collect data from the system itself and see if both the simulink model data and the data from the system are close, if not then a more accurate parameter estimation must be taken.

Brian: I had two possible theories regarding the problem.  1) it could be that there was just too much processing to keep up with the incoming data stream OR 2) there is some bug in my code which is causing the buffers to suddenly fill.  I met with Nag in the morning and he suggested more testing to find the problem.  In order to better diagnose the problem, I added a log to the data pool class which would allow me to collect data on the state of each pool over time.  Plotting results from one run produced unusual results.  Everything appeared to work fine until the very end.  This seems to point to the second solution, but that wouldn't do anything for the other issue with sample times.  In order to solve both problems, I will be attempting to switch to timed sampling.

6/8/06 (Thursday)

Nathan: I went to the hybrid system lab in room 312 and began to learn how to create a bond graph on GME using a bondgraph paradigm and the FACT software. The objective was to create an accurate model of a three tank system and use an interpreter to create a simulink model. After the model is generated on simulink we can observe the model's output and see if it matches up with the expected behavior of the system. My homework for the night was to create a hybrid bond graph from scratch of the 3 tank system and generate the pipe resistance of tanks 1 to 3 and tank 2 to 3 and the draining tank 3 for the parameter estimation.

Brian: I spent the first part of the day working on more experiments with the software.  In order to verify that the components were "in sync" I shrunk the size of all the buffers.  On Wednesday, I thought I had turned all of them down.  With more work, I found that I had forgoten to shrink the buffers in the NCAP objects. Unfortunately when these were brought down to 10-40 elements, they software started having problems.  It seems like I was hiding the problem all along with the large buffers (~100 elements).  I spent the afternoon trying various solutions such as adding in a delay to the polling loop without success.

At the same time, I found that the data points were not being accurately sampled.  The time between samples was varying from .8 to 1.2 seconds when it was supposed to be 1 second.

6/7/06 (Wednesday)

Brian: Continuing where I left off on Tuesday, I finished getting the controller integrated. I ran a few experiments at the end of the day with the logger.  They were mainly successful after the bugs were worked out.  I was able to log data for 6 minutes at 3Hz without any problems.  I also successfully logged for 30 seconds at 4 Hz.  With just a little more work, the controller will be working and I will be ready to really start integrating with FACT.

Nathan: I continued using bond graphs, and had an opportunity to finish all of the homework problems that Wu Jian had given me. I then did research on hybrid bond graphs and looked at how other people used bond graphs to model systems. My goal was to determine the difference between a bond graph and a hybrid bond graph.

6/6/06 (Tuesday)

Brian: I continued working on restructuring the code I wrote during the last semester.  The goal is to make it interface with the FACT diagnoser.  After today it was logging from test data.  I will spend tomorrow integrating the existing controller with the new code.  When complete, the new code will need to be tested as there were some problems with the code from last semester running too slow compared to the system.

Nathan: I spent the first part of the day studying about the systematic way to analyze and model systems using bond graphs. Wu Jian gave me homework and I am too provided the equations for an electrical circuit and a two tank system. After researching about hybrid bond graphs online I went to the engineering computer lab and used simulink to model the equations that came from the bond graphs. This tool is important because simulink will be one of the programs that is used to model the three tank system that we are working on.

6/5/06 (Monday)

In the morning we had the first of our weekly meetings. During the meetings we are to talk about what we have learned so far, What we plan to do for the upcoming week, and what we are doing relative to our projects. For the rest of the day Brian worked on modifying some code that would be a controller for the three tank system. Nathan was looking into Bond graphs and Hybrid bond graphs and how they relate to the equations of the behavior of the system. The Bond Graphs will be used later with Simulink to model the three tank system.

6/2/06

During the first part of the day, we further discussed models of computation with Ethan.  In particular, we discussed the concept of abstraction in models.  Using the dataflow model as an example, we proved one such abstraction (that a dataflow model without cycles implies that the represented program is deadlock-free).  The afternoon was spent working on our project specifically.  We worked on bond graphs for a good part of the afternoon.   We went from an introduction to equation generation.  With that complete, we went up to the hybrid systems lab.  We estimated parameters for the three tank system (filling, draining, and transferring).

6/1/06 (Nathan)

Today the majority of our our day was spent in the SIPHER lab working on creating MetaModels with Ethan. The MetaModel we were supposed to create was an adder that worked the function 2x-1.  Lab 2 two was done and completed from the website (http://www.isis.vanderbilt.edu/projects/4ml/sipher.htm). After finishing the lab with the GME software, we met with Daniel Balasubramanian and he trained us on how to use the software TeXnic and MiKtek and how to the LaTex program to write and format our papers. The software allows the user to write their paper in a .pdf format and add a bibliography, footnotes, titles, graphics and more. Daniel sent a template to us on an email. Also the LaTex paper needs to finish by next week friday.

5/30/06 (Nathan)

• SIPHER Intro Meeting (meet grad students, participants, SIPHER staff and professors)
• Campus tour (EGR building)
• GME Training, Lesson 1
• Papers were given for review from Daniel B, and Wu Jian.
  

5/30/06

• SIPHER Intro Meeting
• GME Training, Part 1