Proceedings - EDGE



Project Number: 05511

STONEHURST REGATTA RACE TIMING SYSTEM

|Douglas A. Carr / Mechanical Engineering |Robert Magnant / Electrical Engineering |

|Jeffrey Lisco / Electrical Engineering |Juan Gonzales / Electrical Engineering |Jacob Johnson / Computer Engineering |

Abstract

This papers summarizes the efforts of Senior Design Team 05-5511 to develop a system capable of eliminating race timing errors that were occurring at the Stonehurst Regatta crew race in Rochester, NY. The team has developed a system to electronically collect, organize and transmit boat numbers and corresponding race times from the collection points at the start and finish lines to the final processing location at the “results booth.” The paper documents design considerations as well as the final implementation

introduction

The Stonehurst Capital Invitational Regatta is an annual fall crew race occurring on the Genesee River in Rochester, NY. Teams of boats from around the northeast United States and Canada gather at this unique race in the rowing world to compete in two separate events throughout the day, a long, endurance style “head race” in the morning and a shorter, more exciting head-to-head style “sprint race” in the afternoon. Times from each event are combined and awards are given based on the overall performance for the day.

In the past results collection has been performed using a printing stopwatch from Seiko® for start and finish line times, and a pen and paper for corresponding boat numbers. This method worked extremely well for collecting data, but results were then transmitted to the results booth at the boat launch site by verbally reading via a cell phone to a person entering data on a laptop. Since the volunteers performing this task are under pressure to publish these results quickly (so that trophies can be awarded in a timely fashion,) mistakes have occurred during the transcription process, which were not caught until after the awards had been given out. This has led to the post-race retraction of some awards, which is both frustrating for the competitors and embarrassing for the race officials.

The objective of this RIT Senior Design project was to create and implement a system or method for alleviating the problems occurring during data transcription. The project sponsor desired that the solution be user friendly and robust, since the race volunteers come from varied, often non-technical backgrounds, and also that it integrate easily into the current system without impairing the current functionality, so that a backup system is readily available. The team was given $500 to design and build a fully functioning system to be implemented in the next race in October, 2005.

Nomenclature

GUI – Graphical User Interface

RFID – Radio Frequency Identification

RS232 – Serial data communication standard

RTC – Real Time Clock

Project Requirements

Several key parameters define the design requirements of this project. The system must fix the problem, be simple to use, reliable and robust enough to survive in a wide variety of usage environments. These objectives must also be completed on time and within budget. A more detailed look at each of these parameters follows:

Addresses data entry problems:

The major function of the prototype will be to remove the process of manual data entry (i.e. keying in results being read over the phone) while transcribing the data from collection points (i.e. the start and finish lines), to the results booth. According to the project sponsor, in the past this step has been the most subject to human error, while other aspects of the current method have proven themselves rather reliable.

Ease of use:

A major point of emphasis is that the final product should be simple to operate and generally easy to use. The people that run the timers during the race are typically volunteers from the Rochester community who are trained at the race site, on the day of the race, and often have little or no technical background. Even technically savvy and experienced timing personnel only participate in the system once a year, so any user interface should be intuitive and uncomplicated.

The design should display the results quickly so that users can visually verify the data, and they should also have the ability to delete accidentally recorded results. The design should have visual user feedback (e.g. an “On” light) so that it can quickly be verified that the system is properly functioning. Any third party software should be common and familiar, and any Graphical User Interface (GUI) should have familiar feeling functionality to the average computer user.

Reliability:

The design should take as much user error out of the picture as possible. The final design must be reliable, as this competition is a large, chaotic event with several hundred teams competing and many thousands of people watching. Initially the new system will be implemented with the intention that the current stopwatch and cell phone system will be readily available should anything unexpected happen. If the design proves reliable, then it will become the primary system; however, the design should allow for reversion to the old method in any case.

Accuracy:

Discussion with the project sponsor revealed that the results are currently recorded and published to an accuracy of 0.1 seconds. These results are accepted as accurate, including any inconsistencies due to human involvement in collecting results. 0.1 seconds is a standard in the collegiate regatta world that is generally accepted and has been achieved in past years through the use of printing stopwatches, which record times to .01 seconds. Any delay caused by our system should not jeopardize the 0.1-second accuracy of the results.

Also to be considered in this category is the fact that multiple boats will be crossing the lines in close proximity to one another. Though the starting line in closely controlled, throughout the course of the race boats can overtake one another, which means that several boats could reach the finish at nearly the same time. The finish line is approximately 100-ft (30.5-m) wide, and boats with oars fully extended can be 20-30 feet wide, so the system needs to be able to record as many as three results in extremely rapid succession while maintaining the 0.1 second accuracy.

