Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm currently an undergrad in computer science and I'll be entering my final year next year. Augmented reality is something I find to be a really interesting topic, but I have no idea where to start learning about it.
Where do you start learning about this topic and what libraries are available?
Being a quite popular buzz word, augmented reality can be build with some distinct algorithms which can be learnt separately. Usually it covers:
planar object detection (can be a marker or previously trained object).
SURF/SIFT/FAST descriptors, RANSAC for homography matrix calculation
store trained objects in DB (KD-trees)
camera position estimation
augmenting 3D model with custom objects (OpenGL)
To dive into this subject I would recommend this steps:
All of this is already implemented in OpevCV, you can start playing with its examples.
To understand what's happening under the hood, take probably the best book on this topic:
"Multiple View Geometry in Computer Vision" http://www.robots.ox.ac.uk/~vgg/hzbook/ .
If you are going to play with AR on mobile phones take a look on works of scientific labs
like http://mi.eng.cam.ac.uk/~sjt59/hips.html (FAST) and http://www.robots.ox.ac.uk/~gk/PTAM/ (PTAM).
If you're comfortable with Objective-C, downloading and playing with ARKit would be great place to start. It's based on magnetometer/accelerometer readings rather than pattern recognition.
If pattern recognition is what you're interested in, then start with artoolkit instead. But that library is a bit more intense, naturally.
Take a look at this augmented reality framework comparison table to select a suitable AR framework for your work.
qualcomm's vuforia AR api is a great place to start since it is free and it has all the AR features we can think of.
And also this book gave me a huge help to start building AR apps.
Developing AR Games for iOS and Android
by Dominic Cushnan, Hassan EL Habbak
Ben Newhouse, the man behind Yelp's augmented reality Monocle feature, gave a talk at Stanford about the process he went through when making it. It is available for free on iTunes U, at this location: https://podcasts.apple.com/us/podcast/iphone-application-development-winter-2010/id384233225
(The link won't work in Chrome, but it does in Safari. If it doesn't work, just search "Yelp Monocle" in iTune's search box, and download the iTunes U lecture.)
The lecture is about programming for the iPhone, but most of it is translatable to other areas. It is packed with valuable information, and has proved extremely useful for me in seeing all the components of what i want to make.
The Pragmatic Programmer AR book is pretty good, lots of code samples and exercises that get you involved, instead of just reading about it. It is a little dated, but it should be a pretty good starting point.
This was extremely helpful to me because of the step by step tutorials and sample code: http://dev.metaio.com/sdk/getting-started/
It takes you from setting up your phone/ dev account through to tracking configurations and 3D content.
I have spent a bit of time looking for AR code for the iPhone. If you want to do AR and locations then download this project
http://github.com/adascent/iPhone-AR-Toolkit
It based on ARKit mentioned above but improved and actually compiles. The orginal AR kit does not support device rotation. Someone else added it but there actual code never worked and so a 3rd person took it and fixed it.
I am currently added more features to this code.
augmented reality is combination of 2 skills: ability to code on smartphones + using all the input sources that the handset can provide to provide interesting applications. Computer vision is a major aspect, since the camera can be used in very many interesting ways. But you must know that knowing any one aspect of it is not good enough. for example if you use comp vis, alone to detect where you are based on the camera input of a shopping mall store it is not going to be easy at all. but if you couple up your gps location etc, the problem reduces to a very managable level. So the important thing is being able to couple ideas from different aspects and knowing a little bit about both aspects. Take a smartphone programming class and a computer vision class. that should get you started.
If you're an undergrad, you start by asking faculty about it (or grad students, if you're in a place with them). Even if they don't know much about it, they'll know where to find out.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm an undergrad who finds computer vision to be fascinating. Where should somebody brand new to computer vision begin?
Check out this book
http://research.microsoft.com/en-us/um/people/szeliski/book/
it is in beta stage right now and available for free.
Richard Szeliski, the author, is a a well known researcher in the field of computer vision. He is also behind the Photosynth project.
Get your hands dirty! What language do you program in? I would recommend looking at OpenCV, which is an open source library that comes with many functions you can use to build interesting systems. It is written for C++ but also has bindings for Python. It comes with many demos that you can run right away and hack around with.
For complete overview of the field books are the best way to go.
For any particular topic you want to know more about, survey papers found through Google Scholar are the way to go.
For most recent research, look at papers from CVPR, which is a vision conference:
http://www.cvpapers.com/cvpr2010.html
You definitely need a solid math background: calculus, linear algebra, signal processing, probability and statistics.
You also need to understand what specific problems are studied in computer vision: recognizing an image of a particular object, recognizing a general class of objects ("cars"), detecting whether an object is present in an image, locating an object in an image, tracking moving objects in video, reconstructing a 3D object or scene from an image or a set of images, etc.
I was once told by a professor of a good way to get into a new field. Go to the library, find the main journal for that field, and start reading abstracts to papers, until you get the lingo. In the case of computer vision, good journals to look at are IEEE Transations of Pattern Analysis and Machine Intelligence, aka PAMI, and International Journal of Computer Vision (aka IJCV). By the way, the two major conferences in computer vision are CVPR (IEEE International Conference on Computer Vision and Pattern Recognition) and ICCV (International Conference on Computer Vision).
Topics that are related or heavily overlap with vision are image processing and machine learning.
If there is a course in computer vision offered at your school, take it. Get some books on the subjects I've mentioned. If there is vision-related conference near where you live, sneak in and look at the posters.
Oh, and Matlab is a great environment to play with image processing and vision algorithms.
Some resources:
Learning about Computer Vision
Must have background on signal processing methods - Transform - Fourier - Hough -etc
May use a better environment such as MATLAB for image processing
Pattern classification methods
Neural Networks is an important and widely use tool in Computer Vision
As with all other things at school.... start by taking up a course with a good amount of project work. Explore ideas and implement algorithms in those projects that you find interesting. Wikipedia is a good beginners resource as usual. If you want books, the most popular ones are:
http://www.amazon.com/Multiple-View-Geometry-Computer-Vision/dp/0521540518
http://www.amazon.com/Computer-Vision-Approach-David-Forsyth/dp/0130851981/
http://research.microsoft.com/en-us/um/people/szeliski/book/drafts/SzeliskiBook_20100423_draft.pdf
But I would suggest before you jump in to books, take a course/go through some course slides at one of the top ten universities or via iTunesU.
I found this guide to be pretty good at introducing the novice to computer vision, but you really need to go for a MS for that. Electrical and Computer Engineering Departments offer it under a Digital Signal Processing Program, from which you can choose to specialize in Machine Vision or Digital Imaging (whatever they may call it).
SOCIETY OF ROBOTS - COMPUTER VISION TUTORIAL
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am working in a small team on some projects in my spare time. We are having the problem that we seem to go in circles and are not able to get our products developed - however this is not a problem during my day job. The lack of face-to-face communication seems to have a real impact on productivity.
Any examples of software or methodologies in use by the open source development community would be appreciated.
If you read the history of most open source projects, they start with one person doing a lot of the initial work. If there's a team, it's small, and one person actually leads the team.
To pick one example. In the Python community, they refer to Guido van Rossum as the Benevolent Dictator for Life (BDFL). His word is (more-or-less) final. In many cases there are folks don't agree with him -- but for the sake of the Python community -- they seem to acquiesce to his judgment.
I think every open source project has a (singular) lead programmer who assures that decisions get made, and made in a consistent way.
Back in the olden days, Fred Brooks (The Mythical Man Month) described "chief programmer teams". Same concept. Someone is in charge of the technical content. Emphasis on the one. Nowadays we call the the "architect" or some such term.
No real methodology here, but I think 2 things are important:
Have well defined goals and
responsibilities.
Let each developer
have the last say in how their
allocated part should be done.
In open source projects the only real and strongest motivation is the fun to be had coding the product. Relating to #2 above, if people are told what to do, and they don't agree with it, the motivation starts lacking. Of course there will always be a bit of give-and-take like in any other type of relationship.
Also about the face time, Skype is great for having face to face meetings, which I recommend at least once a week or month (depending on the size and momentum of the project)
This is a difficult question to answer because "open source projects" is a very broad selection of projects. I think the defining characteristic is the project has a single unifying goal (perhaps, a set of related goals).
Are you on any open source mailing lists? I am subscribed to my favorite distro's mailing list and the developers e-mail each other many times a day. Also, there are other avenues of communication such as IRC / Instant Messenger.
I am not a RoR developer, but I would suggest skimming through Getting Real for some inspiration.
My guess is that your private projects are all run and coded by developers. Developers are known to... keep on developing. The big difference, in my experience is that a company has experienced managers that can define when things are DONE. I'd recommend putting someone on the task of defining goals and decide when things are done.
I've been on some projects where we had a lot more talkers than developers. My inclination is to ignore the talkers and listen to the coders. Even then there's usually one person who is in charge of accepting patches. There may be political issues they have to tread lightly around, but for all intents and purposes they have final say.
Linus has had some fairly famous issues with the same problem. Take note of this thread from 2006: Talk is cheap. Show me the code.
One more thing. Since you say in the comments that you do have code, just a lot of rewrites, I'd highly suggest you read Eric Raymond's The Cathedral and the Bazzaar. Eric's a bit of a nutter actually, but the essay is priceless for anyone wanting to run a Free Software project.
I'd have a think about your and your team mate's motivation and goals in this project. Are they to:
a) Create an awesome product
or
b) play around with software, and learn some new things
Both answers are equally valid, and i'm guessing it'd be a mix with a leaning towards one or the other.
If it's more of (a) then look at suggestions on methodology etc. Maybe even consider forming a company around your awesome idea. Because making such a thing takes work.. and well you probably get enough of that at work.
If it's mostly (b) then you're going to have a harder time making an awesome product, but an easier time in that you can forgive yourself for not getting there right away and suffering multiple re-writes. And you will all be learning new skills each time you look at it and work together which are very applicable to your long term careers.
Firstly i suggest you all be clear with each other on why you are there. Then look at paring back on what you are planning on doing, and release early and release often. If your project is made up of three components and one is complete, then release that as a separate component and start building a community of users. This will pay off as these users will possibly help you with your code, plus form a solid core of users for the full product and let you assess how you are going early rather than later.
Good luck.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
After every new program written a lot of paper documentation remains.
Apart from the usual scribble notes from the programmers there usually is a nice heap of papers containing physical model explanations, calculations and so on (equations, tables, graphs, little pictures describing variables ...)
We usually do numerically intensive calculations in console applications, which are not released to the public (remain in the house, only results go out). Before each project is finished all those papers have to be packed somehow with the application, so that one day, when someone will be reusing parts of it, has some idea what is what in there.
So far, we've been using the 'dirty' solution of just scanning all of it, and packing it up on the disc with the application.
So I was wondering ... for all science guys here in a similar situation ... how do you handle project documentation which is needed, but not released to the public ?
(the one that does, goes to the dtp laddies, and they make it nice and shiny - not our problem anymore :)
I use one of three options:
Keep everything in my lab notebooks, which I archive myself, for low-level stuff
Scan the paper document, and add to source control in pdf. It's ugly, but if someone needs it, it's there
Transcribe the equations, results, etc... in a clean format (usually Latex) for future reference, and again, add to source control. Official paper copy gets signed (I work in a highly regulated domain) and filed in a binder.
In the projects I've worked on we have done a lot of physics calculations in our programs and consequently we have a lot of whiteboard sessions with equations we are working on.
We keep a wiki for each major project and after each whiteboard session we physically photograph the whiteboard with a digital camera and upload/organize it within the wiki. We also scan in paper documents from developers notebooks if it is important and include it in the wiki as well.
Then, we back up the wiki on disc for storage. So our solution is pretty similar to yours, other than we use the project wiki for organization.
If it's important, it seems to me you should treat the internal documentation with the same care with which you treat the public docs.
I create UI paper prototypes when designing the UI of an application, which produces lots of A3-sized papers (in one project we had many desks covered with papers). When the design is ready or it needs to be mailed to somebody, I take pictures of it with a digital camera, so that I can produce a series of pictures showing how to perform some tasks on the UI, which serves as documentation of how the application is meant to work. This serves also as a backup, in case somebody steals/cleans away the original papers.
Here is some of the thoughts... Not so practical though :)
We can make it part of our Check-in notes. This may help the developers going to maintain the application.
Update the requirement document/Low level design document with these items
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
which were your achievements in programming in 2008?
what technologies surprise you or learn this year and what do you expect in programming terms in 2009
Edit:
Changed to Wiki
I wrote 2 VB.NET language features that will ship as part of VS 2010.
I designed a programing language called Liberty,
However, I've only implemented a small fraction of it. I stopped working on it so that I could concentrate on building a profitable software company. My original intent was to market the language (actually an IDE for it) as my first product, but the economics of programing languages being as they are, I decided to pick something else for my company's first product. I've been thinking about turning it into an open source project. If the statement "A programing language that feels like LISP, but looks like C#..." has any appeal to you, and you are interested in working on an open source .NET compiler, let me know.
I started my own software company
I've designed and implemented most of my company's first product "Transactor Code Agent", which should be shipping in Q1 2009. I've been billing it as a "Disaster Recovery Tool for Programmers".
It's a tool that provides automatic local version history for source code. You point it at the folders that contain your source, and then anytime you make a change to file it automatically creates a backup for you. It's meant to be a compliment to existing source control setups, by protecting all the "broken", "in-progress" work that you usually don't check into source control.
By the way, we are looking for beta-testers. If you are interested let me know.
After Scott's outing I would feel deep shame in confessing what I achieved in 2008.
I made one of my "flagship" applications better by removing features from it.
For the first time, I sold my work to a general audience, via the App Store. In so doing, I:
Reached over five times as many users as my most widely-used previous work (26000+ instead of 5000+)
Made more than three times as much money as my most lucrative previous work (a Google Summer of Code grant in 2005)
Learned two new environments (Objective-C/Cocoa Touch and Ruby/Rails) after sticking with Perl for many years
Disciplined myself enough to get the boring bits done
Learned what it meant to be responsible to thousands of people
But perhaps most importantly, I made beautiful things that I could be proud of.
In 2009 (or maybe late '08) I'll release a new product that I hope will push all of that even farther, and maybe even be a best-in-class solution for a problem everybody faces.
Helped push another release towards the door (not quite there yet)
Presented a paper on accelerating the Hough Transform at WorldComp
Averaged just shy of one blog post per week
Built up hope of catching John Skeet in reputation
Did a huge set of bizarro work with reflection and dynamic code generation
Gave up all hope of catching John Skeet in reputation
Managed three employees, more or less successfully
I decided I would learn a new language, nothing specific at the time, since then I have learned Python.
This coming year, I would like to learn another language, preferably something like c++ or maybe just maybe (I'm a *nix kinda' guy) Ill try a Microsoft stack with something like .net but we'll see what happens.
Improved interviewing skills. I am now better able to discern good and bad applicants through better questions, including small whiteboard coding sessions.
I am up to speed with Drupal, though lots still to learn. First time really working with a good framework.
2009, maybe i'll get around to doing some lisp funness
I opened myself to the world of Dynamic Languages and Functional Languages. I can read programs that dont resemble a C++ or C# kind of code with {} and ;. In the process developed better understanding to patterns like MVC.
I needed to learn PF early this December as our existing firewall solution was woefully underpowered for an industrial application, but we didn't have the dough for the "professional" solutions (i.e. ci$cso stuff).
So I ended up taking my existing OpenBSD box in the server stack and turn it into the firewall using PF. Since the system uses multiple servers and multiple IP's (some on domains), I needed a combination of NAT, RDR and the usual RULES.
It's certainly not as sexy as learning APL or LISP (or Ruby etc.) for fun, but it was necessary and urgent.
The new firewall is performing beautifully and I don't have to reset the horrid little firewall appliances twice a week anymore (which had to be done remotely which also was not fun). :-)
Cheers,
-Richard
Well, I've builded a big site (for some project) and learned java, now I want to learn C for coming year.
I released my first program into the wild world of the Internet.
I went outside my .NET bubble by creating the previously mentioned program in Objective-C.
I built a pretty cool string extractor utility and corresponding processing library to facilitate automatic localization of string resources in a native C++ application without refactoring the code to extract the strings from where they were used, with the added benefit of allowing cross-language string pooling of localized strings.
I also built a cool operator_cast<> function (with some help from the SO community) to help codify programming intent when using custom casting operators.
1- I made changes to a International Wine Contest Software that i previously wroted. it was changed because the a new sponsor have a different logic in the contest we were notified about the changes 3 days before, so a friend and I code like 2 days in a row,literally running from work to the contest in order to provide support. at the end everything was Flawless
2.- Released my first program for Sales and inventory for Video game retailer
3.- Start my Coding Blog
both in .Net of Course
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Courses for people who are being introduced to programming very often include a code project, which I think is a nice way to learn. However, such projects often feel too artificial, and are thus not very rewarding to work on.
What are your ideas of rewarding code projects? (Preferably easy to begin, and extendable at will for the more advanced!).
Edit:
#Mark: thanks for the link, though I'm more interested in projects for people who are completely new to programming (the link seems to refer more to people who are already proficient in at least one language, and trying to learn a new one -the typical SO audience I'd say :) -).
#Kevin, Vaibhav, gary: I was thinking of people who are learning programming through one language, so at the beginning of the course some don't know anything about control structures (and even less about any kind of syntax). However, I was thinking in quite a large project (typically in the 1k-10k lines of code range, possibly in groups of 2 or 3 students). This is what was done at my school for the complete beginners, and it sure seemed to work for them... except that most of them found their projects quite boring to work on!
As has been stated a few times, what you are trying to teach the beginner is very important to the project.
My advice to you for planning something like this:
1) Avoid making a computer game
A computer game, while fun to build, doesn't reward the programmer with results early on (it's very complex). You want to concentrate on small but useful application programs, such as a Port Scanner. The example there is a little complex, but it's one of the best learning projects I've seen on the web.
2) Teach graphics early
It's rewarding to see the fruits of your labors early on, and it motivates you to go further. Whether you're using WinForms, MFC or the Win32 API, OpenGL or DirectX, teach it early.
3) Many small lessons with in depth information
This principle is followed by the above linked Port Scanner project, and it works well. Teach each part thoroughly, and give time for the beginner to absorb the lesson. I think that ZophusX had a good format for giving the information. It's too bad he's mostly abandoned his site.
4) It takes time
Don't rush things. Nobody becomes a stellar programmer in a few weeks. Try and make the lessons simple, but engaging, and keep building from your previous lessons.
5) Get feedback early and often
You might think a project is incredibly interesting, or a particular lesson or such, but you aren't the one learning. Your student(s) will greatly appreciate it when you ask them early on how things are going, and what they'd like to know more about. Be flexible enough that you can accomodate some of those requests.
6) Have fun teaching
Have fun. Passion is contagious, and if your student(s) see how much you enjoy the subject matter, some of that enthusiasm will rub off on them as well.
I hope that helps!
Some good rewarding projects, in terms of what you can learn and which are quite scalable in terms of complexity, features are:
Games
A travel and transportation reservation/booking system
Encyclopedia or a Dictionary of terms, articles
Conversion Calculators (Currency, Units, etc.)
The key is to pick a project simple enough, so that some of its features are immediately apparent, when you look at the project title. And when really given a thought, will reveal more features that you can add to it.
The project should have enough difficulty to so that its features seem just beyond the beginner's reach, thereby motivating him to learn something new all the time.
If you are training new people in your company, then attaching them as intern resources on a live project is very rewarding.
This increases the work load of the main developers a little (because they have to review all the work that the intern does), but goes a long way in terms of training and development of the person.
I do think that games and puzzles are a good place to start as they can give great scope for developing more complex versions. For example a tic-tac-toe program can be built as a simple command line program initially that lets two players play the game.
This step can be used to show how a simple data structure or array can represent the game board, simple input to get user commands/moves, simple output to display the game board and prompts etc. Then you can start showing how an algorithm can be used to allow player vs computer mode. I like the simple magic square math algorithm for tic-tac-toe as it's based on very simple math. After this the sky's the limit, UI improvements, using file I/O to load and save games, more advanced algorithms to get the computer to play better etc. More complex and satisfying games can still be produced using text mode or simple graphics.
I've used the Sokoban game as a means of showing lots of techniques over the years.
The simplest game I've used is a number list reversing game. This involves a mixed up list of numbers from 1-9. The player can specify a number of digits to reverse on the left of the list. The aim is to get the list sorted. This is great for absolute beginners. Each little part of the game can be written and tested separately.
It really depends on what you're trying to teach the beginner. If you're trying to teach syntax, then simple "Hello World" programs and ones that spit out every odd number between 1 and 100 are fine to get them started. If you're trying to teach data structures, then maybe something like a 20 questions game or some simple sorting program. If you're trying to teach recursion, then maybe a breadth first search program. If you're trying to teach database manipulation, then something like a order tracking system would be appropriate.
Take a look at code examples in the book Python Programming for the Absolute Beginner
Text Adventure.
It's a console app
You'll need to do some useful things, hold inventory, map and room state and parse input
It's fun and you can give it to others to play! :D