Enclosed: Proposal for Kayak Slalom Race Timing System

Size: px

Start display at page:

Download "Enclosed: Proposal for Kayak Slalom Race Timing System"

Jasmine Angelina Jackson
5 years ago
Views:

1 April 22, 2007 Lakshman One Simon Fraser University Burnaby, British Columbia V5A 1S6 RE: ENSC440 Postmortem for Kayak Slalom Race Timing System Dear Mr. One, Enclosed please find our ENSC440 Capstone Project Postmortem, which details our results and experiences through completing this project. Our objective was to design and build an automated kayak race timing system which can be installed on existing kayak race courses to eliminate the need for judges at each gate. ImuTime Systems is comprised of four innovative and driven engineering students Ashley Penna, Chris Munshaw, Kevin Lockwood, and John So. Each of these individuals brought a unique perspective and skill set to the ImuTime Systems team. If you have any questions or concerns regarding the attached document please feel free contact us by at ITS-ensc440@sfu.ca Sincerely, Kevin Lockwood President & Project Manager ImuTime Systems Enclosed: Proposal for Kayak Slalom Race Timing System

2 Post Mortem for Kayak Slalom Race Timing System Project Team: Contact Person: Submitted to: Kevin Lockwood Chris Munshaw John So Ashley Penna Chris Munshaw Steve Whitmore ENSC 305 Lucky One ENSC 440 School of Engineering Science Simon Fraser University Issued Date: April 22, 2007 Revision: 1.0

3 Executive Summary Whitewater kayak slalom racing began shortly before World War II as a branch of traditional whitewater canoe racing. This Olympic sport involves racers paddling down a natural or man-made river through hanging pairs of gates in a kayak, usually made of fiberglass or plastic. The racer must proceed through green gates in the down-river direction (see Figure 1), and red gates in the up-river direction. The overall time of the racer from start to finish is recorded, and time penalties are added for gates touched by the racer as well as missed gates. A judge watches each set of gates from the shoreline, recording time penalties for each racer that goes by. Human judging is an inefficient method that introduces a huge potential for human error. Figure 1: Slalom Kayak Racer Source: IOC Currently, each of the gates is individually manned. A judge determines if the kayaker passes through the each set of gates, as well as determining the time at the beginning and the end of the race. Using humans for this task is cumbersome, potentially inaccurate and expensive. ImuTime Systems (ITS) created an automated kayak race time system which tracks both a Kayaker s race time and the integrity of their gate maneuvers. This system was all wirelessly interfaced to our custom software which provided user interface and real-time race results. The results of our product paved the way for future more robust and dynamic systems which Imutime plan to build in the very near future. Our current product shows the integrity of the technology to track a kayaker s progress as well as detecting any contact made with the gates. The fidelity of our wireless data transmission also far surpassed expectations. We proposed that the research, design, and construction of this project to be completed an engineering prototype would encompass a 13-week period from January 8 th to April 6 th, The entire project is tentatively budgeted at $ CAD. Our final budget including used technology was $850. 1

4 Table of Contents Executive Summary... 1 Table of Contents... 2 List of Figures Introduction Current State of Prototype Deviations from Original Design and Specification IR Beam Presence Detection/Power Control Future Plans/Upgrades Budget and Time Inter-personal and Technical Experiences Ashley Penna Chris Munshaw John So Kevin Lockwood List of Figures Figure 1: Slalom Kayak Racer Source: IOC... 1 Figure 2: Slalom Kayak Race Timing System Overview... 3 Figure 3: Presence Detection... 4 Figure 4: IR Beam... 4 Figure 5: Wireless Data Communication System... 5 Figure 6: Software User Interface... 5 Figure 7: Presence Detection Future Upgrade

1 Introduction ImuTime Systems (ITS) consists of four engineering students whose collective experience and knowledge in hardware and software design combine to create a truly unique product.

5 1 Introduction ImuTime Systems (ITS) consists of four engineering students whose collective experience and knowledge in hardware and software design combine to create a truly unique product. Planning and high level design began on Jan 19, 2007 and completion of the first prototype on April 16 th, We began with several possible design solutions. We investigated each solution diligently and only eliminated alternatives due to cost or physical constraints. There was never any pressure due to time to pick the easiest solution. This document describes the Kayak Slalom Race Timing solution chosen and outlines why it was chosen and what we learnt. 2 Current State of Prototype The follow section details our current prototype for a Kayak Slalom Race Timing System. Below is an overview of the system as a sum of its parts. Figure 2: Slalom Kayak Race Timing System Overview As a Kayaker approaches a gate, his/her presence is detected by Ultrasonic range finding sensors. 3

Figure 3: Presence Detection This triggers the higher power consuming IR lasers to turn on.

When these beams are both broken at the same time by the kayaker then reestablished, this signifies a

Figure 4: IR Beam There are an accelerometer mounted in the gate which is set to filter out ambient forces

