The importance of speaking to people who have had experience with similar systems in the past. This again, is something that we did not do, and I later felt that by doing so, we could have avoided many of the problems we encountered.
.
That discussing problems with people not involved in the project can lead to new solutions you may not have previously thought of.
.
"Get help. We never contacted the tutor who was there to help us when we needed it and we only went to see James Trevelyan a few times.
(I now appreciate the) "importance of speaking to people (like last year's students) who have had experience with similar systems in the past. This again, is something that we did not do, and I later felt that by doing so, we could have avoided many of the problems we encountered.
<list of topics at top of page>
I have learned about the time savings inherent in having a good understanding of the tools available and their capabilities and limitations before starting the project.
.
"From this project I learned a great deal about real control systems and I have learned far more in this unit working hands on with equipment and software and in any other unit. It is quite a sudden change in this unit is the most unique and different from all the other once I have done. In addition, working with the third-year students has been a good learning experience for me. Quite a number of times during our group meetings I would ask them questions on the various sensors or hardware or simply watch them do their work and learned from them.
"I assumed that acquiring a thermocouple from a laboratory technician that matched our specifications would be enough but unfortunately I forgot to ask which metals are used in the thermocouple and how it works. Also I seemed to be unprepared for the presentation. I was nervous and I panicked and this cost me marks because I was asked a question which I knew the answer to but I seemed to have a mental blank at a critical moment. I had even written down the answer in my journal but failed to realise this until it was too late. From this I have learned that everything should be documented thoroughly and that you need to know absolutely everything about the equipment that you are using....
"I have found this project of the most rewarding and informative. The greatest joy came when we finally had everything configured properly with the rig designed to hold that are fully constructive. It was a great moment seen the system runs on having our first set of full data logged and being able to plot the results on a force and velocity plot, representing all the effort we had put in for the previous 10 weeks.
"Some of the basic concepts I have learned our basic control theory, shielding and protecting from electronic noise, learning how too code using the LabVIEW environment, and about time delays, obtaining data from sensors, limitations and problems with hardware and software, the difficulties of integrating both hardware and software together to develop a working system, working in a team with other mechatronics students, and working with other engineering disciplines. This was a great learning experience.
<list of topics at top of page>
"This project has taught me a lot. On nearly every project that you do their will always be an aspect of that you are unfamiliar with and you need to research it yourself to learn how to use it. This emphasises the importance of continuous self learning.
.. and consequences of insufficient knowledge .
"The initial plans, I believe, showed that all the group members had a lack of understanding of the lift system. To meet this was the driving force to attempt to build a proper understanding that would allow a good system specification to be made. Everyone had goals to work towards. I assigned tasks initially to try and get the other members to see how the lift work in the context of LabVIEW.
I obviously misjudged the team members reaction to this self learning. While I gave them a start as to what needed to be understood, they obviously never really sat down and made a valid attempt. Several times the same simple questions were asked, while each said they "sort of" knew the answer as to what was going on.
<list of topics at top of page>
"My involvement with this project has taught me a great deal. For one, it has restored my faith in working in teams again. This group work really well together and throughout the process, became friends. Secondly it gave me the opportunity to implement the lessons I have learned from my previous project experience. These lessons were to plan the project, to start early, to work together during regular scheduled sessions and not to become too dependent on other members.
.
"Over the course of this project, I have learned many valuable lessons, the least of which is the importance of strong leadership to guide, motivate, and generally bring the group together.
..... and when things don't work out as expected
.
"Being involved in this group project was a great learning experience for me. It reshaped my ideals on how hard leadership can be. To be honest I found leading this group one of the most challenging academic experiences I have had in a long time. Perhaps I went into this group a little overconfident about my own abilities in teambuilding, teamwork and leadership. I have been mentor to first-year university students for the past two years and I have been a youth leader at my local church for the past five years which seems to suggest that leading the group would be easy for me but it definitely was not.
.
"This project was very rewarding for me since it gave me a chance to develop leadership and communication skills with less experienced students. It gave me confidence that I can complete any project without the fear of not having enough technical information or intelligence. I believe that with good teamwork, group dynamics and research, all projects should be able to be completed with the utmost quality.
<list of topics at top of page>
"Both Richard and Chen had very poor communication skills; hence many group discussions were very unsuccessful. Earlier in the group's life I lost interest in trying to understand what some of them were trying to say and would give up. However I soon learned that if I didn't listen to their ideas, why should they listen to mine? After a bumpy start I practiced patience and made a conscious effort to try listening to them more and more in trying to understand what they were saying.
"Try to divide the work as equally as possible even if one person is a real expert who could do the whole thing just by himself. This is probably the biggest mistake that our group made. We assigned the whole of the coding of the lift controller to one person, thinking that he would be able to do it since he had very good programming skills. But things did not turn out as we expected. He could not finish the coding in time and he did not ask help.
"I learned a great deal from the project. Firstly that managing a project is never easy, and it really requires an understanding of who you are working with. There needs to be commitment by all group members -- otherwise there is the opportunity for "social loofing" where some people do not bother to help because other people appear to be capable.
"I think a major problem is that I had no real authority. I could not enforce others to do the work, but could only asked and try to lead by example. I think that possibly I should not have taken such a laid-back attitude and I should have actually demanded results. Because other team members did not come up with their part in the required time I saw that the need for excellent activity planning is important. A network diagram would have given us a better option and a better view of what was happening than against the Gannt chart that was used. It gives a more visual aspect to the task flow. This would also have helped with systematic design to ensure that knowledge of the hardware was available in time to specify the software properly. I now realise that we should have done this first because without this we have no way to properly design the software. Without this knowledge we could not do the testing properly.
Note: Engineers in most industrial situations seldom have real "authority" and evidence suggests that using authority to get results is seldom effective in the long run. Learning how to motivate people to do something is the more effective solution (JPT)
Figure out how you would overcome this problem if you saw it developing earlier in the project work
"The third progress report was done entirely by myself as everyone decided they had the excuse of having lots of other work to get done. Louis basically said that he had his thesis presentation to prepare. Although I was sympathetic to this he could have talked to me about the project. I had asked by the group members to do some testing but on the day before the progress report was due to be handed in I received e-mail is that they had not had time and needed some more help.
At this point I decided that there was no way the project was going to be close to finished if I did not try and do most of the work myself.... to be honest I had a good understanding of the lift by this stage and it did not take me long to get a sufficient working program running with minimal design changes to the state diagram.
I believe I functioned as best I could as the group leader under the circumstances. I arranged meetings and kept notes of progress issues, software problems and other agenda items discussed at meetings. The hardware timing was eventually attended by assignment that this was only in the last week of semester and I also have to explain to him what needed to be done. The other students in my group did not do enough work and left me with an overload of work. Richard gave the least contribution and was difficult to contact the best: his efforts were not up to an adequate standard. Lim gave the minimal effort possible to the project and I expected I would have to do most of his work. Wendy at least attempted most of the tasks that were set for her. She did struggle with LabVIEW and expected too much tutoring but was far more diligent than the other group members.
<list of topics at top of page>
"One aspect that I found unprofessional about our group was that we had a lot of time when we were wondering what to do. We should have made use of our time much more efficiently. Simply looking at others do their work is not productive at all.
... I now understand that you can't do everything by yourself in these big projects. The knowledge from the third-year students was invaluable to the group.
..
The hardest lessons, I think I learned, was that estimation of time to complete is never as you would expect. People generally take longer in learning something that you would expect. But once they have some understanding work proceeds much faster.
Keeping a lot of spare time aside for testing hardware and software is the most important aspect I have learned from this project. There will always be things that go wrong and other things that need to be changed. Finding out what went wrong, fixing it, and testing it again takes a huge amount of time. When everything was prepared for the demonstration the network went dead for a few days and during that time the field point unit was changed in the mechanical group changed the pump. After everything was up and running nothing worked and it took a whole day to fix up everything.
..
"I learned that planning is the most important part of the project, and that a high degree of organisation was very useful. Also that coming up with a solution was only part of the process. Often the first few ideas don't work, and much (time and) effort is needed to work out the kinks out of solutions that actually do seem to work.
I think that I have learned a lot by doing this project. Firstly, working in a group with people I didn't know before helps me with my communication skills, as we have to communicate ideas and learn new things. It also teaches me to be more responsible with my time management, as group needs should be prioritised rather than personal needs for most of the time.
..
"One of the major lessons I learned from this project was to allocate time for contingencies. There were many things which happened which was not expected and this made us change our plan repeatedly but it also prolonged the time allocated. If we had provided a reserved time for contingencies then we would have given a more accurate estimate to the client. It also meant that we would not be surprised or concerned if something did not work out since we can take the time spent from the reserve section of our project plan.
"From a generic point of view, I have learned three important lessons. The first is the importance of project planning. At the start of the robot project, the task at hand felt overwhelming, but a solid project plan for the group's mines at ease. I believe having a well laid out plan will be the critical factor for the success in my honours project.
<list of topics at top of page>
"Set a regular meeting time. We had scheduled times the meeting but we did not meet regularly.
"My experience on this project has been a positive and enlightening one. Having completed projects in the past where group members have not done the work, which consequently lead to a poor group performance, I was dreading this major group assignment. However, in completing this assignment my faith in group work has been renewed. I thought Ashley, Graham, Ben and myself worked well as a team. We started by sharing all our phone numbers and e-mail addresses which allowed us to reach each other at short notice and organise meetings conveniently. We all put in the work and if something needed to be done it was done on time and to a high quality. As a group we worked efficiently and always made the time to meet even though we had major timetable problems. The time was spent together was relaxed and friendly which helped in the functioning of a group. All these factors contributed to us completing a successful project.
..
"The project confirmed to me the importance of regular communication between group members. I put a lot of emphasis on regular e-mailing and having regular meetings. At these meetings we discussed both progress and problems and they were a good chance to get to know the rest of the team. Having group discussions about some of the specific problems we faced seemed to quickly resolve many of those problems which may not have been resolved individually without considerably more effort.
<list of topics at top of page>
"When creating or tackling and engineering project there certain procedures to be followed. Failing to follow these steps could prove costly later on.
Specification must be set before any work can begin. We must first analyse all data to determine the requirements for the project.
Planning, whether it is group or individual work, to set definite goals for each task.
Research and testing, every component will code must be tested under set conditions to see that it meet specifications set previously.
Construction must be on time yet not to be rushed because this is when mistakes are bound to happen. Set deadlines and do not exceed them if you can.
Problems and issues are bound to come up. The deal with them accordingly but consult with teammates and conduct more testing.
Documenting everything. This proves to be more useful than it sounds at first. Sketches and log books are very helpful when you need to retrace your steps after making a mistake.
<list of topics at top of page>
"Write everything, in full detail, in the diary. I described the work that I did in my diary but it was not detailed enough when I needed to remember it. I needed my diary records is much more than I thought I would.
"Keeping a log book was definitely very useful. Every time I had to look back and check something I could easily find it and fresh my memory on what I did that they. Similarly, when another group never wanted to find out how I got a particular result I only needed to look at my log book in the right place. My log book has saved me lots of valuable time on searching for things that I have already found. Especially at the demonstration when I was asked a question on the load cell that I had forgotten about.
.
I think the thing that I learned the most was that, like the guide said, writing everything down was the key. Things that I wrote down stayed clear, and once I got into the habit of documenting everything the process ran much smoother. In the beginning I didn't documenting everything, and by later on in the project I was greatly regretting it.
"Another key lesson to learn is the importance of documentation in software code. When we were sharing code between group members, it had to be documented appropriately so less time is wasted from reading the code and trying to understand what was happening. Documentation gradually became better as the project neared its completion and I believe that all group members would make documenting the habit for future software design.
"When creating or tackling and engineering project there certain procedures to be followed. Failing to follow these steps could prove costly later on
Documenting everything. This proves to be more useful than it sounds at first. Sketches and log books are very helpful when you need to retrace your steps after making a mistake.
.
"I now know that it is important for not only having documentation of everything project related but because you can jot down ideas and work things out and use them later as they are in one place. During this project I would write things down on scraps of paper I had handy and then often lose them or forget that I even wrote anything down etc. I am sure you know what I mean.
<list of topics at top of page>
"Searching for the right load cell was a very time-consuming job.
I send e-mail to the companies that have load cells that might have matched our requirements and had to wait for their replies. I had to correspond continuously with them to get them to send the specifications of their load cells and this took a long time because I always had to wait two or three days for their replies. After receiving specifications I finally chose the three companies that have the load cells that best fitted our requirements and I telephoned them to discuss the load cells. To my disappointment, one company said it would take six to eight weeks to ship the load cell since they were stocked only in America. The load cell from the second company that matched our requirements cost over $2000. The third company appeared to have the right product but the sales representative told me that it was only a compression load cell even though I had made it clear in my e-mail correspondence that we needed a tension and compression load cell. I felt that all my work was just a waste of time.
By the time our demonstration was getting pretty close I had no companies left to contact. We decided to purchase a standard load cell and asked our mechanical design colleagues to change the specifications of the rig to fit the load cell that we could purchase. I telephoned the supplier to make sure about the load cell and then they told us we needed an amplifier as well. I never thought that purchasing a simple piece of hardware would take as long as it did.
<list of topics at top of page>
"... I learned that you should never reject an idea simply because of one deficiency. You should always investigate any reason for rejecting an idea before moving on and if you do reject an idea, document the reasons. For example, in our project, we disregarded a particular design because we thought there would be too much friction without even trying to investigate lubrication options.
"It is interesting to analyse why we felt pressured into making important decisions rashly. First, we felt that important decisions that determine the path of the project needed to be made by the group as a whole. Second, there were not many times when all four of us could meet. Further, none of us had enough experience in the specific areas that this project required. Fourth, the passage of time and pressure we felt "to get a move on" so that we would have something to report in our progress reports. These factors combined to impose themselves on our otherwise rational approach.... I imagine that with experience will come the confidence to know intuitively which path to follow and which information is needed. Nevertheless, our mistakes in this project have talked me a lesson I think everyone needs to learn at some point: rational argument needs to be behind every important decisions, and if you cannot articulate your reasoning and you should not be making the decision at that time. Outside pressures will always be present but one must not be too swayed by them.
..
" .discussing problems with people not involved in the project can lead to new solutions you may not have previously thought of."
"The second lesson learned is the importance of systematic design. Not until it was pointed out in the group's demonstration had I realised that some of the decisions made had been done without logical thought. The repercussions of these decisions were quite obvious.
<list of topics at top of page>
"Another key learning experience that I will take away with is the absolute importance of coming up with very tight specifications to each module. This was something we did not do well, and it manifested itself in an overly (and possibly unnecessarily) long implementation time. When my turn comes to lead a group like this, I will do my utmost to stress the importance of very tight specifications that are finalised early on in the project.
..
I also learned the need for much better testing. I think that the test specifications should have been set up better and defined much further. It appears that they may also have been too broad when they should have said exactly which procedures are to be followed. I also learned that the reporting and documentation of testing should not be left up to individuals but should be required as a weekly check to ensure that work has been completed properly.
<list of topics at top of page>
"A great amount of time was spent over the course of the project finding simple errors in the code. The testing by Jenny and Chen turned up a number of problems that had to be traced right back through the code. This was made even more difficult as we could only display a limited number of outputs to the screen. As one error was found the code's variables that produced this error had to be displayed and if needs be the variables below this were displayed to find the error. In one case after some code had been documented two variables had been found to be swapped around. Initially this caused erratic behaviour of the motors where previously there had been none. We initially checked the output of the control to see what was causing the oscillations, as more and more variables were checked we found that the velocity of both back wheels was rising into the hundreds of thousands. This was traced right back to the encoder module where to variables had been swapped around ensuring the change in position of each wheel was growing with each call. These types of errors caused much frustration and the ability to gather all the code variables and display them on the computer in a table or something like that would have saved a lot of time. I learned the need for greater automatic error checking and recording and implementation of more robust code that couldn't accept values which were obviously well outside the desired ranges.
<list of topics at top of page>
"Managing a group project is not as easy as it looks. It requires good communication skills, leadership skills, and knowledge about what is going on. The project made me realise that I still need improvements on those areas mentioned above.
There was also trouble in the fact that some members could not be relied upon to come to scheduled group meetings. They claimed, through e-mail, that they were undertaking work on the project will stop often, through e-mail, questions were asked as to what they should do next -- this often needs a face-to-face explanation especially for assignment of module work.
.
"It is also very important to communicate and work with your other group members. There is no point in doing something yourself and finding out when you have finished that another group member has already done something completely different that makes your contribution useless. Interaction with other group members is crucial as it will make work easier and definitely cut down on waste of time.
..
The project confirmed to me the importance of regular communication between group members. I put a lot of emphasis on regular e-mailing and having regular meetings. At these meetings we discussed both progress and problems and they were a good chance to get to know the rest of the team. Having group discussions about some of the specific problems we faced seemed to quickly resolve many of those problems which may not have been resolved individually without considerably more effort.
..
" . Also I am confident my technical communication skills improved dramatically. I spent a lot of time trying to explain complex mathematical issues to the rest of the group, and I consistently had to make a conscious effort to explain my thoughts as concisely and simply as possible.
<list of topics at top of page>
"I also learned about mechanical design is especially with regards to rigidity and inverted pendulums. It is clear now that to improve balancing performance the centre of mass of the robot must be as high as possible. Also, it is clear now that rigidity can be significantly increased by using be shaped or U-shaped channel metal sheets rather than flat sheets. It is starting to realise how such simple mechanical designs can potentially improve the performance of the system.
<list of topics at top of page>
"The third lesson we learned from hindsight is the importance of simulation in control system design. The fundamental factor that affected the group's success was its ignorance of simulation.
<list of topics at top of page>
"Never trust what team members say without looking at the actual work. On one occasion I asked one of the group members if his code worked and he said yes, so I trusted him. But, when I tested the code a few days later, it did not work.
Test every module of code, every aspect of the design, as rigorously as possible as soon as it is completed. I realised that we did not do enough testing, otherwise we could have found out what was going wrong with the code. Also, our testing was towards the end of the project which turned out to be too late.
Keeping a lot of spare time aside for testing hardware and software is the most important aspect I have learned from this project. There will always be things that go wrong and other things that need to be changed. Finding out what went wrong, fixing it, and testing it again takes a huge amount of time. When everything was prepared for the demonstration the network went dead for a few days and during that time the field point unit was changed in the mechanical group changed the pump. After everything was up and running nothing worked and it took a whole day to fix up everything.