Slashdot Mirror
DIY Augmented Reality Heads-Up Display
mkwan writes "A PhD student in Melbourne, Australia, has built an augmented reality head-up display using a baseball cap, an Android smartphone, and off-the-shelf optics. It won't win any awards for style or practicality, but it's a fun way to use Wikitude. All we need now is a Terminator-vision smartphone app."
Not nearly as modern, but vaguely related: the Private Eye P4.
Okay I really don't see the story here. How is this better than App Blaster?? Other than making you look like a dork and attracting bullies I mean???
It must also augment his reflection in the mirror if he thinks he should go outside with a smartphone and a block of styrofoam taped to his hat.
1. Make mountable earpiece with technician one-ear headset.
2. Link lens to single eyepiece.
3. HUD app.
4. Make deliberately fragile and cheap.
5. Infinite business as geeks the world over keep buying them to crush while screaming that it's over 9000.
He could have reduced the CV value of the gear if he didn't use double mirroring - i.e. the phone could be horizontal, screen down. One fewer mirror is better quality. Software can mirror the screen contents (I tried an Iphone in a similar setup, using the car windshield as the mirror). As a next project, the camera could continuously monitor the user's eyeballs and determine where in the real life and on the screen he is looking at, including depth! Also, whenever an image is shown on the screen to augment reality, the phone uses not plain images but light field camera (Lytro; might go on the hat too) pictures so it can be refocused as the user's eyes indicate various depth. Stuff like this becomes almost practical: http://vimeo.com/timoarnall/light-painting-wifi and add CMU Johnny Chung Lee's techniques for depth simulation (http://www.youtube.com/watch?v=Jd3-eiid-Uw&feature=player_detailpage#t=165s) and motion tracking (Minority Report). Maybe for better precision, use some laser light to determine the focus depth and exact direction the user looks at. Then Apple should blow 10Bn on converting the entire gear into one fashionable eyepiece, that doubles as sunglasses, available with a black or - much later - white frame. _That_ will bring the CV value down.
This is the same guy who wrote the partially completed android X11 server that was posted on /. recently. I didn't see the story there either. I mean, it was impressive that he had implemented most of X11 by himself, but a fully featured x11 app already existed on the market ( here), so I don't consider it newsworthy.
/.'s front page?
How does his blog keep getting on
You can never know everything, and part of what you do know will always be wrong. Perhaps even the most important part.
Have ask what 'You don't say (so)!' think It is a pus to think such Christ alive!
Obviously.
You're preaching to the choir here buddy.
Do you understand VNC? That app works by rendering everything to an offscreen framebuffer in RAM, then VNC copies it into a separate process's RAM (I presume directly into the display framebuffer). This means no hardware acceleration for the X server, and some battery-draining CPU load for copying the pixels. It gets particularly bad if you attempt e.g. video playback, where the normal flow is sending YUV (or similar) data directly to the video card, which handles scaling and RGB conversion in hardware, and X/VNC requires software RGB conversion, software scaling, blitting to the X framebuffer, and copying to the display.
A native X server like we have on the HP touchpad will at least address the wasted CPU usage; I'm not sure it's feasible to provide hardware acceleration in either case (you'd need to implement an OpenGL ES proxy, something like XDMX or chromium). This, of course, is where Maemo/MeeGo shines with native X support, but a proper X server for Android will at least reduce the penalty.
that was my plan for the raspberry pi. but i'd make it look good
...and the the first thing he looked at WASN'T porn. Which would be a first for any new display technology
I guess the whole point of it is to say that it is rather easy to create a (although perhaps rather ugly) HMD. Which is nowhere for use by common folk. The whole point of it proving that there is no real excuse for there not to be on the market other than no demand for it.
Say what you want, but he at least managed to get it working. Which I didn't, and I haven't seen somebody selling one of those.
I don't care if I'm wrong. I only care about everyone obtaining something from the discussion.
Seems like augmented reality has been a popular research area in Australia for a while. At LCA a few years ago there was a presentation by another PhD student on his AR project and I even got to try out the gear (somewhat bulkier than this latest one though):
http://www.tinmith.net/
While his project is cute, there are already commercial solutions that are pretty much the same thing.
P.S. I am not responsible if you decide to AR while biking on real roads...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Does it have to be a baseball cap? Can I have mine in a propeller beanie or a leopard-skin pillbox hat? Maybe a motorcycle helmet because you know I'm going to be crashing into all kinds of stuff trying to ride my bike while I play Counter-Strike on this thing.
You are welcome on my lawn.
This is something that is a bit puzzling to me, surely now we have all the required technology to make AR as common as smartphones?
Take a smartphone, create genuinely useful and interesting software, add a stylish minimal heads up display in a pair of glasses and eventually contacts or laser retina scanner, add some sensors and a camera and we have everything we need, this all exists today but hardly anyone seems interested in developing a proper setup and selling it with a smartphone, i believe it will be the next big thing after mobile phones and the internet, when the world meets the virtual there's a lot of possibilities.
not augment it, but then I realized that it would just go faster and faster the longer I was in it. That's when I decided to go back to bed.
Please do not read this sig. Thank you.
Yes I understand the difference between VNC and X11, but for the typical android phone/tablet use case of using wifi x11 tunnelling over ssh to a remote server running X apps, none of the performance issues you mention (hardware acceleration, video streaming) are relevant at all.
Both the "native" X11 server and the "fake" X11 in a VNC session will have essentially the same performance it that situation.
You can never know everything, and part of what you do know will always be wrong. Perhaps even the most important part.
I'm fairly certain that's not the typical use case at all. The typical use case AIUI is a debian or ubuntu install in a chroot on the tablet. If you're running the app remotely, wouldn't you just use NX, and get better performance than X11 for WAN latencies?
And again, copying pixels between processes -- it won't be a big slow-down on modern devices, but it will keep the processor busy when it should be idle, and that means it costs you battery life... maybe this is just something we disagree on, but IMO that alone makes a native implementation /.-worthy.
It's sloppy, it has no "value," it will not win awards,.... and that is how progress is made. Value is he went and built something, unlike everybody else simply buys. He has an idea, ideas are a time a dozen, and he created something of substance and that takes time and expense. During that time, he learned what works, what doesn't work, and what parts and tools needed to build things.
I've been going through something similar of packaging 900MHz amateur TV transmitter and a receiver in a box for field use. Sounds simple but somehow video signal is losing horz sync, it might be some bad connections and it has been a pain in the ass to find. Particularly I don't know anyone with complimentary devices for me to test my signals. Everyone else says just go iPhone, no need for ATV. But they missed the point because I want something I can fully control without subscriber fees, EULAs, etc. Of course to really do it like real men, design a circuit from scratch (but very few in USA can do that nowadays).
mfwright@batnet.com
This application implements a mostly-complete X11 server, running natively in Android. It allows X Window System applications to be run remotely and displayed on an Android device with internet access.
(bolding mine) which is why I assumed most people used it for ssh tunneling.
You may want to run the app remotely rather than NX for many reasons - accessing data or controlling hardware on a remote server for example. Your point about copying pixels between processes is certainly correct for your use case of a local chrooted OS install. However, for my ssh tunnelling use case, I'm not sure I agree, because the VNC pixel copying and X11 rendering occurs on the remote server, so doesn't cost battery life on the client device - what is sent to the mobile device to be displayed is essentially a partial jpg image. A mouse moving would only cause the pixels effected by that movement to be sent and modified. For this use case - it might be the native x server that uses more cpu - since it has to interpret and render the X11 protocol using a more complex algorithm. It would certainly be borderline as to which technique uses more power on the client device, I think it would depend on the using patterns, and I don't think it can be said that one technique uses more power on the client device in all cases.
You can never know everything, and part of what you do know will always be wrong. Perhaps even the most important part.
I find your statement intriguing, and would like to subscribe to your newsletter.
Jesus saves... the rest takes full damage.
The first line in the description of the native X server app is
This application implements a mostly-complete X11 server, running natively in Android. It allows X Window System applications to be run remotely and displayed on an Android device with internet access.
(bolding mine) which is why I assumed most people used it for ssh tunneling.
Fair enough. Maybe that's more common than I thought. I had no clue it said that, because of course I didn't RTFA. ;)
You may want to run the app remotely rather than NX for many reasons - accessing data or controlling hardware on a remote server for example.
NX is running it remotely -- it's a remote-desktop technology based on X that generally does better than X11 WRT latency and better than VNC WRT bandwidth -- it's generally considered the best of the three, at least for typical WAN connections.
Your point about copying pixels between processes is certainly correct for your use case of a local chrooted OS install. However, for my ssh tunnelling use case, I'm not sure I agree, because the VNC pixel copying and X11 rendering occurs on the remote server, so doesn't cost battery life on the client device - what is sent to the mobile device to be displayed is essentially a partial jpg image.
Except what you're discussing doesn't correspond to the X/VNC app you linked -- that app runs both a local X server and a VNC client, so you get X protocol coming to the device, rendered by the server, then copied across to the VNC client. What you're describing here (which is a reasonable enough option), is what you get if you run a remote VNC server, and run only a VNC client (not that X/VNC bundle) locally. I agree that VNC alone might well have lower power than X11 alone, but either one will be lower power than running both of them on the tablet, which is what the app you linked does.
if I could build one of these into my motorcycle helmet & have Google Nav on my face shield