Panono: Panoramic Ball Camera - General Accessories

Hi there,
Some of you might have already noticed our project, a ball shaped camera you can throw into the air to capture a fully spherical panorama. We are currently running an Indiegogo crowd funding campaign to raise the funds needed. We see that many campaigns nowadays launch with apps, usually only iOS and most of them don't really put much effort into their apps. We want to go a different way as I am a long member of xda-devs and include the community into the app development. As the camera is supposed to be used with a smart phone or tablet, the app is essential for the Panono.
So what does our app actually do? Well, you can re-experience the situation captured with the Panono camera by navigating the 360x360 panoramas by moving your phone/tablet like a window into the captured moment. If my English failed to make it understandable, please have a look at the video starting from 1:22.
We are facing a problem with our app which is caused by the different implementation of the gyroscope sensor reading in different phone models. Unlike on iOS, only few Android phones have a correct algorithm to calculate the current device orientation. The result is a shaky experience in our app. We are trying our best in optimizing our app to work with all devices. To address this issue, we are also having a talk at droidcon in Stockholm right now.
So what help are we seeking right now?
We need people who have a android phone with built-in gyro test the app. The following feedback would be interesting:
Device model: (e.g. Samsung S4)
Shakyness: (e.g. image is jumping around but the orientation is correct)
Lag: (e.g. it takes a while until the correct orientation is displayed)
Jumps: (e.g. the orientation jumps into some random direction for a few frames and returns to the right direction afterwards)
You can get the app here: https://play.google.com/store/apps/details?id=com.panono.panonoviewer
If you have any question about the Panono as the next-gen accessory for your android device, you can also post here, of course.
Thanks!

Related

[APP][ALPHA] G Force Logger for Vehicle Performance (no, not gPC)

Hi, my name is Eric. I've been working with WinCE for a long time (since WinCE 2.0 haha) and I've regained interest in PPC programming. Working with few things here and there, mostly experimenting.
In anycase, I've got an idea to record g forces on a vehicle while it's being tested to its limits (AutoX, drag race).
Now, I know there's already a piece of software out there, gPC, but it isn't completely refined (indepth calibration, angle corrections) or completely free (by donation).
The goal of the project is to create something similar to a device called gTech which goes upwards of $300 for the basic model.
Key features will include:
- a reset function + algorithms to compensate for device orientation
- graphs of resulting logged data
- logging of calibrated data and raw data
- Driving aids
- Flashing screen to indicate reaching of new peak G (separate indicators for forward and lateral)
- a screen showing realtime overlapping graphed data for all axis
- a 2d grid with a cursor indicating current forward and lateral g
- on the same 2d graph, a drawn boundary indicating limits of g achieved (this will eventually look like an egg after working the car hard)
- and finally, real time telemetry transmission via edge/3g to a receiving computer
The ultimate goal of this project is to provide reliable data for motor enthusiasts whether they would like to see if their shifting is smooth, or if they're braking, or powering on in the right places or if their car mods have had any effect (this last one is pretty useful to quantify). In addition, provide some rudimentary tools to assist in competitions and spirited driving in the form of g limit warnings (flashing screen, large indicators of current g). In the case of spirited driving on a mountain road, the device can warn when approaching loss of traction (after collecting limit data) to prevent going off a cliff.
Venues of use:
Auto Cross
Track Days
Drag Strip
Skidpad
Of course, I have to insert here, that this device can't save your bacon if you do something idiotic and by no means do I condone dangerous driving.
With that said, all the above is what I hope to achieve and any of your comments is well appreciated.
Current Release:
v0.1
Alpha stage, rudimentary raw data output via numbers and a line (indicating X and Y recorded g) and a circle (indicating Z g). The numbers shown are the raw numbers recorded from the accelerometer and not converted to m/s^2. Although, you can probably do that math on your own if you're smart enough (simple scaling). What I've discovered is that each accelerometer is different, and even going from a negative axis (eg, device upside down) to positive axis (device right side up) will give different numbers. In addition, if you run the program, you'll notice a lot of jitteriness. I hope it doesn't affect the accuracy once I smooth them out with a segmented average.
Executable is packaged in a zip. It contains an EXE which can be straight run with Dot NET CF v2.0 (basically, all WM 6.1 devices)
Hi Canagan,
Great idea, I will certainly be testing this out.
I would like to ask, would it be possible to be able to include 1/4 mile time, and 0-60 etc so we can work out HP of the car. There is a similar app for the Iphone called Dynolicious http://gizmodo.com/5030749/iphone-apps-we-like-dynolicious-car-performance-meter
Thanks.
Whoooaaa sound a really good app ! Will test it this weekend ! Thanks
PooleyUK said:
I would like to ask, would it be possible to be able to include 1/4 mile time, and 0-60 etc so we can work out HP of the car. There is a similar app for the Iphone called Dynolicious http://gizmodo.com/5030749/iphone-apps-we-like-dynolicious-car-performance-meter
Click to expand...
Click to collapse
Yes, I can do that if there's more of a demand for it. Calculating horsepower is fairly simple, however, I may put 1/4 mile times and 0-60 towards the end of development as they require tieing into the GPS.
Great idea.. I will test it also
It seemt to be working on my Touch HD. But are the meaning of all these numbers??
CanaganD said:
Yes, I can do that if there's more of a demand for it. Calculating horsepower is fairly simple, however, I may put 1/4 mile times and 0-60 towards the end of development as they require tieing into the GPS.
Click to expand...
Click to collapse
Cool, looking forward to seeing this develop.
So far the accelerator test seems to be working fine.
would be need ive i could see how many hp mycar has

