Update: our team placed 3rd in the final competition.
I developed a system to automate survey tasks such as structure deformation monitoring using a cell phone for my final undergraduate project. A phone emulates a traditional data collector for total station at a tenth of the cost of COTS product. The networking capability of the phone also enables live updates and tasks assignment in the field.
With a bit of interface electronics, I had the phone connected to a total station via Bluetooth. My Android application receives survey instructions over the internet, and controls the total station to survey automatically. I had to write the software on the phone (Android, Java) that controls the total station via the Leica API, as well as the software on the basic web server (Python) that collects instructions over the net and distributes survey status and results.
(The final demo was run over WiFi, and I had my laptop set up as the server locally instead of over the real internet.)
The phone conducts periodic survey and reports the results to a remote server in real time. A supervisor can then monitor the progress and review the data from any web browser on any device - be it a desktop in a office, or an iPad in the field.
Most of the work was actually in understanding the proprietary Leica API for the total station. Documentation was available, but often the exact behavior of the API is not fully described in text. For example, when an "abort" command is sent, will the station stops moving at the instance it receives the command, or will it stop after the current command is completed? These behaviors of the API are often not documented and the only way to find out is to test it myself.
This is a proof-of-concept showing that I got Bluetooth SPP working on Android with a custom AVR dev board:
A little "Bluetooth dongle" I made:
The rest is better summarized in a graph.
The complete system was demoed on May 1st, 2013, the same day the Lassonde School of Engineering officially launched. We placed target markers around the hall and had the system automatically surveyed them and showed the results live on an iPad and a laptop. Our team placed 3rd in the presentation competition.
Presentation, presentation, presentation. The outcome of this sort of competition usually has little to do with the technical content. The number of features I can demonstrate in a 5-minute presentation is very limited, so the confidence you have in your product affects the outcome much more so than the actual amount of technical work you have put in. This is when a good presenter is crucial.
But at least I can take solace in that there are still technical minds out there. A judge approached after the official demo:
"Which of you is the programmer?"
My team pointed at me. So he turned to me:
"So you wrote the code?"
"The server as well?"
"Is it threaded?" Threading often improves usability but are more challenging to design and debug. This is a question that tells a lot about the ability of the developer.
"Yes I did. I also designed the application protocol with XML as well. I wrote the encoder and parser pair in Java and Python. Message framing was done using byte-stuffing over TCP..."
"Not bad. You are graduating this summer right? Here's my card. Give me a call if you are looking for a job."
So he knows that there's often only one key programmer who does all the technical work.
All Rights Reserved. Stanley Lio, 2014
Stanley Lio >