Life Before the World Bank: Creating ROMDAS

In March 2020 we had a reunion in Auckland of my old team who worked with me during the first 35 years of my career. It was a real blessing and honour for everyone to be together again and lots of lost memories were shared. It was suggested that I should document the history of ROMDAS over its inception until I joined the World Bank in 2003. So this is my attempt at telling the story of a small but very talented team who developed a great solution to collecting and managing data on roads, at the same time indulging our inquisitive natures and having fun. I used the Covid-19 lockdown for a walk down memory lane—warning: it’s a long post!

Nabin Pradhan, Paul Hunter, Chris Bennett and Zuwei Deng

The evolution of ROMDAS can best be summarized through the figures below. We went from a simple device connecting a single roughness meter to a hand held or personal computer, to a comprehensive integrated system collecting data on the full range of essential road attributes.

1990 – 95	2003

In the Beginning …

ROMDAS started because I was doing my PhD in Civil Engineering at the University of Auckland and needed to earn some money. It grew because it filled an important gap in data collection technologies during the 1990s-2000s. It continues 30 years on because it has adapted and continues to meet the needs of traffic and highway engineers for reliable and affordable data.

Let’s start with the name. ROMDAS is an acronym for ‘ROad Measurement Data Acquisition System’. At the time of its development my PhD research was measuring speeds on two-lane highways. I had a data logger produced by the Australian Road Research Board called VDDAS (Vehicle Detector Data Acquisition System) and I couldn’t be bothered to be more creative. Who cares about branding? Typical engineer.

The story of ROMDAS starts with road roughness. Roughness is a key determinant of road performance and there were an array of instruments available for measuring it, as well as calibration devices. These ranged from dedicated sophisticated vehicles with major computers, to trailers, to vehicle mounted ‘Response Type Roughness Meters’ which measured the relative displacement of the vehicle chassis to an axle. Below is an example of the TRL Bump Integrator which was manufactured by CNS Farnell Ltd. of the UK[2], and a figure of how they operated[3].

Australia developed the NAASRA meter [4].

These RTRMS had manual counters, such as the one below which was produced by CNS Farnell to be used with the TRL bump integrator[5]. A separate trip meter was used to record the distance travelled along the road and every kilometre they would move the toggle switch from A to B. This would freeze the count in A which would then be re-zeroed for starting again after the B count was completed. The operator would write down the roughness each kilometre. This approach has many issues—including the time in one country where the people had a broken meter and wrote the numbers 0 for the entire survey (truthfully). You had to travel at a constant speed, as there was no speed data, and the data were presented on 1 km sections.

In 1989 the New Zealand consulting firm BECA procured a NAASRA meter [6]. I was working with them part time while doing my PhD and found the recording system to not only be inefficient, but also that it would not provide the granularity that we wanted to make management decision for shorter sections of pavements.

At this time, digital technologies were nascent so there were not a lot of options available for recording the data automatically. With the help of Garry Carr—my PhD technician—he came up with a simple optical transducer which replaced the mechanical transducer on the NAASRA meter. This produced a serial output which had 36 pulses per revolution, and it was also connected to the trip meter. But our challenge was how to flexibly record the data. Enter the Psion LZ64.

The PSION LZ64 was cutting edge in the late 1980s. It had the ‘Organiser Programing Language’ (OPL) which was a lot like Basic. This made it viable to act as an integrated data logger for the NAASRA meter, when connected through its proprietary RS232 port. A local PSION programmer Gavin Murray did the programming for us.

This system worked reliably for BECA for a number of years, and the first four ROMDAS systems used the LZ64 for data logging.

In 1989 I also began working part-time in Asia and was introduced to the TRL Bump Integrator where the Thailand Department of Highways were using the CNS Farnell manual system above to survey over 25,000 km of highways a year. Gary and Gavin adapted the system to work with the TRL Bump Integrator and it was rolled out in 1990. This was the start of commercial ROMDAS, and I used it in Thailand and also Nepal where I was doing feasibility studies.

The evolution of ROMDAS had several phases:

• 1991 – 1993: ROMDAS was ported to a personal computer and developed into a system which would record roughness, enter visual condition data or inventory, with a robust location referencing system.
• 1994 – 2000: Commercialization where we developed ROMDAS into comprehensive solution.
• 2001 – 2003: Porting the system to Windows and introducing the laser profilometer.

The company grew over time. You can see from the number of units supplied over the first ten years that it was initially a hobby with only five units, but then by the late 1990s as we began to focus on improving the system and adding features that were requested by our users.

In October 2003 I joined the World Bank and moved to Washington D.C. from New Zealand, so my direct involvement with ROMDAS ended. Paul and Raj Mallela who took over still run the company today.

1991 – 1993: A Side Hobby

In 1991 Mike Riley was working on a project in Pakistan and encouraged me to port the system to a notebook computer running MS-DOS. He wanted two major features integrated into ROMDAS: (i) keyboard rating of pavement condition and roadside features; and, (ii) a solid location referencing system which allowed the surveyors to enter location reference points (LRPs) and measure the distance relative to the LRP as opposed continuously from the start. It was feedback and feature requests like Mike’s that helped refine the system and make it useable: a practice that continues to this day. He also requested that we put in a software based dual trip meter which meant that ROMDAS would completely replace the stand alone trip meters.

The MS-DOS version was released in 1991, coded in Clipper by Gavin Murray. Paul Hunter eventually took over the programing. Gary Carr still built the hardware in his spare time. We began to sell quite a few systems to use with the TRL Bump Integrator, but it wasn’t so much a business but a way of financing my PhD—and giving me the data I needed for my consulting projects.

Anecdote: One thing we also did at this time was to build in a lock to the software (which was described in the documentation). We would ship our equipment upon receipt of a deposit, and the system would work for one month before requiring an unlock software key. There was one company who did not pay the balance of the order and refused to respond to our requests for the balance. About three months later I got a call at 2 a.m. from the company saying that their team was in the middle of a large survey and the system had stopped working. I said that this was because they had not paid the balance and it would remain a brick until that was done. “This is very unethical Doctor Bennett” I was told. “So is not paying your invoices” was my response. I gave them a five day unlock code so they could continue their work, and the balance arrived within three days.

At this time I also became one of the very early users of online support. In the pre-internet web days there was a company called ‘CompuServe’ which had a hosting service. With ROMDAS systems being sent all over the world, and my travelling more for consulting work, this became the solution for making the user guide’s and software available to all users. I eventually adopted an ‘Open Information’ policy where all our internal technical notes, calibration and validation papers were available for download.

