{"id":140,"date":"2014-10-10T07:27:23","date_gmt":"2014-10-09T20:27:23","guid":{"rendered":"http:\/\/new.radio-active.net.au\/web3\/?page_id=140"},"modified":"2014-10-10T07:27:55","modified_gmt":"2014-10-09T20:27:55","slug":"aprs-in-hollywood","status":"publish","type":"page","link":"http:\/\/www.radio-active.net.au\/web3\/consult\/projects\/rezn8\/aprs2000","title":{"rendered":"APRS in Hollywood"},"content":{"rendered":"

APRS in Hollywood<\/p>\n

\n

 <\/p>\n

APRS in Hollywood<\/span><\/span><\/h3>\n

 <\/p>\n

Integrating
\nReal Time 3D Graphics<\/span><\/center>with Wireless
\nGPS systems.<\/span><\/p>\n

 <\/p>\n\n\n\n\n\n
<![if !supportMisalignedColumns]><![endif]><\/caption>\n
\n

Phil Brock<\/h2>\n
Senior Graphics Programmer<\/div>\n
REZN8,\u00a0<\/span>Hollywood,\u00a0CA,\u00a0USA. <\/span><\/div>\n
Pbrock@silcom.com<\/span><\/div>\n
<\/div>\n<\/td>\n

<\/td>\n\n

Bill Kovacs<\/h2>\n
Chief
\nTechnology Officer<\/span><\/div>\n
REZN8,\u00a0<\/span>Hollywood<\/span>,\u00a0<\/span>CA<\/span>,\u00a0<\/span>USA<\/span>.<\/span><\/div>\n
Bkovacs@rezn8.com<\/span><\/div>\n
<\/div>\n<\/td>\n<\/tr>\n

<\/td>\n\n

Darryl Smith, VK2TDS<\/h2>\n
Radioactive
\nNetworks,<\/span><\/div>\n
Sydney<\/span>,\u00a0<\/span>Australia<\/span><\/div>\n
Darryl@radio-active.net.au<\/a><\/span><\/div>\n<\/td>\n

<\/td>\n<\/tr>\n
<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

Abstract<\/h2>\n

 <\/p>\n

<\/div>\n
This
\npaper describes the integration of a real time wireless GPS\/GIS system
\nwith high end real time 3D computer graphics. It describes some of the
\ninfrastructure required for such a system, and the work required for implementation.<\/span><\/div>\n
<\/div>\n
<\/div>\n

 <\/p>\n

Introduction<\/h2>\n

 <\/p>\n

<\/div>\n
A large
\npercentage of the worlds information is geographically based. Applications
\nsuch as the graphical APRS clients are a great way to view this data, but
\nthe information although dynamic lacks impact. With this in mind, REZN8<\/a><![if !supportFootnotes]><\/a><\/a><\/a><\/a><\/a>[1]<\/a><\/span><\/span><![endif]><\/span><\/span>
\nand Radioactive Networks<\/a><![if !supportFootnotes]><\/a><\/a><\/a><\/a><\/a>[2]<\/a><\/span><\/span><![endif]><\/span><\/span>
\njoined forces to create a demonstration on how geographical based data
\nsuch as that from APRS could be rendered if combined with the fastest desktop
\ncomputing power, the fastest graphics cards and the latest 3D rendering
\npackages.<\/span><\/div>\n
<\/div>\n
We are now to the point where realistic 3D graphics can be generated in real time on the desktop \u00f1 and not just the graphics like those found in Doom or Quake but broadcast or film quality. This project was done using APRS as the base which all other technologies were added. The technology we are presenting here is quite intensive on animators and modelers at the moment, but developing technology should reduce the resources required.<\/span><\/div>\n<\/div>\n

 <\/p>\n

 <\/p>\n

\n

The Idea<\/h2>\n
<\/div>\n
In the outside world the way that information is presented to the user is paramount. If it were not, Linux would be the predominant desktop operating system and Windows would be a cute toy for hackers. Like most software of it’s type, all the APRS software under windows environments presents the information in 2D.<\/span><\/div>\n
<\/div>\n
REZN8 wanted an application they could use to highlight their graphics expertise when integrated with the latest microprocessors and nVidia graphics cards. They decided that adding 3D graphics to APRS would be the ideal example of this expertise and technology.<\/span><\/div>\n
<\/div>\n
<\/div>\n

Previously, REZN8 had produced a 3D model of\u00a0<\/span>Sydney<\/span> for the Paralympic Marathon. This model had a line moving through the city growing as the athletes moved. This line extended at a constant speed and
\nhad to be adjusted by hand as the race progressed. A photo of these graphics can be found in figure 1.<\/span><\/p>\n

For this presentation we decided that extending this concept to the next level \u00f1
\nAdding live wireless GPS data for dynamic generation of graphics.<\/span><\/p>\n<\/div>\n

 <\/p>\n

 <\/p>\n

<\/div>\n

 <\/p>\n

 <\/p>\n

\n

 <\/p>\n

\"\"<\/h2>\n

 <\/p>\n

Figure\u00a01<\/span><\/span>
\n– 3D Animation of Sydney Paralympic Marathon<\/span><\/center><\/p>\n

\n<\/div>\n

 <\/p>\n

 <\/p>\n

\n

The Concept<\/h2>\n
<\/div>\n
To give
\nthe demonstration some appeal, we needed a gimmick \u00f1 and the obvious gimmick
\nwas with the object that we were tracking. After looking at a few options
\nwe settled on children\u00eds scooters that have become popular recently.\u00a0<\/span><\/div>\n
<\/div>\n
We decided
\nto have two people race the scooters outside the venue of our demonstration,
\nwhilst being tracked on a video screen inside. To make the race a little
\nmore exciting, one of the contestants took a somewhat shorter alternate
\nroute.<\/span><\/div>\n
<\/div>\n
During
\nmost of the race the only image shown was a live 3D representation. At
\nthe end, closed circuit television was used to show that this was not faked.<\/span><\/div>\n

Tracking the scooters<\/h2>\n
<\/div>\n
GPS
\nwas used to track the scooters. This was not ideal for low speed vehicles
\nin close proximity but it performed well enough.<\/span><\/div>\n
<\/div>\n
In order
\nto operate flawlessly we had already chosen radio transmitters with a 50W
\n(max) power output so that we could gain range and cut through any interference
\nexperienced.<\/span><\/div>\n
This
\nwas important as the original concept called for tracking cars over a larger
\narea where the power would be needed for the range.<\/span><\/div>\n
<\/div>\n

The scooters
\nwe ultimately decided to use for the demonstration were the larger battery
\npowered units. But with these units we had the problem of where to mount
\nthe radio, GPS and controller. We found that if we removed the internal
\nbattery, making the scooters self powered, we could mount most of the equipment
\nin the battery compartment.<\/span><\/p>\n

Equipment<\/h2>\n
<\/div>\n
We decided
\nto use Kenwood D-700 transmitters with integrated TNC\u00eds as they were tightly
\nintegrated making them less likely to fail. The radio was connected to
\nan AISIN GPS receiver purchased surplus as well as to a custom controller
\nfor triggering transmissions. These three objects were mounted in the now
\nempty battery compartment.\u00a0<\/span><\/div>\n
<\/div>\n
With
\nthis much equipment in the battery compartment there was no room to mount
\na battery with the equipment. We eventually mounted a 7 AH battery on the
\nback of the scooter with Duct Tape. [If we had been allowed to make major
\nmodifications we could have fit the battery in, but our sponsor wanted
\nto give the scooters to his children after the demonstration]<\/span><\/div>\n
<\/div>\n
The
\nD700 front panel was mounted on the handle bars, along with the GPS antenna.
\nA small magnetic mount was also mounted on the handle bar column.\u00a0<\/span><\/div>\n

With the
\nD-700 in POSITION mode, this made the scooters the ultimate toy with the
\nGPS based speedo function. Several people we showed the scooters to believed
\nthat we should just sell these and make a killing \u00f1 even more so when they
\nrealized that they would know where their children were at all times.\u00a0<\/span><\/p>\n

Technical Implementation<\/h2>\n
<\/div>\n
In order
\nto track the scooters in near real time, we needed to have the D700 transmit
\nat least every 2 to 3 seconds. Every second would have been better, but
\nevery 2 to 3 seconds was acceptable. Unfortunately the quickest beacon
\nrate of the D700 is 10 seconds, which is enough for most applications,
\nbut not ours.<\/span><\/div>\n
<\/div>\n
The
\nD700 radio has a GPS port for parsing GPS data in many formats. In TNC
\nmode, there is a command called LTMON which allows the GPS data tobe
\nmonitored automatically on the serial port. For instance when the command
\nLTMON 3 is issued, GPS data will be sent to the serial port every three
\nseconds.<\/span><\/div>\n
<\/div>\n
The
\nGPS data is returned in a string starting $PNTS, a proprietary format designed
\nby the makers of the chipset in the Kenwood radio. Since our application
\nwas for customized receiving software, any line starting $PNTS was simply
\nsent over radio using converse mode.<\/span><\/div>\n

We implemented
\nthis using Rabbit Semiconductor microcontrollers attached to their development
\nboards. In a production environment we would probably choose a different
\nprocessor.<\/span><\/p>\n

Data Reception<\/h2>\n
<\/div>\n
The
\nreceiver was a Kenwood TM-251 radio connected to a Kantronics KPC9612 TNC.
\nSince we were only receiving at 1200 bps, both these pieces of equipment
\ncould have been downgraded but allowed for reconfiguration if required.<\/span><\/div>\n
<\/div>\n
The
\nTNC was connected to a 150 foot CAT-5 serial cable onto a stage where the
\ndemonstration of this technology was taking place.\u00a0<\/span><\/div>\n
<\/div>\n
In the
\nfield,a D7 handheld with internal
\nTNC was used to monitor the performance of the scooters so that we could
\nfix any problems. After operating perfectly for a few days before hand,
\nwe actually needed to reprogram one of the TNC\u00eds just before the demonstration.<\/span><\/div>\n

Server Software<\/h2>\n
<\/div>\n
The
\nserver was responsible for reading GPS data from the rs232 connection,
\nprocessing the input stream and separating the two streams of data. The
\nsoftware also moved the GPS coordinates into the coordinate system used
\nby the 3D model \u00f1 by stretching, rotating and scaling the coordinates.
\nIt also acted as a TCP\/IP server for clients to connect to.<\/span><\/div>\n
<\/div>\n
We extended
\nthis a bit during testing when we found that GPS data was not a perfect
\nmatch for a small vehicles on a short race \u00f1 so we placed a model of the
\npath into the server as well. This allowed us to use least squares approximation
\nto find the closest point on the path to the GPS data if required.\u00a0<\/span><\/div>\n
<\/div>\n
It also
\nallowed us to build extrapolation for the GPS data to remove the jerks
\nin movement \u00f1 which is important when video moves as 30-60 frames\/second,
\nand the GPS data was arriving at 3 second intervals.<\/span><\/div>\n

Having
\na server allowed us to run more that one client displaying the graphics.
\nThis was important since we were beta testing hardware for the highest
\nperformance. It also allowed us to tune the incoming data to the format
\nrequired by the graphics engine client software. We could also play back
\nGPS data to the clients in case of system failure.<\/span><\/p>\n

Client Software<\/h2>\n
<\/div>\n
For
\neach valid data point, the server processes the data and sends to the client.\u00a0<\/span><\/div>\n
<\/div>\n
The
\nclient, programmed in C++, allowed for dynamic control of the viewing location
\nwith the keyboard and mouse. The controls included pan, tilt, zoom etc.just
\nas if this were a real camera. The client also stored a copy of the 3D
\ndatabase as well as the Maya 3D real time graphics engine.<\/span><\/div>\n
<\/div>\n
This
\nsoftware required a copy of the 3D model on the local PC to improve processing.
\nThe software that we wrote has the potential to revolutionize the GIS industry.<\/span><\/div>\n<\/div>\n

 <\/p>\n

 <\/p>\n

\"\"Figure\u00a02<\/span><\/span>
\n– LA before zooming into the venue <\/p>\n

<\/center><\/p>\n

\n<\/div>\n

 <\/p>\n

 <\/p>\n

\n

Computer Modeling<\/h2>\n
<\/div>\n
Whilst it is outside the scope of radio, creating a 3D model of the area is probably the most important task of this exercise. I am detailing it here to give an idea of the sheer amount of work involved at the moment.<\/span><\/div>\n
<\/div>\n
The first step was to commission some aerial photography, of the whole area of interest in general, and closer up images of the area of the demonstration. These photographs were provided as large (200+ Mbyte each) TIFF files. Using the 3D Studio Max and Maya we were able to create a seamless transition so that when we zoomed into the area of interest, the higher resolution image was inset. Figure two shows these files.<\/span><\/div>\n
<\/div>\n
Although this only created a 2D representation of the area, looking onto the map side on did look 3D until zoomed in close. This is when the magic really happens.\u00a0<\/span><\/div>\n

With the 2D representation as a backdrop, the REZN8 artists created a 3D model of the local area by hand. This involved adding everything from roads to buildings and letter boxes.\u00a0<\/span><\/p>\n

This work was assisted with lots of photographs taken from ground level as well as some artistic license. This sort of effort is quite labor intensive, and not the sort of task to be undertaken lightly.<\/span><\/p>\n

<\/h2>\n

Discoveries and Challenges<\/h2>\n
<\/div>\n
When we started analyzing the problem of viewing the data we came across the height information from the scooter \u00f1 or more correctly found that the GPS sentence that we were using did not contain height data. Upon analyzing the problem, we worked out that the height data was not useful to us anyway.<\/span><\/div>\n
<\/div>\n
The height data from GPS contains a higher error than the latitude and longitude. More importantly, in most cases when visually modeled, the height data needs to be the most accurate. It is not easy to tell if an object is one meter too far to the left or the right, but it is very easy to tell if they it is one meter off the ground, or embedded one meter into the ground.<\/span><\/div>\n
<\/div>\n
When we thought about the problem, there was one obvious solution \u00f1 we should always have the moving object at exactly ground level. Since scooters do not fly despite what you may have seen in\u00ebBack to the Future\u00ed, this was perfect.<\/span><\/div>\n

The GPS receivers that we were using performed extremely well in most cases. However they do not like to change hemispheres of the world without a hard reset. We spent well over an hour on top of a\u00a0<\/span>Hollywood<\/span> car park before discovering this.\u00a0<\/span><\/p>\n<\/div>\n

 <\/p>\n

 <\/p>\n

\"\"Figure\u00a03<\/span><\/span> – Local area with single object being tracked near the entrance to the dome building.<\/center><\/p>\n

\n<\/div>\n

 <\/p>\n

 <\/p>\n

\n
<\/div>\n
<\/div>\n

Conclusion<\/h2>\n
<\/div>\n
Our demonstration of this technology was successful, with all those who saw it leaving very impressed. We have once again shown that the resources needed to produce the type of graphics described are significant, even on such a small scale.\u00a0<\/span><\/div>\n
<\/div>\n
Having said this, we believe that it will soon be possible to integrate real time 3D graphics with real time GIS data from systems such as APRS without having to dedicate so many resources.<\/span><\/div>\n
<\/div>\n
We have shown what is possible. The challenge now is to improve it and decrease the cost.<\/span><\/div>\n

\n<\/div>\n

\n

<![if !supportEndnotes]><\/p>\n

\n

<![endif]><\/p>\n

\n
<\/a><![if !supportFootnotes]><\/a><\/a><\/a><\/a><\/a>[1]<\/a><\/span><\/span><![endif]><\/span><\/span><\/span>
\nREZN8 is a\u00a0<\/span>Hollywood<\/span>
\nbased studio specializing in visual effects for film and television, commercial
\nproduction, internet design and programming, interactive presentations,
\nas well as\u00a0hardware and software
\nintegration. For more information visithttp:\/\/www.rezn8.com<\/a><\/span><\/div>\n
<\/div>\n<\/div>\n
\n
<\/a><![if !supportFootnotes]><\/a><\/a><\/a><\/a><\/a>[2]<\/a><\/span><\/span><![endif]><\/span><\/span><\/span>
\nRadioactive Networks is an engineering consulting based in Sydney Australia.
\nSpecializing in wireless networking solutions.<\/span><\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

APRS in Hollywood   APRS in Hollywood   Integrating Real Time 3D Graphicswith Wireless GPS systems.   <![if !supportMisalignedColumns]><![endif]> Phil Brock Senior Graphics Programmer REZN8,\u00a0Hollywood,\u00a0CA,\u00a0USA. Pbrock@silcom.com Bill Kovacs Chief Technology Officer REZN8,\u00a0Hollywood,\u00a0CA,\u00a0USA. Bkovacs@rezn8.com Darryl Smith, VK2TDS Radioactive Networks, Sydney,\u00a0Australia Darryl@radio-active.net.au …<\/p>\n

APRS in Hollywood<\/span> Read More »<\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"parent":116,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"jetpack_post_was_ever_published":false,"footnotes":""},"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/P5cfmK-2g","_links":{"self":[{"href":"http:\/\/www.radio-active.net.au\/web3\/wp-json\/wp\/v2\/pages\/140"}],"collection":[{"href":"http:\/\/www.radio-active.net.au\/web3\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.radio-active.net.au\/web3\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.radio-active.net.au\/web3\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/www.radio-active.net.au\/web3\/wp-json\/wp\/v2\/comments?post=140"}],"version-history":[{"count":2,"href":"http:\/\/www.radio-active.net.au\/web3\/wp-json\/wp\/v2\/pages\/140\/revisions"}],"predecessor-version":[{"id":143,"href":"http:\/\/www.radio-active.net.au\/web3\/wp-json\/wp\/v2\/pages\/140\/revisions\/143"}],"up":[{"embeddable":true,"href":"http:\/\/www.radio-active.net.au\/web3\/wp-json\/wp\/v2\/pages\/116"}],"wp:attachment":[{"href":"http:\/\/www.radio-active.net.au\/web3\/wp-json\/wp\/v2\/media?parent=140"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}