The project sponsor also stipulated that the results recorded by the system should be confirmable, such that they can be checked for accuracy at a later time. This can be achieved if the printing stopwatches continue to function in parallel with the design, since they create a hard copy of the data which can then be used to verify the electronic records.

Survivability:

The Stonehurst Regatta takes place in October on the Genesee River, so weather is a serious concern in any design. We have set design goals in this regard to attempt to encompass all possible conditions. The design should be able to function properly in temperatures from -10 to 40 degrees Celsius (15-100 (F.) It should also be able to function in wind, rain, snow, bright sun, humidity or any other weather conditions common to Rochester, NY.

Durability:

The system should be physically strong and durable. It will be carried around by hand and used outside so an impact from a drop or bump will not be uncommon. This means that any materials selected should be strong but also impact resistant, as well as water resistant and thermally stable.

Budget:

The budget for this project is $500, which places constraints on how much can be done. For instance, it would not be possible to create a system that would identify the boats and take the times automatically without any human involvement, which was one of our initial design ideas.

Integration:

It is desirable that the system that we design integrates seamlessly into the current system, so that the printing stopwatches can continue to be used as a backup. The project should take simplicity of integration into account so that should any future improvements to the system be desired, they could be performed easily.

initial design

The initial concept was developed without direct knowledge of the project budget, and was considered to be an optimal design. The concept was an attempt to completely eliminate human interaction in the data collection by implementing an automated method of identifying each boat and recording each boat’s time via Radio Frequency Identification (RFID) technology. RFID technology is in fairly common use, and generally consists of a passive transponder, which is be powered and subsequently activated by passing through an electromagnetic field. Once activated the tag emits a unique radio signal that can be detected by a nearby antennae. Common applications include anit theft devices in retail stores, vehicle identification in automated highway toll booths, and very similar application for tracking large marathon results that involves attaching a small tag to the shoe of each runner.

[pic]

Figure 1 - Bow Ball

The design called for securing one of these RFID tags to the tip of the bow of each individual boat by embedding it in a plastic device that would fit over the boat’s “bow ball.” (Figure 1) An emitter antenna would be either draped over the top of the start/finish line or secured beneath the water, and would trigger the tags as the boats crossed the line. A nearby receiver antenna would then detect the output signal from the tag and activate a stopwatch device what would electronically store the time in a data buffer. Times would then transmitted automatically by a wireless method to the results office where they would be stored on a program on a laptop computer.

[pic]

Figure 2 - Initial Design Process Flow

While this completely automated design would have been an optimal solution, our order of magnitude cost estimate for the design exceeded $2000, due to high part volume (1 tag per boat over 100 or more boats) and expensive antennae technology. Though one of our options according to the project definition at the time was to build and test a simplified prototype and not a fully functional system, the team’s personal goals included fixing the problem in a timely a manner.

Once the details of our budget were ascertained, it became clear that we would not be able to construct a completely functional system for the race in 2005, nor did it seem likely that the funds could be easily secured to complete the system at a later date. Based on this reasoning, the design was deemed not feasible and thus a simpler design was developed with a narrower scope.

Final Design

Given the cost constraint, it was determined that the most feasible plan for creating a reliable system would be to find a way to integrate into the current system in such a way that the results from the current would be captured electronically. This means that the device needs to interface with the Seiko® S129 printing stopwatches, which are currently used to record results, both to trigger the stopwatch to print, and record a time electronically in parallel. The concept that has been developed around this framework is to build a centralized platform that would integrate the following devices and features together into a cohesive system.

Stopwatch:

The current system uses a Seiko® S129 stopwatch (Figure 3) to record each boat’s time. It is desirable to keep this current system functioning because of its reliability. The stopwatch system has proven its ability to capture the race time accurately, with only one boat in many years not having its time properly recorded by a volunteer with a stopwatch. The team’s first idea was to attempt to utilize the “data output jack” found on the bottom of the stopwatches to obtain the race results. This proved to be impractical upon further research because the six-pin connector is an extremely non-standard design, which also happens to be Seiko proprietary and not readily available or easy to imitate. The Seiko cable needed to access this jack has never been sold on the U.S. market, and the stopwatches do not appear to be compatible with any standard software or data standards such as RS-232.

[pic]

Figure 3 - S129 Printing Stopwatch

A second possibility was to utilize the stopwatch’s remote triggering capability to activate each start/stop and capture the time using a separate device triggered in parallel, since receiving the time data from the stopwatch is not an option. The remote trigger works through another simpler connector, also found on the bottom of the stopwatch. When a button is pressed on a pistol-grip type handle, the two pins in the connector are shorted together, which has the same effect as hitting the stopwatch button to record a time.

Real-Time Clock:

The project requires that there be a universal time so that each boat will receive a time from the same clock. It was decided that a Real Time Clock (RTC) module could provide the project with the necessary universal time and accuracy to record each race result. Each RTC would be synchronized before the start of the race, both between units (i.e. start and finish line devices) and with the stopwatch, so that all timekeeping devices will display the same time throughout the course of the day. This can be easily accomplished using a built in reset feature on the RTC and by taking advantage of the fact that the stopwatch start can be triggered simply by mimicking the signal created by an event (i.e. triggering the device via the connector in the bottom.) When a boat crosses a start or finish line, the time from the RTC can be recorded and since the times at the start and finish line are synchronized, a simple subtraction of times from the start clock and finish clock is all that is required to obtain the total course time.

PIC Micro Controller:

In order to handle signals between the trigger, stopwatch, RTC, memory storage, and communication to a laptop a PIC micro controller will be used. The PIC will receive a signal equivalent to the command “get a time” from the operator when a boat crosses the start or finish line. It will then proceed to interface with the RTC and retrieve a time, then send that information to the data handling program.

RS232 Communication Chip

Once the data is retrieved from the RTC it will need to be exported out of the unit to a program running on a laptop computer. RS232 serial data communication standard is mature, well developed method for doing this, and prefabricated microchips are available at low cost which communicate across nine-pin RS232 ports in a standard fashion. The PIC controller will activate the RS232 chip and communicate the data to it for transfer.

Data Collection Program

The system will be connected via 9-pin RS232 ports to a nearby laptop, which will have a data collection program running to handle the times. The data will be displayed in the order in which it is received, and a parallel list of corresponding boat numbers will also be displayed. These numbers will also need to be inputted directly by the person operating the program.

Keypad:

To keep track of boat numbers, the existing system involves having another volunteer writing down boat numbers using a pen and paper as boats cross the finish line. Though this method works well in the current system, in order to make the data from the RTC meaningful, the finishing order will be included in parallel with each result. Boat number data will be entered through a custom GUI in our data collection program, and will displayed in parallel to the corresponding boat times.

Wireless Data Transfer:

The laptops connected to each unit will be wirelessly connected to the internet using commonly available technology such as PCI Modem over cellular network. When the operator indicates that it is time to send results, the program will automatically connect to a website and upload a formatted results file with times and corresponding boat numbers to a remote web page. These results will then be openly available for download by another person or program in the results booth were they can be handles electronically (i.e. cut and pasted) into the current data handling program, which performs the necessary math and allows for input of other information such as faults.

Visual Confirmation (LED’s):

One of the requirements is to have visual confirmation that the system is functioning correctly. Three LED’s will be employed in the design: one to indicate when the power is on, one to flash when the trigger is activated and a time is captured, and one to indicate that the system has been synchronized.

Implimentation & process flow

Upon power up the unit will initialize all variables and set up the communication with the laptop via RS232. The user will have feedback that the unit powered up via a labeled LED. When this is completed the system will wait for an interrupt verifying that it has been synchronized. This is very important because all real time clocks (RTC) must have the same global time in order to do accurate calculations. The synchronization is easy accomplished and is done with a simple button that will reset all RTC’s. Once this is done an LED with be lit up showing the user that the synchronizing is complete. The system is now ready for collecting times.

The user will push a trigger button to acquire a time. The boat numbers are taken care of using a graphical user interface (GUI) based program on the laptop. When a trigger is pressed the system will write a command to the RTC which will read a time back. The system will then write that time to the RS232 port of the laptop for interfacing with the GUI program. While this is being completed an LED will flash showing the user that the trigger has been recognized. The system will not handle any additional trigger presses while this is occurring; however, this delay won’t cause any problems because of how fast the program can complete the read and write of the time, on the order of micro seconds.

[pic]

Figure 4 - Hardware Layout

To accomplish the functionality described above, custom hardware was developed. A PIC micro controller from Microchip(, the PIC16F628, is used to control the system. It handles all interrupts and controls the outputs. The RTC is a DS1391 from Dallas Semiconductor, and was chosen because it exceeded the requirement of 0.1 second accuracy and for its ability to interface easily with the PIC and any memory element if needed. In order to interface with the laptop via RS232 an additional integrated circuit (IC) was needed. We used the DS232, also from Dallas Semiconductor(, for this function. A custom build PCB or printed circuit board has been designed in Orcad’s package using the Capture, Layout, and GerbTool programs.

On the laptop side, a standalone computer program has been written to handle the time and boat number information, and then export the data file to the internet. The software will create a list of the boat numbers and corresponding times in a format that can be easily read at the results booth in order to compute the results for each boat. Each program (one at the start line and one at the finish line) submits results to an on-line website so that the program running in the results booth can download them and calculate the results.

The program used to create this software is Qt Designer, which is a graphical user interface (GUI) program that uses C++. The version that was used was a non-commercial version of the software, which allows the programmer to freely distribute the software created so long as it is open-source. This program allows the programmer to lay out “widgets” however he wants and to specify the connections and functions that correspond to each widget. A widget is any object that can be seen in the GUI such as a button, text-box, or even the main window itself.

The program at the start and finish lines are to take boat numbers inputs from the user and list them in a text file alongside the boat times. “Listbox” widgets are used to display these inputs. Listboxes are widgets that arrange information in a single column. They can take in a variety of inputs such as integers or strings. The inputs for the boat numbers are typed into individual text editor widgets on the screen, which only accept three digit numbers, and then display them in the listbox. All of these connections are made in the Qt Designer program. The time inputs are read in from a text file created by the hardware and then displayed in a listbox. This listbox updates frequently to show the viewer any new times that have been taken.

[pic]

Figure 5 - GUI

Originally, the start and finish programs saved each individual listbox separately as a text file. This would make four text files, two for the boat numbers of each lane and two for the corresponding times; however, it was much simpler to combine all the information into one text file, thus making it easier and quicker to upload and download. Since lane designation (in the case of the afternoon race where there are two “lanes” for side by side boats) is for viewer purposes only, it does not matter if the times and numbers were combined into one list as long as the boat number is matched up properly with its corresponding time.

The next issue was to come up with a way to upload these files to a website. Originally, the program implemented an FTP (file transfer protocol) option built into the program itself. However, this involved the use of a second, more complex programming language, which was not very feasible because the programmer was unfamiliar with the tool. To solve this problem, another program was utilized which was included with the Qt Designer program and was easily integrated into the race programs. This FTP program is free to use and distribute as so long as no profit is made off of the program.

The FTP program has simple functionally, with one button to upload, one to download, one to connect, and finally one to erase files. The race program contains a menu which when clicked externally loads the FTP program and allows the user to upload the information to the FTP website.

Once the files have been uploaded to a website, a program that operates in the results booth must be created to download these files and combine them into useable readout. This results program will use the same FTP interface for downloading the files. Once the files are downloaded, the program must distinguish between the times and the boat numbers and then display them in order for final computation of the results. At the press of a button, the user can tell the program to compute all available times for each boat. These results are displayed in a separate listbox. These results can also be saved to a separate text file on the desktop of the results booth computer in order for further manipulation and transfer, should the user desire it.

Conclusions

At the end of spring quarter 2004-05, the team will have completed construction and implementation of a working system that will be capable of alleviating the data transmission errors for the Stonehurst Regatta. We hope to see the system implemented during the next race, which will occur in October of 2005. The team encountered several hurdles over the course of the year and would like to share some lessons learned with future generations of Senior Design teams to follow.

Firstly, it is very important that all the crucial information about the nature of your project should be collected as soon as possible, and included in this list should be your budget. Our budget was not explicitly stated in the project description, and we did not gain access to this information until nearly half way through Senior Design 1, at which point we had to make significant changes to the design in order to meet budgetary constraints.

Also, it is very important that teams get their hands on any crucial hardware as early as possible, as often there will be constraints in the physical implementation itself that wont be apparent until you have your hardware in hand. In our case this occurred when were given access to one of the stopwatches that have been used for the race timing in the past. We discovered that some critical assumptions we made about the nature of layout of the device and its connectors, based on the users manual, were faulty and we had to make some significant design changes again. In general this is important, as other teams have run up against problems with everything from motors to motor controllers to bearings to microchips. Having the parts in hand is invaluable.

Acknowledgments

The team would like to acknowledge our project sponsor, Mr. John Bowen, who has been volunteering at the Stonehurst Regatta coordinating the timing effort for a number of years, and was the driving force behind the project. We would also like to acknowledge Dr. Dan Phillips, Professor Paul Garsin, and Mr. Jim Steffano of RIT’s Electrical Engineering department for their expertise and advising, as well as Professor Paul Stiebitz and Mrs. Chris Fisher for helping our purchasing and manufacturing effort run as smoothly as it has. Dave Hathaway, Steve Kosciol and Rob in the Mechanical Engineering machine shop also played a critical role in helping take this project from ideas on paper to a reality; they have our heartfelt thanks.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download