The common denominator across all ROMDAS systems from 1988-2010 was the ‘hardware interface’ which Gary Carr developed. This hardware took in the signals from the odometer and bump integrator sensors, and then connected to the computer. Version 1 was created for the BECA NAASRA meter. Versions 2 and 3 were designed to work with the TRL Bump Integrator (or similar) and standard distance measurement instruments (DMIs). Version 4 was created to work with the ROMDAS Bump Integrator—with its higher frequency outputs—as well as the newer DMIs that were coming available with higher pulse rates[7] and precision. Gary produced Version 5 which could handle two bump integrators[8]. This was a unique feature of ROMDAS as it is the only RTRRMS which can measure the roughness in individual wheelpaths.

Version 4 – 1997

Version 5 With Test Kit – 1998

Gary Carr reminisces: Some design details. The hardware interface is based on an Intel microprocessor with a number of programmable input/output lines and serial receive/transmit. The serial lines are connected to an RS232 serial interface to provide communication to the control computer serial port. From memory I think that Paul developed the computer program to process the data. A handshake system was used with ASCII characters to communicate with the hardware interface. Initially there was a small number of pulses for a given road roughness but by using a 1000 pulses per revolution optical rotary encoder in Henk Mooy’s bump integrator a more accurate measurement could be obtained.

1996 – 2000: Getting Serious

Inspiration

In 1994 I worked on the ‘Four States Pavement Management System in India’. This was a major World Bank Financed Project collecting data on a large number of National and State Highways using a very expensive ARAN vehicle from Canada.

I found the concept of the ARAN the antithesis of what was needed for many developing countries. It was very expensive—some $300,000 by memory—and for that we had roughness, ultrasonic transverse profile, video logging, manual rating, and a gyroscope for slope. It was housed in a dedicated vehicle that was shipped from Canada, and so was built for driving on the right, not left hand side of the road.

Anecdote: In 1997 I went to Rajasthan to do some training on the pavement management software. After the training they asked ‘Can you please fix the ARAN’? It was parked out back under a tarpaulin. This is symptomatic of what we find everywhere: works departments are graveyards for these sorts of equipment. After getting a new battery I asked what was wrong. The monitor didn’t work so the starting point was making sure the power cable worked. Unfortunately, the wiring was a nightmare. I noticed that one of the computers had a monitor plug unused on the back and so we got a cable from the office and it worked. They then said the gyroscope was broken. This was more of a worry. There were two switches, one said to the effect ‘turn me on first’ and the other ‘next’. So I did this and it worked. They hadn’t used both switches. The client was happy, but I doubt that the vehicle was ever used for collecting data.

The industry’s needs for effective data to manage roads was increasing, but nobody seemed to be focusing on the practical challenges that are faced in developing countries, or the ethics of providing very expensive equipment which is difficult to service and maintain locally.

Doug Brown from New Zealand was operating the ARAN and I bombarded him with questions about what would work best given the challenges that he faced in getting data. The list was:

• Portable: That way it could be carried into the country and not delayed in customs when shipped as cargo. The photo below shows a ROMDAS roughness measurement system in its case.
• Robust: built to handle rough conditions and able to operate in any climate.
• Flexible: It had to work in any vehicle, and be easy to install and remove.
• Use Readily Available Components: Where possible, use off-the-shelf components rather than designing and building everything ourselves.

I decided to get serious about making ROMDAS an effective system for meeting the needs of developing countries, and develop it along Doug’s guiding principles.

The Company

The ROMDAS work started under the name ‘Highway and Traffic Consultants’ (HTC). This was later change to ‘HTC Infrastructure Management’ (HTCIM) when I found out there was another HTC in New Zealand. We had the mission statement:

“We will provide engineers and researchers with innovative technology for measuring and managing roads, which is cost-effective, efficient, reliable, and well supported, at all times acting as an ethical business”

Our vision was:

“To provide the best technology for measuring and managing roads”

I was the owner and manager of the company, with my wife Lis Pedersen as a shareholder. We were based at our rural property at 1135 Peak Road, Waimauku in the west of Auckland. I built a large open plan office on our property which was overseen by Cilla van Heerden who was our office manager, accountant, human resources person, and jack of all trades. As we grew she was joined part time by Kumeu local Lynette.

A lot of the equipment was produced off site—for example the hardware at Chevron Engineering—and then we would do the final testing, packaging and shipping from our home. This is (a young!) me in our kitchen testing a three camera video system for a client.