Project coming soon (prop 215 app)

Well I am interested in developing an app but would like to gauge some interest. Here are the details of the app:
1. App will take advantage of built in light sensors to read your lights lummens output.
2. App will have a nutrient calculator based on (advanced Nutrients, Canna, Dutch Masters, and General Hydroponics)
3. App will also include nutrient charts for all the companies.
4. App will include a DB of pictures with descriptions of different plant diseases and deficiencies.
I have more ideas as well as in how to optimize air flow for your room and much more also will include for outdoor growing as well.
If your interested in seeing an app like this for our winmo phones let me know through this thread and i will post updates and beta versions once they are ready if there is enough interest in something like this.
Sounds nice. Good luck.
seems good,
later i will be doing some project may be i can seek you help then
It seems nice
can be useful
All the best
it is coming along. right now the strain app supports WVGA 480 x 800 resolution. follow my progress in the thread in my sig. I should be about a week away for the MJ's Strain Guide beta. all that is posted right now is an alpha so you get a feel for the UI. Still a lot to do.
Sounds good! Being completely crap at maintaining plants this seems quite useful
I know what you mean. I hope this app helps guide people but when it comes down to it a major factor in your outcome is the genetics. bad genetics of a good strain will give you bad results. i am attaching here a alpha version of my strain app. its also located in the HD2 app section. im not sure it will work on other phones as i have a hd2 right now. I due plan to port to other resolutions and sizes after completion. It will be easier as its just resizing of what i have done. I am also bringing in some friend to port the app to android and iphone/ipad and to make a windows pc based version. if anyone has suggestions or think they can help in anyway let me know. i can always use the help.
PS:
This is the 4th app i have ever made in my life.
Notes:
when app is installed and launched you will get pop up menus. These are due to the controls. Currently they are trail controls. I am sending a payment to get the full license to that will be removed by beta.
currently all list are populated but no data is inputted so when you try to launch a strain in kinetic scrolling it will do nothing. Only one works right now. It is located in Sativa Strains List. It is Cannalope Haze. Let me know what you think of how the data is displayed. If you install this on WVGA device 480x800 it should work so HD2/TP2 should look perfect. Let me know what device you have it installed on and your screen fitment issue only if its WVGA. QVGA and WQVGA are not supported.
enjoy!!
Update:
I have attached a newer version it is the latest i have made so far. I have updated the indica and sativa list and updated how the data is displayed for cannalope haze. The way the cab is made is different so now it will ask if you want to install on sd or phone. I also finally added an icon for the app. i still have a long way to go but i hope you like where its going.

[App] Simple Audio Analyzer (WIP)