6 Figure 3: Presence Detection This triggers the higher power consuming IR lasers to turn on. These lasers create two parallel beams across the gates. When these beams are both broken at the same time by the kayaker then reestablished, this signifies a passes gate. Figure 4: IR Beam There are an accelerometer mounted in the gate which is set to filter out ambient forces on the gates such as wind and water splashes. It triggers when the kayaker touches gates, with remarkable sensitivity. Once an event occurs on the gate; either passing through the IR beams, or triggering the accelerometers, this data with then transmitted wirelessly 4

7 through our Zigbee Xbee RF modules. These modules currently have a maximum range of 30m, but do have an upgraded version with a 1m range. Figure 5: Wireless Data Communication System This data is received by a receiving RF module which connects directly to a laptop which contains our running software. Figure 6: Software User Interface 5

8 3 Deviations from Original Design and Specification Due to the extent that each technology was investigated there was no one original design. Therefore this section will compare the final design to the one it most resembles from our Design Specification document. 3.1 IR Beam Originally we had only planned to have one IR beam across the gates. This was until we realized however easy it would be to fool this system by simply placing a paddle through the gate to break the IR beam. Therefore we used two beams 8 apart on the gates. 3.2 Presence Detection/Power Control Presence detection was something that was not ever though of as a possible design in our original planning. When it was first conceived its main purpose was to determine that the kayakers had approached the gate from the correct direction (recall gates are unidirectional according to kayaking race rules). Figure 7: Presence Detection Future Upgrade However since we were using ultrasonic sensors for this application, interference between the sensors quickly became problematic. Due to time constraints, there was no time to try and investigate into an alternate technology. At this same time the power board was being designed. It was noted that the IR sensors consume many times more power (amphours) then any other component in the system. Therefore only one ultrasonic sensor was used for presence detection, and simply acted as a trigger to turn on the IR sensors. 6

9 4 Future Plans/Upgrades Throughout this project many constraints were present. These constraints hindered some of the advances in technology for the system. Our prototype is not yet ready to be used by the Kayak Racing market, as we have not subjected it to stress/reliability testing. This section will detail our future plans to upgrade our product for market use. Currently there is no sensing on the gates which determines whether the kayaker approached the gates from the correct direction. In future, our presence detecting ultrasonic sensor would the replaced by two sensors. These should have no interferences and allow us to correctly monitor the direction of approach. As a side note this would also allow us to detect if the kayaker maneuvered correct between the gates or did an Eskimo roll (when the kayaker rotates his body underwater). These sensors would also trigger the power board was well. Our RF modules have a range of up to 30m, which can be slightly increased outdoors with less line-of-sight- obstructions, and using a higher gain antenna. However a simpler solution is to employ upgraded modules with a 1m range (Xbee Pro). Circuit board can be greatly reduced in size by designing then on PCB boards. Also a cost reduction redesign of the entire system would also cut size and costs as well. Lastly wireless communication, as of April 17, 2007, is only unidirectional (sent by gates to the laptop module). In future bidirectional communication will be made possible to allow from remote power monitoring, calibration and turn on/off. As a consequence a lot of the hardware filtering that is currently present will be moved to firmware. This avoids changes in component values over time, and allows to remote calibration to take place. 5 Budget and Time Our project was completely funded by Michael Necklar, owner and president of Necky Kayaks. He is heavily involved with all BC whitewater kayaking events. Our initial budget proposal was for a total cost of $1060 for one prototype. We were able to complete three working prototypes for $850, well below initial projections. These costs include a lot of unused technology and part. After a cost reduction design, we estimate a cost per unit of approximately $200. Many of the upgrades mentioned in the previous section could have been easily completed given more time. Unfortunately an early demo date had to be chosen to accommodate everyone in the group. A later demo date would have produced a more developed product. However the main components of the system were demonstrated to function as expected and well enough to foresee real world use in the future. 7

10 6 Inter-personal and Technical Experiences 6.1 Ashley Penna One of our first main tasks in this course was dividing up the tasks. Since I was the member of the group that was the most familiar with microcontrollers, I was the one selected for this task. Initial considerations such as the type of microcontroller, possible development board(s), and whether or not to use a boot loader were considered. These paths were all developed in parallel; each providing its own challenges to be overcome. Also, since the microcontroller had to be the central hub between most of the other systems, (RF, sensors, accelerometer, ultrasonic), I had to be constantly updating my firmware and figuring out was system design flow would be best in each individual system, and as a whole. Integration of the system proved to be the most challenging part. Throughout the semester, I learned that a project like this is extremely hard to have everyone ready for integration at the same time. Also, I learned that when integrating with different hardware technologies, the firmware has to be able and willing to adjust as the hardware is optimized and evolves. It was a valuable experience to be able to integrate with all of these technologies, as I learned a great deal about each one of them individually. One improvement that in retrospect I would have liked to see in our group is for us to do more integration separately, amongst smaller parts of the project so that we had more of a branching tree effect rather than a straight line where we followed the signal from beginning to end. This could have possibly prevented a few all-nighters. Since this is an ongoing project, building these three gates is just the beginning. We have tried out numerous technologies, but as suggested, there might be other factors we should also consider. As this system is refined though feedback such as that provided at our presentation, we hope to be able to produce a marketable product. Overall, our group functioned well together, each excelling in our own areas of expertise. Our personalities worked well for the organization of our project and group. This was a valuable team project experience, as well as an enjoyable one. 6.2 Chris Munshaw I came into this course being the only person in my group having taken ENSC 387: Sensors and Actuators. For this reason, we decided that it was logical for me to begin by working on the sensors portion of our project. I quickly learned however, that there is a lot more required than just an understanding of the concepts behind different sensors to make a project successful. I found myself searching for as many opinions as possible from experience engineers on topics such as optical technologies and signal conditioning. I also found that there were many factors I had never considered before when designing circuits: can the circuit be powered by batteries, how much PCB real-estate is this 8