During this period we ramped up our game, having our first commercially produced brochure which I first distributed at the 1998 ‘International Conference on Managing Pavements’ in Durban. We also did a video overview of the ROMDAS system (you can see it at https://tinyurl.com/romdas-video), with Paul as the camera man and myself describing the system. The video was photobombed by my cat Aslan. We also created a CD which we sent out not only with our systems, but also to potential clients. Keeping with our policy of being open with our information, this had on it all of our technical papers, background information, etc.

In April 2001 ROMDAS was moved into a new company Data Collection Ltd. (DCL). This change came about through the merger of HTC with Montgomery Watson (NZ) Ltd. We had grown to the point where it was becoming a lot less fun for me so time to simplify my life. This simplification led me to join the World Bank two years later.

Anecdote: CNS Farnell from the UK manufactured and marketed the TRL Bump Integrator with the manual counter shown earlier. As ROMDAS sales began to increase, they stopped selling the manual counters and only the Bump Integrators were shipped. Eventually Tim Farnell asked one of the purchasers what they were using to collect the data and he was told “ROMDAS”. Tim contacted me and I was happy for CNS Farnell to market ROMDAS on our behalf, which they did from 1994 – 1997 until I decided to create HTCIM and take ROMDAS to its full potential.

Developing the Transverse Profile Logger

The measurement of rutting is important for managing roads and so I decided to produce a ‘Transverse Profile Logger’, or TPL. Doug Brown told me that the ARAN profiler used Polaroid ultrasonic transducers so I contacted Polaroid in the USA and asked for the name of two small specialized firms who could do custom work. They pointed me to Doug Boehm of Senix in Vermont. My wife and I were at the PIARC Conference in Montreal in 1995 and so travelled down to meet Doug and discuss my concept.

To meet the portability objective, I wanted to have five sensors at 100 mm spacing in a metal container. We would connect six of them with RS-232 serial cables and have a 3 m span. That way, if one system failed in a survey we could replace them quickly in the field. For the ‘bar’ on the front of the vehicle, it could be fabricated locally. The ROMDAS CD included plans for anyone to build the TPL housing. Plans were free of course.

Senix produced the first TPL components in early 1996, when I was working as a Research Fellow at the University of Birmingham. This is a photo taken by my wife Lis of my desk at home testing the TPL sensors.

For one test I put the TPL into ovens and freezers to test temperature impacts—which were strong and linear. This is not surprising given the relationship between temperature and the speed of sound. But what to do? Doug Brown came to the rescue. He suggested that we add a ‘calibration’ sensor which is fired at a fixed target. Thus, if the distance of this sensor changes due to temperature, elevation, or humidity, then all of the other sensors will need to be corrected by the same proportional amount[9]. This redesign proved to be expensive, but it was a simple and reliable solution which ensured consistent data.

Having validated the TPL in controlled laboratory conditions, it was time to go out to the field. A friend Bryn Jones designed a housing for the front of the vehicle.

I had located a narrow lane near our home with a very poor cross section and so that was the ideal location. We did our measurements with the help of a young friend from church Jonathan Partridge, who also helped me with elements of the video overlay system described below. To get an accurate profile, CNS Farnell had secured a ‘TRL Beam’ which is a calibration device for roughness meters. A wheel rolls along the road with a linear displacement transducer recording the vertical distance to a bar. We turned it 90 degrees and measured the road cross section. This approach would come in useful in later years, but more on that later. Below are some photos from our 1996 testing.

Bryn Jones and I Setting up for Testing

The TPL on Lis’ Car

Lis Helping Measure the Transverse Profile with the TRL Beam

As a result of the testing we confidently stated in the ROMDAS manual: “The confidence intervals for the means [from static tests] were < 0.5 mm with 95% confidence. Allowing for errors in the ‘real world’ the measurements can be taken to be + 1.0 mm.“

To avoid interference effects between adjacent sensors, the same sensor is fired in all six of the units at the same time. This is then followed by a firing of the other sensors until all five sensors in each unit have been fired. The staggering of the firings means that the resulting transverse profile is not from the same point in space but are instead a composite formed from the five firings. The distance over which the sensors are fired was a function of the vehicle speed. The speed of sampling made it possible to take measurements at longitudinal intervals of 10 m at a speed of 80 km/h.

Evan Fray and his son Dan from Chevron Engineering in Auckland refined and improved the housing and he eventually manufactured many of the ROMDAS mechanical elements for us. Later, Dan joined the University of Auckland as a technician so it is great to see that there continues to be a ROMDAS link with the university.

Some years later the firm APSA in Chile did comparisons between manual rutting surveys and the TPL and found good correlations. What was more reassuring was that when the data for homogeneous sections were analysed, there was a 0.98 correlation between the average rut depths at the centreline, and 0.86 at the edge line, showing that the two methods would yield similar results in a pavement management system for identifying where to intervene.

Anecdote: Our pricing goal was always to charge a fair price for the equipment which would allow us to operate, and to continue to develop new instruments or improve on what we had. It was never to maximize our profit—hence giving away for free the plans for the TPL housing. One of our competitors who sold a similar ultrasonic transverse profile logger commented that they could not manufacture their product for what we sold ours for, which was about 25% of the cost of their units. Why? Their system was 100% custom built whereas ours was produced by Senix as a variant of what they had already developed. By using existing solutions and integrating them we kept costs down. And that is what we did with the ROMDAS video system.

Developing the Analog Video System

Video logging is a very important feature for not only recording road condition, but also for road inventory surveys. Often in developing countries you need to do these surveys before road projects start so as to ensure that people don’t move in and occupy land, requesting compensation.

For video surveys to be of value, you need to overlay onto the video key information such as the date, time, road name, chainage, etc. In the pre-digital days this was challenging and expensive and it required character generators. This was an approach I wanted to avoid.

I investigated various consumer products which allowed you to record your computer display onto a small portable video recorder. I came up with a simple and elegant solution: have the entire computer display blank, and only a small box at the top (or bottom) of the screen with the data that you wanted to display on the video. This meant that only a small part of the video was overlaid, as most of the screen was blank. This photo shows the results.

Here is a photo of the complete analogue video system. The system could use either a min-DV or Hi-8 video recorder, but another option was to have a second computer with a video card which would directly digitize videos. Due to computer limitations of the era, this had to be done by a second notebook in the vehicle which was mounted in a docking station with a capture card.

We used a single CCD video camera which was mounted in an environmentally protected housing. This camera could be mounted anywhere on the vehicle. Typically, it was mounted on a roof rack and aimed along the right of way. Later, we ran multiple cameras to also get right-of-way data.

The portable VCR approach above was adequate, but what we wanted was to directly digitize the videos in real time. We solved this by using a notebook computer docking station fitted with an Intel video capture card. This card was programed to record (say) every 10 metres. It doubled the number of computers in the vehicle, but got rid of video tapes.

To help users, in the late 1990s as Windows began to be popularized we developed a desktop application that would allow users to play back the videos.

Anecdote: From the onset, the system was designed to be portable. My concept was that you could put it with your luggage and arrive in a country to start surveys—quite important because importing anything through customs in the 1990s was tedious and bureaucratic to say the least. This created a few adventures for our staff. Howard Porter had never been out of New Zealand and I asked him to come to Cambodia in 2001 to deliver me some gear for a survey. When he didn’t exit the arrival terminal I figured he was being held back by the customs people, for no valid reason. I had to pay a US$100 ‘levy’ to allow him into the country. I’m sure it never made it into the official books. Earlier, Christia Chrysaffis was asked to Manila to deliver some video gear to Manila. When I told her to exit and look for me in the parking area she said it sounded like some dodgy drug deal, except the drugs usually went from the Philippines to New Zealand, not the other way around.

Developing the Bump Integrator

We decided in 1998 to produce our own Bump Integrator. The reason was that our users were reporting that the TRL Bump Integrator was not sufficiently sensitive to low roughness roads. This was related to the number of pulses per revolution that the TRL Bump Integrator produced.

With the help of Henk Mooy from the University of Auckland, we produced a CNC lathe design for the ROMDAS Bump Integrator. This resulted in an instrument that was very straight forward to produce, and also streamlined. In order to test that the ROMDAS instrument was valid, we used a lathe to run parallel tests with a TRL Bump Integrator. The ROMDAS standard error of measurement was lower than the TRL instrument so it would give more consistent results. One problem that this introduced was that the hardware interface was unable to reliably record the data on rough roads, so we released Version 4 which resolved this problem.

Anecdote: The statistically correct calibration of bump integrators was a really important issue for me and I developed an Excel workbook which our users could employ to ensure that they had valid data from our instruments. The ROMDAS manual contained detailed background on the theory and practicality of bump integrator calibration. A few years after I joined the World Bank I went on a Mission where I was assessing the road management system. They were not using ROMDAS, but a different RTRRMS. I complemented the consultant on the level of detail they included in their company’s guide on calibration provided to the client—and then advised that I was in fact the author! They had lifted everything from the ROMDAS manual and then relabelled it as their own. Fortunately, I’ve always subscribed to the maxim that imitation is the sincerest form of flattery, so I just insisted that they give credit to DCL.

Introducing GPS Surveys

Many people are surprised to hear that GPS was initially reserved for military applications. So during ROMDAS’ early days it was of much more limited use than today. Until 2000 there was ‘selective availability’ activated which gave it an accuracy of +/- 100 m. We designed ROMDAS to work with any GPS device that would output an ASCII text string with their data through a serial port. The most common format was NMEA 0183. As users wanted improved accuracy we updated the system to allow for differential corrections, as well as commercial providers such as Starfire who offered their own improved accuracy transmissions.

To support the video surveys we developed the Laser Surveyor option. This would see a Laser Atlanta Advantage GPS Survey instrument aimed at a location reference point, and the system would store the GPS co-ordinates of that point. This was never a popular option, but was fun to do.

Anecdote: One of the challenges with GPS surveys in the early days was relating the survey data to the actual roads. The figure below is from a 2001 survey in Samoa where the GPS measurements were offset by some 13 m from the road. There was an issue with the projection data that was used to convert the NMEA0183 readings to the Western Samoan Integrated Grid. Today, these issues are long resolved with correct projection parameters readily available.

Failing to Develop the Longitudinal Profile Calibration Device

1998 marked the year of our most expensive R&D failure.

I had long been concerned about the lack of an affordable Class 1 calibration device for our roughness meters. The only practical options were the Face Dipstick and the ARRB Walking Profiler, both of which were prohibitively expensive.

The ROMDAS Walking Profiler (‘Longitudinal Profile Calibration Device’ or LPCD) was designed by Mike Jones—an ex-University Auckland technician—to be a Class 1 road profiler for quality control or for calibrating roughness meters and gave elevation readings to a resolution of approximately 0.5 mm. It was a lovely machine:

· Portable: Weighing less than 7 kg, the LPCD would fit into a small case.

· Ease of Use: The LPCD was a small ‘cart’ which was pushed along the road.

· Triggering Surveys: Surveys could be automatically started and stopped to ensure that the measured lengths are correct.

· Data Logging: Had its own on board data logger.

· Temperature Corrections: The LPCD automatically corrected for the effects of temperature on the measurements.

This is me testing Version 3 on the edge of Peak Road outside our property.

In spite of building three prototypes we were unsuccessful at getting it to work. The accelerometers would just not settle fast enough to get reliable readings. This lead to the development of the static Z-250.

The Z-250 Profiler

If at first you don’t succeed, try again!

We built the Z-250 which consisted of an inclinometer with two feet spaced at 250 mm (hence Z 250, with Z for the vertical elevation). The Z-250 is ‘walked’ along the road and records the elevation profile (in mm) at 250 mm intervals along the road. The data were logged into a hand-held Windows Pocket PC. At the end of the survey the Z-250 calculates the IRI for the wheelpath.

The Z-250 was validated against a Face Dipstick owned by Transit New Zealand and found to have a correlation of 1. So we were very confident with our much lower cost solution.

Other Features and R&D

One of the things that we did as a company was have an R&D budget. This was a ‘sunk cost’ wherein the money was in a dedicated account only to be used for R&D so if someone had an idea with potential, we could give it a go. It was a lot of fun and really interesting, with the team learning new skills. We had many successes—using the funds to refine what we were already building—but also failures (the longitudinal profile calibration device being the greatest!). Some things we did worked, but there was no market interest in them.

Voice Recordings and Digital Photographs

As our systems began to be more widely used, we were asked for refinements. One of them was to integrate digital photographs and voice recordings into the system.

Anecdote: We first did this for Auckland City Council who had their resident engineer on Great Barrier Island retiring. They wanted to ‘capture’ his knowledge, so we did a video survey with him giving detailed comments on issues around each section, what had happened and what to watch out for. An effective way to capture institutional knowledge about to be lost!

Griptester Integration

The Findlay Irvine Griptester was a small, portable friction measurement device. Lis and I had a delightful visit to their office in Scotland in June 1997 to work out the technical details. Delia Harverson was a great host, and I found the trip extra special since my grandmother came from Edinburgh. The weather was miserable (it was June with snow on the mountains!) so I could see why she moved to South Africa. We worked out the technical details of how to integrate the Griptester into ROMDAS and developed the technical specifications, but nobody ever requested this option during my time with ROMDAS.

Crossfall Measurement

The ROMDAS crossfall system was based upon a four sensor KVH gyroscope system which was mounted on the vehicle. The measurements were made with a fluxgate compass, an inclinometer and two 2-axis gyroscopes. The output from the system is the vehicle pitch, roll and heading to an accuracy of 0.1 degrees. The data were analysed in conjunction with the transverse profile data to estimate crossfall—which was an interesting intellectual exercise to figure out how to do it.

Dust Meter

This was going to be an instrument which we would mount on the rear of a vehicle to measure the dustiness of unsealed roads. The idea was based on something that Phil Page-Green developed for the CSIR in South Africa. The design was to measure the dust using light sensors and emitters. These sensors were to be attached to a vehicle traveling down an unsealed road; one attached to the car in front of the forward tire and the other behind the rear tire. The dust travels between the light emitter and the light sensor obscuring to some degree the amount of light that the sensor is able to measure. The light measured by the second sensor was less than that of the first sensor due to the dust generated by the wheel. The difference between the measurements between the two sensors was a measure of the dust generated by the surface. We built an early prototype but laboratory testing proved that there would be too many operational challenges so the project didn’t proceed.

Illumination Measurement

We thought it would be interesting to do an inventory of the streetlight locations from a moving vehicle. We built a system with a 40 Hz ‘Gigahertz Optical’ luminance meter with a remote sensor on a 2 m cable. To protect the measurement sensor, a 75 mm diameter optical lens was mounted in the cone approximately 20 mm above the sensor. Since the presence of the lens altered the amount and distribution of the light reaching the sensor, we developed a linear calibration equation. As the chart shows, the system worked, but there were practical issues such as needing to better shield the sensor from other ambient light sources. Nobody ever expressed interest in this feature so we didn’t take it further.

Dedicated Keyboard Rating

One of the features of ROMDAS from the beginning was the ability to record point events (at a single location) or continuous events (over a section of road). While some of our competitors had expensive and custom systems for doing this, we identified a low-cost off the shelf unit that just plugged into the computer. This kept with the philosophy of ROMDAS: adopt or adapt where possible rather than create!

Moving Traffic Surveys

Traffic count data have always been recognised as important in the design and planning process. Traditionally, most traffic count data have come from temporary or permanent traffic count locations. An alternative approach, which lends itself to a ROMDAS survey, is to do a ‘Moving Traffic Count’. It works mainly on single and two-lane roads, although theoretically it should also work on multi-lane roads. The Average Daily Traffic (ADT) is estimated as the number of vehicles counted travelling in the opposite direction divided by the time taken to travel the section[10]. ROMDAS was designed to undertake these surveys with the operator striking a key when a vehicle passed, optionally using multiple keys to classify the vehicles. Various calibration factors could be input to ROMDAS to convert the ADT to an average annual daily traffic.

Anecdote: I made an application for research funding to adapt and calibrate the moving traffic survey to New Zealand. It was unfortunately declined. Sometime later I was contacted by a graduate student asking for a copy of an obscure report that I referenced in my application. It transpired that their supervisor had been on the evaluation committee which declined my proposal, but had liked the idea so given a copy of my proposal to their student to work on. As a result of my formal complaint the evaluation process for research funding was subsequently changed so the potential for such theft of intellectual property was reduced.

Congestion Surveys

In 1994-95 I was Team Leader developing the technical models used in the HDM-4 software for economic analysis of roads. A key metric that we developed was the concept of ‘acceleration noise’ for measuring congestion: the more congested the traffic was, the greater the frequency and intensity of accelerations. So of course I implemented a speed survey option to collect data on travel times and accelerations for when I would be using HDM-4 in the field. ROMDAS produced three statistics:

· Average speed: this is defined as the cumulative distance travelled divided by the cumulative time (km/h).

· Instantaneous speed: this is the speed over the last observation interval (i.e. between the 1 s intervals). It is the change in distance divided by the change in time (km/h).

· Instantaneous acceleration: this is calculated as the change in instantaneous speed divided by the change in time (m/s²).

Unfortunately, I’ve never seen it reported in HDM-4 calibration studies that anyone ever used this feature.

Calibration Triggers

We developed a photocell attachment for ROMDAS to allow for the automatic triggering of starting and stopping data logging. The photocell was directed at the pavement and when a reflective strip is crossed the system will start/stop. This was designed to improve the calibration accuracy. Unfortunately, it was found that while these worked adequately in a laboratory setting, they were not well suited to actual field applications. This was primarily due to the response time required for a signal to register: at high speeds a very large target was required and even then missed signals were frequent. Accordingly, the development focused on a simple mechanical sensor using easy to obtain parts: (i) a door lock hasp which is used with a padlock to lock doors/gates; (ii) a magnetic alarm sensor used on doors and windows as part of a burglar alarm system; (iii) a lightweight rod (such as used with curtains); and, (iv) a spring. The rod was attached to the magnets on the hasp and run out to the left of the vehicle. The sensor was triggered by having a pole or heavy stand adjacent to the start of the test section. When the vehicle was driven along the road the rod struck this pole which caused the magnetic sensor circuit to be broken. The ROMDAS system then started recording data. The spring brought the bar back into its original position. At the end of the section another pole was struck and the circuit was again broken. This caused ROMDAS to halt recording. Simple, low cost, and worked well.

TRAFDAS

I found it frustrating that there was no low-cost traffic counter so I decided to build my own. TRAFDAS was a simple pulse recorder which when connected to a treadle, piezo electric or similar detector would record the time of observation. Below are photos of the prototype being tested on Peak Road outside our property.

The data processing was done using a suite of software tools that I had developed during my PhD research for a similar device. It worked well but we never finished the project commercially, preferring to focus on our core ROMDAS business.

2001 – 2003: Windows Takes Over

ROMDAS for Windows

By 2001 we transitioned ROMDAS from the MS-DOS system to Windows (ROM-WIN). The programing was done by Tim Johnson who worked with the team until about 2013, also doing the ‘Laser Crack Measurement System’.

ROM-WIN was a complete rewrite from the ground up, although it still used some of the original command structure. ROM-WIN Release 1 focusing on roughness, LRP, key code, GPS and video surveys; TPL surveys and other features were relegated to Release 2. The major advantage to ROM-WIN was it simplified the use of peripheral cards, such as PCMCIA cards, by using standard Windows device drivers. One really nice feature was the video camera connected to a Firewire (IEEE-1394) PCMCIA card, so the system directly digitised videos onto the same computer used for the other ROMDAS data. This eliminated the need for a second computer in the vehicle for video surveys.

As mentioned earlier, in 2010 the ROM-WIN system dispensed with the original RS-232 hardware interface and the system was driven by USB protocols. Below is the current system.

Laser Profilometer

In 2001 we received a grant from the NZ Foundation for Research in Science and Technology to develop a low-cost, portable laser profilometer. Richard Williams began developing our own but then found an Australian Company AMSCAN which were selling a turnkey solution that we could integrate into the ROMDAS platform. So we went down this route.

The profilometer consisted of a laser with an 8 mm spot size operating at 16 kHz coupled with a fully integrated accelerometer and a standard Ethernet interface. It determined the elevation profile of the pavement (in mm) from which the roughness is calculated. The elevation profile was also stored. ROM-WIN displayed the IRI in real time, and the elevation profile could be directly analysed using the RoadRuf software for additional information.

For validation we operated the system on four test sections used by Transit New Zealand for profilometer validation. A second validation was done at the 2002 Pavement Evaluation Conference when DCL participated with other vendors in measuring the ‘Smart Road’. A straw poll with other participants showed that we had similar roughnesses.

One unique feature of the ROMDAS system is that it was designed to run BOTH Bump Integrators and the laser profiler. Why would you want to do this? It allows for surveys to be done at low speeds and on very rough roads where no profilometer can measure[11].

ROMDAS Road Management System

We had developed a number of applications to help process ROMDAS data. In early 2001, as part of our transition to ROMDAS for Windows, we released ‘ROMDAS Road Management System’ (RMS) as the standard system for all post-processing of ROMDAS data. We had features in the RMS such as automatic and semi-automatic video calibration which relates the frame numbers to the chainages on the road, the ability to generate MapInfo data from the GPS data, displays of static digital photographs and play digitized voice recordings. Later, it included the ability to estimate pavement widths from videos and enter visual distresses during video playback. Zuwei Deng who developed this was one of the best programmers I ever worked with and we were lucky to have him on our team.

Stationary Transverse Profiler (STP)

The New Zealand Government decided in the early 2000’s that it was time to start a long-term pavement performance (LTPP) monitoring project. In 2001 HTCIM won a proposal to undertake the data collection for this project.

For the transverse profile we initially planned to use the TRL Beam used for validation of our TPL in 1996, but decided due to its very high cost to instead develop our own system, which also could be more suited to these requirements. The beam had a motorised carriage with a wheel mounted on a vertical bearing which moved up and down following the profile of the road while the carriage was driven across the beam. Two encoders (one horizontal and one vertical) provide the data from which the profile is obtained. The horizontal encoder triggered the data collection and the change in height and distance travelled were recorded at 3mm intervals.

The original idea was to have the beam software on a handheld device and while this collected and stored data as required it took too long to extract the files from the device and so a laptop computer was used. An accelerometer was fixed to the beam so that the data could be adjusted to the horizontal. Below are photos of the original Version 2 and Version 3 systems. We were concerned that the sag in Version 2 might bias the rut depth data and so developed Version 3, unfortunately version 3 proved to be unreliable in that the carriage bearings would wear out after only a few weeks of use and had to be continually replaced. [12]. As you travel around New Zealand you will today see 300 m of parallel white dots on the road—this is where Doug and his team continue to collect the data using Version 4 developed by his company R&D Consultants. Software upgrades over the years have resulted in a beam which now displays the profile in real time and calculates the rut depth automatically.

Version 2 – Original STP for LTPP Study
Version 3

ROMDAS Manual Counter

To be honest, I had forgotten that we developed this until I delved into my archives in writing this history. Richard Williams designed this in 2001 as an alternative to those who didn’t want to have the full ROMDAS experience. Gary Carr built us a box with five LCD displays. With inputs from an odometer sensor and up to two bump integrators, the MRC displayed the roughness, speed and distance travelled. Two buttons were used to control the MRC. It was a throwback to the original CNS Farnell manual counter discussed at the beginning of this history, but of course better (e.g. by recording the speed we could use multiple calibration equations to correct for speed variations). It sold well after I left—and order of 21 went to RHD in Bangladesh in about 2004—and the last was sold around 2007. It was replaced by the miniROMDAS which ran on the same Windows Mobile device as the Z250 and connected to the ROMDAS Hardware interface via a Bluetooth connection.

To Close

I can describe my 15 years of creating and commercialising ROMDAS with four words: “it was a blast”. I was privileged to work with some amazing people and we took our ideas—more often than not—from an initial concept to commercial reality. Many of our creations or their offspring are still in use today. There were a number of R&D activities which never made it to commercial reality, but they were never a waste of time or money as we learned new things, and enjoyed the R&D process.

While many contributed, without Gary Carr’s incredible expertise with electronics, and Paul Hunter’s programing skills, ROMDAS would never have eventuated—let alone thrived. So thanks to Gary, Paul and the rest of the team (see below). It was an amazing ride!

The ROMDAS Team

Christopher Bennett	Founder, owner and manager 1988 – 2003
Bryn Jones	Transverse Profile Logger Development and Testing – 1996
Christia Chrysaffis	Manual writer and software testing
Cilla van Heerden	Office Manager
Doug Brown	Survey Manager and Electronics Technician
Gary Carr	Electronics Technician and Developer of ROMDAS Concept
Gavin Murray	Psion LZ64 Programmer – 1988-91
Henk Mooy	Bump Integrator Developer and Fabricator
Howard Porter	Technician
Ian Greenwood	Transverse Profiler Logger Testing – 1997, Utility Software
Jonathan Partridge	Transverse Profile Logger Testing – 1996
Leighton Fletcher	Technician
Mike Jones	Longitudinal Profile Calibration Device Developer
Mike Riley	Road management boffin and ideas man
Nabin Pradhan	Highway engineer, designer and tester
Paul Hunter	Programmer, co-owner and manager 2003+
Raj Mallela	Co-owner 2003+
Sandy Clotworthy	Accountant
Theuns Henning	Highway engineer, designer, and tester
Tim Johnson	ROMDAS for Windows Programmer
Zuwei Deng	Programmer of ROMDAS RMS and other tools

Here are memories some of the team shared for this history:

Gary Carr

I started working as an electronic technician at the University in 1988. Chris wanted to capture information on a computer so I designed and built an interface and that was the birth of the ROMDAS system. In between I took up a position as a technician with Civil Engineering working alongside Mike Jones who later became a close friend. Along with other projects for the Department I continued on an ad-hoc basis with Chris and his ROMDAS making incremental improvements and designing and building the hardware/ software until the final model version five in 2001 at which point Paul Hunter took over and I opted out.

Throughout I enjoyed working on the project with Chris along with the many other projects required by the Civil Engineering school academics.

Paul Hunter

I was first introduced to Chris in 1993 by Thomas Ekholm who was a friend of Chris’ and one of my tutors in my final year at Whangarei Polytechnic. It was a small job to create a menu system in FoxPro for software he had developed for his PhD project.

In 1994, my first year out of Polytechnic, I become self-employed after securing a contract with a company building real time control systems for the saw milling industry. A little while later Chis contacted me again and so I also started doing programming on ROMDAS. There was already a functioning ROMDAS version for TRL Bump Integrators for roughness surveys. It used an MS-DOS based software database language called Clipper that I had never used before.

Slowly year by year Chris would send me a new piece of equipment to get working with ROMDAS. First it was GPS, then the ultrasonic TPL, as well as incorporating extra functionality for key code surveys, location reference points etc.

Clipper on a MS-DOS platform being a database language presented a lot of challenges to use in a real-time environment reading from multiple devices and instruments. I had to get very ‘creative’ to get this working as things started expanding.

At this time Chris was working overseas a lot and he was an early adopter of a very new thing in the mid-nineties called the Internet [My first attempts were around 1991 when we tried unsuccessfully to pair modems to send files to/from Burma!]. We used this to send files back and forward and new versions of the software for Chris to test.

Of course, it was nothing like today. I would log on with a 14kbs modem and once logged on you ended up at the UNIX prompt and everything had to be done with UNIX command prompts to then log in to CompuServe which was the file sharing platform we were using. No GUI then and quite different than what we are now used to.

In the year 2000 there was a large project happening in the Philippines with a road survey being done of the whole country. They were using ROMDAS but there was lots of new features that needed to be incorporated and so it was decided that it would be easiest if I was on the ground in Manila to get this done quickly as the surveys were about to start. This was my first time overseas apart from a small holiday in Australia.

This was also the first time I had seen the whole ROMDAS system installed and used in a vehicle. My six years of programming to date had been all in the basement of the house I was living in in Glen Eden with one small piece of the puzzle at a time. This certainly opened a whole new perspective for me to see everything working together.

Manila had such a traffic problem that the only time they could conceivably survey the roads was over the weeklong Easter break. So, all four of their survey vehicles came to Manilla but they needed to keep them operating 24 hours a day to complete all the required roads. The contractor AFRICON asked if I would be an operator for the week. So here I was finally using the product I had been developing the software on for six years as an operator, on 12-hour nightshifts for a week in Manilla. Quite an experience and invaluable going forward to experience the real-world problems first hand in using the software and equipment.

Later that year after my return from the Philippines Chris asked me up to Waimauku and announced that he was going to ride his bicycle across the USA and would I come an manage the ROMDAS side of things for him while he was away. I agreed and this was where I started to work from Chris’ Waimauku office with all the HTC employees. This was quite a different thing than just writing the software. There was electronics and cables to oversee the building and testing of, fabrication to oversee with Chevron and other new and interesting tasks. When Chris returned, I stayed on full time.

It wasn’t long before a couple of systems were sold to South America that needed installation and training. Thinking that I didn’t quite have the experience and knowledge for this yet I remember asking Chris what to do expecting detailed instructions, guidance etc. In typical Chris style he gave me advice somewhere along the lines of “remember you know more about it than they do therefore you are the expert”. I felt a bit like I had thrown me in the deep end– Chris was always confident I could swim but I certainly was not so sure. All went well and after returning from an exciting trip to Uruguay and Chile I was sold on continuing to work with ROMDAS.

The training and installation trips became a very big part of my life after that sometimes spending 3 – 4 months of every year travelling to do this.

During this time Chris and Lis moved from Waimauku to the top of the South Island and ROMDAS office moved from Waimauku to a rented house in Mt Roskill. There was a lot of interesting and new developments to ROMDAS during the early 2000’s as well as new sales to new customers and countries.

By 2001 the MS-DOS version of ROMDAS written in Clipper was getting completely unwieldy and limiting for new developments and was long overdue to be rewritten on a more appropriate framework. C++ in the Windows environment was the logical replacement development platform, however, this did not come very easily unfortunately as after more than eight years of development it had by now grown to be a big piece of software with thousands and thousands of lines of code. Being a completely different platform, it was complete rewrite of the software and so we got Tim Johnson in to do the work.

Once we were on the Windows platform integration with other vendors’ products was easier and many new developments started to happen such as the integration of AMSKAN laser profilers, direct integration and control of GPS receivers, recording directly from video cameras etc.

I didn’t actually see a lot of Chris in those years as he was away working internationally a lot, but one memory is joining up with him in Roanoke, Virginia in 2002 for the RPUG conference where we had a booth to showcase our new laser profiler. We then went on with Jerry James and Murray Cox from AMSKAN (the company that developed the laser) to the SMART road where we ran the test road with a host of other venders. It was fascinating to see the big American systems there which I had never come across before.

Hugely complicated, power hungry systems (some of which needed dedicated petrol power generators mounted in the vehicles). The simplicity and portability of the ROMDAS system which we mounted on a local vehicle in half a day in comparison to these systems in their dedicated vehicles was very interesting and validated Chris’ original vision. This portability is a model that we have endeavoured to keep as much as possible as time has gone on.

All this took a dramatic change in 2003 when Chris went off to work for the World Bank and had to divest himself of ROMDAS. He helped several of the employees buy the company, myself being one of them. I still remember the exact day of the takeover being June 26th, 2003 as it was my 40th birthday. I was now one of four shareholder’s and became the managing director. We operated from my basement for a while until we rented a commercial building in 2005 in New Lynn where ROMDAS is still operating from today (although we now have expanded into a bigger building next door).

Now 17 years on the company has grown considerably and there have been many adventures and rewarding experiences along the way.

Nabin Pradhan

Remembering those early days (late 1998), working with Chris at an attic office in Waimauku, the first thing I learned was to turn-off myself from other people’s conversation. Chris was constantly on a phone discussion with his sub-contractors and ordering components from various parts of the world for assembling ROMDAS parts. That’s when I found out that manufacturing a ROMDAS system is not an easy task.

Also, memorable was the first meetings with the original manufacturers and programmer at their garage/home where ROMDAS parts were manufactured and the application was developed. One of my jobs in those early days was to courier components/parts to and from the subcontractors on my way home.

Chris’s entrepreneurship of utilizing home-based sub-contractors and his innovative ideas helped to come up with an affordable and reliable data collection system. It was successfully adopted in quite a few countries with an emerging economy.

We were always amazed by the innovative ideas Chris come up with and his persistent nature to convert them to reality. Roughness bump integrator, much more accurate than TRL (most popular one in those days), rut bar using cheaper ultrasound technology (in comparison with expensive transverse profilometer), video images calibrated with GPS co-ordinates and chainage were quite new for us. Being able to visualize processed condition data and work program together with video on one screen was something very useful for an asset manager maintaining a road network.

Obviously, innovation sometimes comes up with surprises. I remember when we were testing GPS tracklog in Samoa – it took some time to figure out why handheld GPS receiver costing less than $1k was giving more accurate co-ordinates than one costing more than $25k.

With building precise calibration devices like Z-250 for calibrating equipment measuring longitudinal profile, Stationary Transverse Profiler (STP) for transverse profilometers, etc. We managed to win the first Transit NZ (now NZTA) Long Term Pavement Performance (LTPP) contract. I still remember the proud moment when I went to Transit NZ Napier Gordan Hart’s office to sign this contract.

My four years of working closely with Chris was one of the most invaluable time of my career development. At that time I was just migrated from a developing country to New Zealand. I had learned a lot about asset management systems from the network of the experienced asset managers I got exposed to and, also, from the best experts around the world whom Chris managed to collate for various pavement management projects in New Zealand and the Asia Pacific. The technical, as well as human skills I learned from Chris, has always been a guiding principle in my asset management career.

Howard Porter

HTC/DCL was a great company to work for and I have been fortunate to be part of the ROMDAS journey.

After graduating as an electronics technician I had 29 job interviews prior to joining the company. I didn’t have a car so I borrowed my aunties’ car to get to the interview. The 70km drive from Papakura to Waimauku was worth it as the job got me my first car and a trip to many interesting countries in the end. [Chris’ comment: Paul and I were very impressed that Howard went to such an effort to make the interview. As he was heading back to his car I said to Paul “Why bother with any more interviews? He’s a great fit.” and Paul agreed so he rushed out the door and told him before he could leave that he had the job. An example of the very robust recruitment processes we used!]

My first overseas trip ever was to Cambodia. I spent an hour in customs getting interrogated at Siam Reap airport with the authorities wondering what the heck I will be doing in Cambodia with $40k of laser surveying equipment with me. Not sure if it was the combination of equipment, youthful face, or my body frame that raised their alarms. After some long delays of back and forth sign language communication going nowhere I was relieved to see Chris and get that US$100 clearance. Now that’s a story I’ll never forget!

Another trip saw me carrying $40k in cash from Seoul from a Z250 sale. You would think that payment online would have been easier. No falling asleep for me on the plane back home!

As a New Zealand born Samoan, the trip to Samoa was another great memory. Enjoying a Vailima beer at the Vaisala hotel in Savaii or the Coconut Beach resort in Upolu after long days of daily surveying that was a great treat. Over one month Paul and I managed to cover both islands of Upolu and Savaii collecting GPS, Video and BI roughness surveys for all of the Samoa Goverment owned roads.

Another memory was when we had the DCL company meeting in Motueka. Paul and I decided to go sightseeing in the ROMDAS Mazda Bongo survey van. We got it stuck in the Golden Bay beach sands and lucky for us, a friendly local who happen to drive by at the right time we managed to pull the van out before the tide came in. That was close!

In closing, it was a pleasure to have been part of the ROMDAS family. Kudos to Chris for your vision and dedication to dream in creating a product of value that has lasted for years and still counting….

Christia Chrysaffis

It was a significant step up from flinging burgers at McDonalds as a 19 year old. Chris kindly offered me a part-time job with HTC. This felt like a luxurious shift, not only because the office was located in Waimauku, a slice of NZ heaven, and that I was able to enjoy Lis’s delicious sandwiches regularly, but that I was working in the same industry I was studying – Civil Engineering.

My time at HTC proved invaluable to my engineering journey, especially when years later, as a Council Development Engineer, I would inspect council’s pavement for signs of failure amongst other responsibilities. Somehow, rut depth was a particular trigger point for me, and something I often looked for. I’ll blame that on Chris and my time with HTC proof reading reports and manuals and testing out TPLs!

I remember Nabin, Paul, Theuns and the other staff and their gentlemanly manner and of course, Cilla, who was an efficient operator and a listening ear to my teenage ramblings. The staff were always a good, safe bunch to be around. Chris did make it clear to me, with a grin on his face, that one of the reasons I was useful to him (as a system tester), was because I would emulate the “least competent user”! [From Chris: I will blame Mike Riley for this. He said that the best thing to do was to get someone completely unfamiliar with the system and get them to use it. If they can make it work, anyone can.]

One of the most exciting and vivid experiences for me, was the last-minute emergency, where I was needed to be the ‘mule’ carrying GPS equipment to Manila, Philippines. I only had a few days’ notice. I remember being told to keep the GPS with me at all times, including not sending it as checked in luggage, but to keep it as hand luggage. 20kg of hand luggage would NEVER be allowed in the cabin these days. But somehow, I made it via Sydney (with a walk around the city centre with the luggage on my back while killing time for my connecting flight), Kuala Lumpur and then Manila. Yes, by the time I saw Chris on the other side of customs in the extreme December humidity of Manila, it did feel like some dodgy drug deal! I was so relieved to have made it through all the x-ray scanners without anyone seizing the spider web of wires and circuitry that was in view on the screen.

Chris combines competency, technical expertise, world-class engineering and empathy for humanity all in one. I appreciated the ethos of the company and its ethics (even through the eyes of a teenager back then) – to provide effective data to manage road infrastructure at a price that developing countries could afford and packaged in a way that would work practically in their context.

They were great times!

Annex: Evolution of ROMDAS in Pictures

1995
1998
2000
2002
2003

---

[1] 92 Bay Vista Drive, RD1 Takaka 7183, NEW ZEALAND. www.lpcb.org.

[2] Source: http://www.kanomax.co.kr/html/product/pdf/safety_16.pdf (left)

[3] Source: https://www.eindiabusiness.com/vedengineering/products.html

[4] Source: http://onlinepubs.trb.org/Onlinepubs/trr/1978/666/666-005.pdf

[5] Source: http://www.kanomax.co.kr/html/product/pdf/safety_16.pdf

[6] Source: John Hallett

[7] We developed a ‘pulse divider’ for the ROMDAS Bump Integrator to work with the older units. This transmitted every fifth pulse to the unit, providing similar results to the TRL Bump Integrator.

[8] Paul advises that Gary’s original hardware interface went through several small redesigns and software tweaks through to about 2010. Since computers had stopped having serial ports, the system used serial to USB converters. It was then redesigned on a generic XMega board with a daughter board.

[9] Credit also goes to Doug for the simple procedure to calibrate the relative heights of each sensor: parking the TPL over a trough of water.

[10] Ron Allan provided the mathematic basis for the approach in ROMDAS.

[11] Laser profilometers have issues measuring a low speeds and rough roads due to the way they work. There is an accelerometer which measures the movement of the laser unit through space, and a laser which measures the elevation of the laser relative to the road. The difference between the two is the elevation change of the road profile. At low speeds the accelerometer no longer gives meaningful results as the signal is very low. Similarly, on very rough roads there is too much noise. RTRRMs will therefore give better results under these conditions.

[12] Version 1 was a prototype system which was constructed in two parts and tied together and tensioned with wires and found to be unsuitable for our field application and so was never used.

Advertisement