This is something I started dabbling on while trying out various SDK things, but continued developing on after first tests. Still work in progress, but it works good enough.
It's a simple application that captures from the phone's microphone and presents the recorded data either as FFT graph, waveform or displays it as SPL/peak/RMS volume meter with graphical history function.
I've put already an earlier show-off on Youtube, but I was on a coding roll, this is a newer (unlisted) demo. Irregularities in the displays are caused by a confirmed bug in XNA.
http://www.youtube.com/watch?v=F7M6qUU3fuM
(Uploaded it a few minutes before this post, video quality will improve.)
Looks cool! Will it work in landscape also?
Hey Tom. You made some good points on Anton D. Nagy's blog, but I reckon it could be optimised. Right now it's very pretty, to attract buyers (e.g. me!) you'll need to provide something really useful. This could include things like highlighting clipped samples, recording to isolated storage or even integration with the Zune hub.
How many frequency bands are you managing with the FFT? For the purpose of a phone you could keep it to 128 or even 64 and save processing power. You're right about needing a dev device to really know.
Good luck, I really like what you've done so far.
I could swear I had already written up something and it seems gone.
Anyway, the app's going to be free, so no need to entice buyers, since there won't be any.
Also, the main intent of the application is to capture ambient sounds/noises and get a visual representation. And since I want to keep it as simple as possible, I'm probably going to leave it at that.
Your comments however gave me the idea to write a simple recorder, that does an audio display with zoom and cursor on both waveform and FFT representations. I don't think applications will be able to directly open something outside their isolated storage, so loading music from your phone will probably not be possible, apart from making a media player proxy play back stuff.
Looks great..very impressive.
I'm tinkering with the same API although I'm a real novice and wondered how you were managing to get at the data being picked up by the microphone in apparent real-time.
I wonder if you would be good enough to let me into some of your coding techniques or point me at some good reference docs/samples I've obviously missed
The code samples I've seen up to now have start record and stop record buttons, with a buffer being filled up over that time period and finally played at the end.
I'd like to do how you managed to process and graph the data as it is picked up by the mic. Are you possibly setting the buffer size very small and just getting small chunks of data and then acting on it - accepting the potential delay in buffering and then processing - maybe the delay is smaller than I'm expecting? or is there some other technique I'm missing from the docs.
Thanks in advance.
Ian
The recording code works practically the same as you'll find in the samples. Signal processing happens on the BufferReady event, which calls respective processing functions. I've set the buffer size to 100ms, which is the minimum XNA allows.
DMAND said:
Looks cool! Will it work in landscape also?
Click to expand...
Click to collapse
Now it will.
http://www.youtube.com/watch?v=k3fLPgJX7g0
Very nice!! I love how it just fits in perfectly with the Metro UI
Hi Tom,
How are you analyzing the audio stream coming off the microphone? I'm trying to do something similar to match sounds with known pitches/frequencies (similar to using the MediaPlayer.GetVisualizationData method) but not sure if I'm missing a simple way of doing it, or if you are analyzing the raw bytes from the stream.
Thanks,
Dave.
I'm capturing raw data directly from the XNA Microphone class and then running it through a FFT routine. I'm using Exocortex DSP, which I've stripped down to the bare minimum.
Hi Servo!
I was wondering how you were able to code the audio to be represented visually in silverlight. I'm looking to do a similar kind of app showing a VU-meter that responds to the audio. It'd be 16 distinct blocks vertically that, based on the incoming audio, light up according to audio strength. I can find samples of accepting microphone input, but how do you turn that visual?
Thanks!
Hi tom, very nice work and excactly what I can use.
Have to do some simple sound measurements every now and again.
Nothing exact but enough to give me an idea what I'm dealing with. This app would be perfect for it. Can't wait to try it.
Hi tom, I bought your 2,0 version of this and I really like where it is going. I need something like this for tinkering with audio setups.
On your graph, could you post some graph lines with maybe some labels (.5 1k 2k...) so I can see where certain peaks lie? it could be toggle-able in the settings?
Also, any plans for some auto or manual calibration?
Its a shame the API only lets you work up to 8k, I wonder why?
Keep up the great work!
i bought this too, and really like it!
But, how accurate is the dB meter??...

Dear Developers, let's avoid making more Hubs.