11 component going to use, and how much money is this going to cost. These factors made design a much more complicated task, not to mention the fact that other parts of the project were waiting on the completion of my designs. This leads me into my next topic: integration. I learned the importance of constant communication between people working on different parts of a project. If one component falls behind, there are things that the other parts can do to avoid wasting time in waiting for that person. Integration with software was a large portion of our project but could not be tested realistically without a working set of gates. This made for a couple late nights near the end of the semester, but John really pulled through in that he had everything ready to be debugged as soon as we had finished building the gates. It may have saved time to have a method of simulating gate messages without having the gates completed, and this would have allowed for debugging to begin earlier. Finally, some of the most valuable things I learned came in the form of feedback after our presentation. Since we plan on continuing this project until we have a strong, robust product ready to market, there is still work to be done over the summer. The feedback from the course instructors and TA s was extremely valuable in that it gave us direction for our next steps from here. The feedback helped us identify any major weaknesses in the project, as well as devise a plan for future testing when the time comes. All in all I had a very positive experience working with the other members of this group. I felt we got along very well and our different skills/personalities suited the type of team dynamics we created at the start of the semester. I would be happy to work with them on future projects. 6.3 John So At the beginning I did not have high hopes. My friends decided not to take ENSC 440/305 this semester, and consequently I had to join a group of three, whom I never knew before. The group turned out to be better than I could ask for. Our first official meeting, like many meetings after, turned out to be communicative and well-prepared. Each member presented the task he or she had worked on, and then questions and discussions followed. Typically a meeting would not last over 30 minutes. Throughout the four months we managed to keep the good team dynamic and energy. An even share of work, encouraging words from group members and good organization are especially important to keep the group spirit up. For the technical side, the main skill earned from this project would be Visual Basic (VB) programming language and graphical user interface (GUI) design. I also learned about wireless communication and hardware-to-software communication. The greatest lesson learned was to have a clear, detailed, and definite goal before actually start designing. I did not enjoy writing the function spec and design spec, but they became valuable when I was designing the GUI. Seeking advice from potential user proved essential as well 9

12 because he knows exactly what functions should be included. But even with such preparations, I had to modify the design multiple times as the project progressed. Integration of software and hardware was my greatest worry. The gates were not ready for testing until the very last week, at which time I had performed very little testing on the software. With theoretically-correct codes and some luck, the integration proved smoother than anticipated, as the software could read from RF receiver correctly at the beginning of integration. I think I should have tested serial communication more thoroughly and confirmed the message format earlier. A regret I have is that I did not provide much help to other group members, and instead limited myself to work on software part only. The software development was not very technically challenging, and I ended up wasting valuable time while waiting other parts of the project to complete. I could have utilized the time to help my partners. 6.4 Kevin Lockwood Having completed two major individual projects in Co-op, I felt I had a good understand of the time requirements going into Ensc440. I quickly realized how time management changes when projects are done in groups. I took it upon myself to be the group leader for task delegation and planning. I do feel my Co-op experience was beneficial in planning for yet unseen complication that were to arise in both development and integration. I have always had a keen yet somewhat timid affiliation with wireless communication. It is definitely a technologies that I will be faced with at some point in my future career, and felt that I should take it upon myself to learn. Therefore I was responsible for choosing, calibrating and build interface boards. Also having done two Co-op with power electronic companies I felt it was natural that I build the power board for the system. I felt I ve learned a lot of wireless communication protocols and conventions. I am also very happy to have successfully built the controllable power supply. It was the first circuit I had ever designed using transistors. I cannot express how happy I am with how the well the delegation of work and fairly seamless integration too place. I could not be happier with our finished product and am truly proud of each member of the group and their great contributions and accomplishments. 10

January 21, Lakshman One Simon Fraser University Burnaby, British Columbia V5A 1S6. RE: ENSC440 Slalom Race Organizer. Dear Mr.

January 21, Lakshman One Simon Fraser University Burnaby, British Columbia V5A 1S6. RE: ENSC440 Slalom Race Organizer. Dear Mr. January 21, 2007 Lakshman One Simon Fraser University Burnaby, British Columbia V5A 1S6 RE: ENSC440 Slalom Race Organizer Dear Mr. One, Enclosed please find our ENSC440 Capstone Project Proposal. Our objective