AR Wave
Purpose: To provide an open, distributed, and universally accessible platform for augmented reality. To allow the creation of augmented reality content to be as simple as making an html page, or contributing to a wiki.
Specific Goal: To establish an open, standard, method for geolocating digital data in physical space (or linking it to physical objects) using wave as a platform.
(For justification as to why we are using Wave see: our faq )
Wave as a platform
We are developing on the PyGoWave server at the moment but the goal is to be compatible with all Wave servers
PyGoWave has already achieved an important aspect in enabling the project in being a waveserver with a working and well documented server protocol. This allows both standalone and webbased clients to interface with it already. See - The PyGoWave Qt-Based Desktop Client
This is one of the reasons why we have chosen to develop for the Pygo server at this stage.
However, the overal goal of AR Wave is to have a framework compatible with all servers using the Wave Federation Protocol. As more wave servers get c/s protocols then ARblips (the data needed to geolocate objects) could be posted and retrieved from various servers using the same client software. For this a standard should emerge. Just as websites don't have to be hosted on specific servers, neither should AR data need to be hosted on specific wave servers.
In order to reach our goal, there are a few very achievable steps involved - see below.
FeedbackWe meet weekly on irc://irc.freenode.net/#arwave
We are still actively seeking feedback, so feel free to join the Wave discussions, and see the history of how the specifications of the protocol evolved. You can also read the justification for some of the choices already made. Note a new discussion for AR DevCamp will be begin at AR Wave: AR DevCamp Session
This will, of course, only be the first draft of the specification, and it is sure to develop much in future.
The important thing now is to make working prototypes while maintaining flexibility.
So what do we need to do?
Steps :
* Establish the overall method - Done.
Each Wave will be a layer on reality which an individual or a group can create. Each Blip in this Wave refers to either a small piece of inline data (like text) or a remote piece of larger data (like a 3D mesh) as well as the data needed to pin-point it in either relative or absolute real space.
We call these blips: ARblips. They are simply blips that stored the data necessary to augment a single object onto a specific bit reality.
It is up to the clients how they interpret and display the data. They could interpret it as a simple 2d list of nearby objects, or as an advanced 3D overlay, whereby multiple waves from different sources could to be viewed at once. What’s important is that there is a standard way to link the digital data to the real world space.
* Establishing the specification for the ARblip - In progress
We have a good idea of what’s needed to be stored in an ARblip, and we have hammered out a rough format.
The data might be stored as blip-annotations, but this has yet to be finalised.
A rough outline of the type of data stored can be seen in this c++/qt header for ARblip data can be seen at the end of this document.
* Storing and retrieving these pieces of ARblip data on the PyGo server - In progress.
The Pygowave team has made some excellent libraries that should make reading and writing data on the PyGoWave server very trivial for those with c++ skills.
This, however, is a real critical step, so more developers with C++ skills are very welcome!
* Making the above client mobile, and using a devices gps device to place the data. - Not started.
The next step would be to port the code to a mobile phone and use it's gps-input to post geolocated data and view what others have posted. This would be a fairly simple and not to useful app in itself. However, it would mark the first time anyone could post AR data and anyone could view it, all using open-source infrastructure.
As a bonus, because we are using wave infrastructure, the updates to any ARblip should appear in near realtime.
* To continue with the proof of concept, we would like to have simultaneous wave input from a PC
and mobile phone at the same time. - Not started.
For example, someone could post a pin on Google maps API and have that data posted to a ARBlip in a wave. Someone logged into that wave on their mobile device would then see the data posted appear.
More so we hope that when the Google map pin is dragged about, the mobile phone viewer, with just a few seconds lag, will see its location updated in real time.
We hope to make a modest yet practical app at this stage.
* After all this, we can go onto the interesting things:
3D data, camera-overlays, data fixed to objects and many more. There's plenty of existing software using these features (such as Wikitude, Layer) and some that are even open source software (like Gamaray and Flashkit). The open source code can give us a leg-up. However, we prefer to establish the protocol first. So naturally, these fancy features aren't a priority for us. Rather we think our energy is better spent establishing the protocols and infrastructure so that other people can build more advanced bit of software easier.
However, once our primary goals are established, we will look to make a open source augmented reality browser ourself which will surely feature many of these features.
Overall, we hope once we have a simple proof of concept, there will be many groups, both existing and new, wanting to use this Wave system for their own apps, games and data.
Conclusion:
Really it's now all about growing the community. We hope as soon as we show how great Wave can be for augmented reality, that lots of individuals and teams will start making their own clients to read/write geolocated data.
Overall we don't think anything we make will be that impressive in itself. That's not our goal.
We instead hope that our project will enable AR-content to be made as easily as web content. That games, information and apps will be able to be created without the creators having to worry
about the infrastructure behind it.
Technical information -
Current ARBlip header file
(below is a c++/qt header file for an ARBlip object that should illustrate the data being stored)
class arblip {
public:
arblip();
~arblip();
arblip(QString,QString,double,double,double,int,int,int,QString);
QString getDataAsString();
QString getEditors();
QString getRefID();
QString getXAsString();
QString getYAsString();
QString getZAsString();
bool isFaceingSprite();
private:
//ID reference. This would be a unique identifier for the blip. Presumably the same as Wave uses itself.
QString ReferanceID;
//Last editor(s)
QString Editors;
int PermissionFlags = 68356; // default 664 octal = rw-rw-r--
//Location
double Xpos; // left/right
double Ypos; // up/down
double Zpos; // front/back
//Orientation
// names, ranges and directions are taken from aeronautics.
// If no orientation is specified, it’s assumed to be a facing sprite.
// Roll: rotation around the front to back (z) axis. (Lean left or right.)
// range +/- 180 degrees with + values moving the objects right side down.
int Roll;
// Pitch: rotation around the left to right (x) axis. (tilt up or down)
// Range +/- 90 degrees with + values moving the objects front up. (looking up)
int Pitch;
// Yaw: rotation around the vertical (y) axis. (turn left or right.)
// range +/- 180 degrees with + values moving the objects face to its right.
int Yaw;
bool FacingSprite; //if no rotation specified, this should default to true
//if set to true when a rotation is set, then it keeps that rotation relative to the viewer
//not relative to the earth.
//Data format
QString DataMIME;
QString CordinateSystemUsed; //The co-ordinate system used. This should be a string representing a Open Geospatial Consortium standard. This could be earth-relative for gps co-ordinates, or in some cases relative to the viewer, for data to be displayed in a HUD like style.
//Data itself
QString Data;
QString DataUpdatedTimestamp; //Time the Data was updated changed
//Note; A seperate timestamp should be used for updates that dont effect the data itself.
//(such as if a 3d object moves, but its mesh isnt changed)
//Data metadata
QMap<QString, QString> Metadata;
};
Uploading ....