Dear developers,
As we develop more and more apps, and as the Windows Phone marketplace hit 10,000 apps, I noticed an increasingly annoying trend: Abuse of panoramic hubs.
Yes, I understand that our latest greatest app may be our first important app, but as a user, the app is only one of my many tools in my toolbox, not the center of the universe.
And I understand that a lot of us want our app to be the hub above all other apps, however, let's face it - it's unlikely any third party hubs will be as important as Microsoft's hubs.
While the 6 major hubs in Windows Phone 7 presents some sort of extensibility, a lot of 3rd party hubs don't really do much except the function it is confined to.
A panoramic hub lets developers put different types of list controls in the same page, often for the purpose of showcasing the many depths of the app. However, some apps don't really have much depth, and the usage of panorama in this case feels like 40 pages for table of contents for a 20 page book.
If the app only displays one type of data, a pivot suits a lot better.
And panorama views usually come with a gigantic title, which takes up lots of precious screen space.
Sometimes I noticed that some developers will try to use a background in an app. However, if the app does not have a strong reason to have a background, e.g. dynamic content, I think it's a lot better to let users decide their background colors in their own theme settings. This can save us a lot of Photoshop time, and save users from a lot of text legibility problems.
Just something I'd like to share as both an app developer/designer and a user. Thanks for reading. Peace.
I agree with the fact that the panorama is overused where the pivot is in 99% of cases more appropriate.
I definitely don't agree with the background image thing. Two simple points: Brand Image and Individuality. From a developer standpoint you need something that sticks in users' brains - nothing does so more than product branding. And images are an integral part of that. Since a mobile device doesn't have room for giant logos, the best thing to do is move it to the background and let the text sit on top of it.
I agree that the developer should always offer a choice of background and ensure the text is fully legible in all - but Marketplace rules forbid text not to be legible anyway.
Second, for every application in the Marketplace there are 10 more identical in functionality. So why get the user to use your app over the other 10? Make it look better. And you can't make it look better when it's using the same colour scheme and layout.
pakkei said:
And panorama views usually come with a gigantic title, which takes up lots of precious screen space.
Click to expand...
Click to collapse
Modifying panorama's header template u can do whatever you want with the title (even delete!). Also, most important feature of panorama control is a nice looking slightly scrolling background image (that, I believe so, MS borrowed from Android's home screen).
Panorama != Hub
There is currently no way for a third-party developer to create a hub. Just because an app has a panorama view does not make it a hub.
I do agree though, the panorama view is overused.
I'd be interested if you could give an example of an app over using it as I really enjoy it when used well.
Purely from a developers perspective, I'm slightly worried that I may fall in the category of overuse.
emigrating said:
I do agree though, the panorama view is overused.
Click to expand...
Click to collapse
I disagree.
I think panorama apps are great. Instead of clicking and then having to go back you just swipe.
Best example for me was 1800pocketpc app which was a panorama/hub.
And then apps like facebook that are purely panorama are much easier to navigate cause you never need to reach for the back key
I love the panorama apps i have , its unique to our phones and what makes it great!
evolutionqy7 said:
I disagree.
I think panorama apps are great. Instead of clicking and then having to go back you just swipe.
Best example for me was 1800pocketpc app which was a panorama/hub.
And then apps like facebook that are purely panorama are much easier to navigate cause you never need to reach for the back key
Click to expand...
Click to collapse
I mean that the Panorama is overused because the Pivot is a much neater way of displaying data imo. I think it separates it out nicely.(Pivot being the Outlook-style swiping to sections)
However, some apps do the panorama justice. Faebook, IMDb, etc. However 3rd party developers rarely use it right.
Sent from my OMNIA7 using Board Express
Don't get me wrong - I love the Panorama view, but some [a lot] apps do misuse it.
I have seen plenty of apps which rather than having a "settings" button to open a new view will create their settings page (and about page) as part of the panorama. That is, IMO, not how you should utilize Panorama.
The same goes for apps where you may search for something to add to your "library", placing the search page on your panorama is wrong. It doesn't belong there.
A panorama should, again IMO, be used to display information that belongs together.
Example. You have a DVD collection app; The app is more than welcome to use a panorama as the main page, perhaps it can display "all", "new" and "favorites" on different pages of the panorama. That's all fine. However, adding more pages to display settings, about, search, changelogs etc just gives an awful UX. Add settings/about/changelog as a pivot on it's own page, accessible by a settings button. Add search as a button, either opening a completely new page or an popping up an overlay on the panorama.
Interesting point, and am inclined to agree Panarama views shouldn't be padded with search and settings screens. After all, doesn't the phone sport a physical search button that would be more consistent and allow you to combine your app settings within the phones' main settings for added convenience?
Sent from my HD7 T9292 using XDA Windows Phone 7 App
emigrating said:
A panorama should, again IMO, be used to display information that belongs together.
Example. You have a DVD collection app; The app is more than welcome to use a panorama as the main page, perhaps it can display "all", "new" and "favorites" on different pages of the panorama. That's all fine. However, adding more pages to display settings, about, search, changelogs etc just gives an awful UX. Add settings/about/changelog as a pivot on it's own page, accessible by a settings button. Add search as a button, either opening a completely new page or an popping up an overlay on the panorama.
Click to expand...
Click to collapse
The above is actually incorrect. A pivot should be used when the data of all screens are based on the same underlying data source. Outlook is the perfecet example, as you have all, new, unread which is just filters or views based on the same source: your inbox. The above where you have DVDs should be a pivot as well, since all, new and favorite are based on the single source of your DVD collection.
This is actually where people are making common mistakes with the use of a Panorama control, when it should really be a pivot control. Most users really won't know the difference between the two controls, but developers should to keep the user experience consistent across applications.
The use of a Panorama for a main screen to offer different sections of you applications is a good idea. Be careful to not have too many though. Once you have more than 4-5 sections in a Panorama, the user has the ability to get lost. And remember unlike pivots, the header of each Panorama is seperate from the others (a pivot combines them giving a better hint of the other pages).
Some things to ponder would be in a multi-page settings setup should you use a pivot or a panorama? Since its really not based on data, it should be a Panorama, but a pivot might give a better user experience.
spokanedj said:
The above is actually incorrect. A pivot should be used when the data of all screens are based on the same underlying data source. Outlook is the perfecet example, as you have all, new, unread which is just filters or views based on the same source: your inbox. The above where you have DVDs should be a pivot as well, since all, new and favorite are based on the single source of your DVD collection.
Click to expand...
Click to collapse
I wouldn't say it's incorrect. A pivot may have been a better choice, but it was based on an existing app I have installed where the panorama view isn't completely wrong.
I also believe your argument falls when we step into movie details - this should clearly be displayed as a panorama even though it's based on the same data.
spokanedj said:
Some things to ponder would be in a multi-page settings setup should you use a pivot or a panorama? Since its really not based on data, it should be a Panorama, but a pivot might give a better user experience.
Click to expand...
Click to collapse
A settings page should, IMO, always be a pivot (if more than one screen is really necessary - often it is better to have a scrollable listview instead). That said, if you manage to keep your settings on a single page, using a panorama view would still work to display the about/support/etc screens.
emigrating said:
I wouldn't say it's incorrect. A pivot may have been a better choice, but it was based on an existing app I have installed where the panorama view isn't completely wrong.
I also believe your argument falls when we step into movie details - this should clearly be displayed as a panorama even though it's based on the same data.
Click to expand...
Click to collapse
Here is a video from MS that clarifies this. Pivots should be used when displaying different views or filters or data. For the Movie details if you look at the "bad pano" example, around 11:00 it explains why you woulnd't want to do that. Just because another app is using it, doesn't mean you should.
http://channel9.msdn.com/blogs/jaime+rodriguez/windows-phone-design-days-pivot-and-pano
spokanedj said:
Here is a video from MS that clarifies this. Pivots should be used when displaying different views or filters or data. For the Movie details if you look at the "bad pano" example, around 11:00 it explains why you woulnd't want to do that. Just because another app is using it, doesn't mean you should.
http://channel9.msdn.com/blogs/jaime+rodriguez/windows-phone-design-days-pivot-and-pano
Click to expand...
Click to collapse
?
I pretty much agreed with you that it I presented a bad example. That said, it still works and was nowhere near as bad as many of the apps in the marketplace today.
As for movie details, let's just agree to disagree. Displaying movie details (as opposed to movie listings as discussed above) in a pivot is somewhat counter intuitive and gives a far worse UX than a panorama - I know, I've tried (and had it useability tested by the actual target audience).

Aviation Heads Up Display (HUD)

Hey guys! I was paging through the forums and had what could be an awesome idea. I'm by no means a aerospace engineer nor a computer scientist, but I was trying to figure out how hard it would be to take a standalone Attitude and Heading Reference System (AHRS) system like the iLevil 3 Sport, and display it on something like the EPSON BT-300. Im sure it would have to be a simplified display, but in theory couldn't we get something like a fighter jet HUD directly in front of your face?!
The reason I have chosen these two pieces of hardware (iLevil 3 Sport and EPSON BT-300) is to try and simplify the problem at hand. Through programs like ixGyro, AHRS Utility by iLevil, and Xavion, to name a few (all of which are compatible with the iLevel, and available to download directly to any Android system), you already have all of the information in tablet form.
The AHRS device has all of the hardware required and outputs the information via WiFi. These programs have already proven that this information can be successfully displayed. It seems as through that the only problem now is the GUI. I don't have either of these two products so I can't say for certain, but I'm willing to bet that the BT-300, running Android 5.1, can display this information almost the exact same as on your phone or tablet! I propose that we simply delete the background so you have a true augmented reality while you fly!

Categories

Resources