For my university I (and three others), are searching for a project that utilizes at least one embedded device, web services or other web technology, and a Graphical User Interface.
Currently we are looking at developing a unified remote, that is an extendable application on a cell phone through which you can control your media center. Any ideas, or advice on this will be appreciated, though it is not the focus of this question.
We are having a hard time finding interesting (or funny) projects on which we can work a complete semester. Any ideas will be greatly appreciated. The software will be released as free software. (GPL or BSD license).
We all have a Bsc in Software Engineering.
EDIT: I am very pleased with the suggestions so far. Thanks to everyone, and keep it coming.
How about follower: carry a device, as you move from room to room in your house devices configure themselves to your preference - lights, music etc. If two people are in the room some precedence rules.
Is that possible just on the presence of a mobile phone?
Another idea (from the top of my head):
A work environment ensurance thing. We programmers like to develop in nice and quiet environments. Unfortunately some people tends to annoy us with their disturbing behaviour (or just by being loud).
So the project could be to create devices wich tracks the stress level (sweat levels, pulse etc.) of the individual and their impact onto others.
An example: One individual is very loud (the device should measure this), and others around him becomes stressed and/or unfocused because of this. The serverside sw, should then detect and warn him to quit down a bit to improve the work environment.
Comments?
What do you peeps like doing? Build an app for it.
So, if you like drinking coffee build a application which will find the nearest frothy coffee shoppe (or if you're particular, the nearest Peets/Starbucks/Whatever-ocino). This idea works for beer too.
If you buy stuff off e-Bay build a sniper app.
If you enjoy playing frisbee build an app which locates your nearest friends and sends them a text asking whether they want to goof off lectures and go to the park.
Heck, you could even build an app which monitors your SO questions and alerts you when you get an answer (although I don't know whether the data services SO currently offer will be up to the job).
The standout companies that have made great universal (programmable) remotes are : logitech, and philips.
One of the big problems with these types of devices is the ability of the general consumer to actually program all of their various devices. Logitech has done an outstanding job of providing a fairly simple Web based user setup experience that then implements a very usable universal control.
I would definitely look at what they have done for some ideas on universal remote controls.
How about an app and hardware that will tell me when my wife's plants need watering? (It's somehow my fault if they don't get watered.)
OK then: the recipe generating fridge. Rfid tags on the contents know what's available and the expiry dates. The database knows the recipes. The fridge emails/texts you to say "buy some mushrooms and you can have a delicous ham and mushroom omelette while the eggs are still fresh."
Benjamin and all those aspiring to do embedded projects ...
When you start a project, especially in embedded systems, you need to understand that the hardware is not your PC but some special device. And every sensor will be a transducer in itself. The only thing that would matter to students is that everything costs and are costly
So, it will be good to make sure that the idea is such that,
It can be completed by the
project members within the given timeframe
All the required development
tools like hardware etc can be
really bought
Of all, it good to ensure that the
project enables you to learn
something useful for your career ...
To do all this it is better set some achievable goals
Develop a system in which you can program the lighting system of your house. You can set up their schedule one time and everything should work automatically.
I really love working witht the Atmel ststk1000/stk1006/stk1002 development boards for tht AVR32. ATSTK1000
2x Ethernet
QVGA lcd
USB 2.0
SD/MMC
Conpact flash
Supported embedded linux
IR
Audio
ps2 interfaces
uarts
++
familiy atmel page:
AVR 32 family home
online forums
Forums for CPU
Related
We are working on a project that involves the conversion of old DOS based screen panels to Windows based graphical user interface using GUI Screen IO.
We got in touch with the company recently to purchase the software but company is apparently in transition of selling and have discontinued the business of providing the licensed S/W. So, we are unable to get a licensed copy of this GUI ScreenIO s/w which would impact our project.
Q -- Has anyone ever heard of another presentation layer s/w that is very similar to GUI ScreenIO and can work with native Cobol? Please let us know.
Thanks,
Kishan
Your info about the discontinuation of Gui ScreenIO comes a bit as a surprise to me.
I am a GuiScreenIO user myself and have heard nothing from the vendor about an end-of-life strategy, what so ever, and was billed for support just a few months ago!
If what you state is true (and I have no reason to doubt your writing), I will have to look for an alternative myself as well.
There is an alternative product called SP2 (Flexus) that has an approach comparable to GuiScreenIO. Since you are at the beginning of the character-based-to-windows-transition you might want to take a peek at it! ;)
Feel free to ask if you need more info about transitioning character based cobol applications to Windows.
Kind regards,
Paul
We are building an companion presentation that will be displayed on computer screens next to a museum exhibit. I believe the machines are going to be running OSX (no touchscreens) and the users will need a mouse at minimum.
Does anyone have an recommendations for what environment to build in (flash, air, web, cocoa, etc) that will allow us to restrict access to the computer itself? Our main concern is with people alt-tabbing, command-q'ing, command-option-escape'ing, etc etc etc. Anything that will let them exit the presentation and access the main system is a major issue.
Thanks.
OS X has support for various kiosk modes which you can trigger from pretty much any programming environment. Something Web-based seems like a good strategy since it doesn't limit you much. Opera has kiosk support (which I haven't used) as does iCab. There are also some purpose-designed kiosk browsers such as Plainview and wKiosk.
I think what you are looking for is called "Kiosk mode":
http://www.mactech.com/articles/mactech/Vol.19/19.12/KioskModeFeatures/index.html
Also, I would avoid giving the users a mouse. Mice will get destroyed in such exhibits over time. A better option might be a touchpad. I don't know for sure, but I would imagine they will have a longer lifespan in a display. I know trackballs used to be very popular for kiosks but the ones I've seen look like specially purchased devices, not the standard Kensington ones you get at the shop around the corner...
I was wondering what are the pain points for other developers when learning Windows Phone 7 programming. For me is switching between application pages and the MVVC. If you have any hints or resources helping to overcome these pain points, please share it.
When switching to a new development platform there are bound to be new things to learn.
If you're coming from a web background it's important to note that you're no longer in the same stateless world as the web. There is also a different navigation model. (Especially if you're developing in XNA!)
The biggest, and in my opinion, most important difference in moving to developing for the phone (or any mobile platform) are teh follwoing 6 points.
"Mobile" applications are used
differently to desktops ones. -
Expect users to have less time to
spend with the application and be
doing other things at the same time.
Input is different. - Consider
[multi-]touch as well as voice,
location and sensors rather than
mouse and keyboard.
Output is different. - Even if just
considering output to the screen,
it's very different developing for a
small screen than a large one.
Connectivity is nott guaranteed. -
Create apps which work offline and
are occassionaly connected. Don't
assume a network conneciton is
guaranteed or fast.
Performance is important. - Partt of
the way that"mobile" applications
are used differently to their
desktop counterparts creates a
different expectation from users and
they are much less tollerant of
applications which are displaying
the equivalent of a wait cursor. Do
no more than you have to and be sure
to keep the app/device as responsive
as possible.
Resources are constrained. - The
most important consequence of this
is to do no more than you must, so
you can preserve battery life.
Afterall, if you run down the users
battery they get frustrated and
can't use your app.
Unfortunately the best way to avoid running in to problems is to develop a detailed knowledge and understadnig of the platform.
With that i mind, I'd recommend the following resources:
For general information check out the MSDN documentation.
I'd like to particularly draw your attention to:
the design resources, particularly the UI guidelines - so you can create something which looks like it is actually part of the platform.
and the fundamental concepts - so you don't waste time trying to do something which isn't possible.
Other useful resources are:
- Code samples
- Online training (there are updates to this coming soon)
- the book by Charles Petzold
There is a great, organised resrouce list here which covers pretty much all the major points of Windows Phone 7 development.
I want to create an embedded system using Linux similar to E book reader using ARM9 processor. I am not an electronics expert but I would love to learn it. I know basics of electronics like transistors, flip-flops, multiplexers. etc. I love software and would like to create something like an E book reader. Is it possible for a software engineer to create an embedded system? I do not want to buy single board computer available in market, I want to create it myself.
Where do I get some kind of tutorial?
Is my knowledge of operating systems enough to create such a system?
Building a system requires knowledge from multiple engineering disciplines. You can only achieve such a task by buying off-the-shelf modular components and assemble them, and in the case of an e-book putting together the modular components won't be pleasant.
Also learning any of the single disciplines needed will take you a long and concentrated effort.
To (loosely) indicate the problem areas:
you need a computing platform of the right form-factor with all the right chipsets (Apple integrate their own single CPU, as of recently, using hardware designs from multiple companies). You will not find a suitable computing platform of the right form-factor.(Electronic Engineer: Digitial designer, Analog Designer)
You need to try to attach an LCD to the right platform, and other peripherals such as USB/ charging port/ WIFI etc etc.
(Electronic Engineer, Product Designer)
You need to build a case for the platform.
(Product Designer)
You need to get a embedded operating system (potentially real-time) (working on your platform) that fits your needs.
(Embedded programmer, Kernel Programmer)
You need to extend said operating system to behave the way you want it.
(Application Programmer, Graphics Programmer)
The most important part is the platform, and getting a suitable one is very hard and very expensive. The original iphone had a platform created by a third party that apple bought and used to apply points 2-5 -- and it still took their best engineers a long time to make a prototype.
Not really; hardware engineering is a degree-level subject in it's own right, and you need at least three different specialities to do that job. Not to mention that CAD software and CNC machines cost a heck of a lot more than gcc, so hardware engineers' overheads are huge.
However, you can hire that done, for a substantial fee. Or you can use embedded boards and get the case design done for you.
For example, a beagleboard with these accessories in a custom case.
Or, a Gumstix overo with one of these and one of these in a custom case.
In either case, running some embedded linux.
Development boards save a lot of time and money, but in both cases, if you have the capital you can get those boards boiled down into a custom board that will do just what you need for your application, and cost less in large numbers.
Do not underestimate the case design; you're looking at the thick end of a hundred thousand dollars just for the tooling to manufacture a plastic, die-cast metal or stamped metal case, without paying for the design work.
Creating embedded hardware from scratch requires a lot of expertise and resources. It would be better to start off with a low-cost evaluation board in order to learn the basics of embedded programming and interfacing first. That should keep you busy for a few months. Beyond that, embedded CPU suppliers typically have reference designs that you can incorporate into your own embedded product, but at this point you will need to start investing a lot of time, effort and money into tooling up for hardware design and development.
There is basically no need to create (I mean to solder) the embedded system. A good approach may be to buy some controller board like this this or this. You need to be careful with the board but there is nothing about it a software engineer could not manage; it has the familiar serial, USB and RJ45 ports and normally already boots Linux. Finding enclosure, connecting peripherials (including analog/digital converters, or adding some relays to the output ports) is fully in the range of capabilities of someone who wants also some work with hardware. Expect to develop in C.
You can buy off the shelf hardware for embedded software development.
PC 104 Boards
How do companies like Valve manage to release games to all three major gaming platforms? I am interested in the best-practices regarding code sharing specifically between Windows, Xbox360 and PS3, since the ideal solution is to reuse as much code as possible instead of rewriting the whole thing for every platform.
It's not any different than writing platform-independent code in other contexts. Hide platform-specific details (input, window interaction, the main event loop, threading, etc) behind generic interfaces, and test regularly on all the platforms you intend to support.
Note that the Cell's threading model is unusual enough that doing threading "generically" takes some care. I am not a Valve employee and I know none of their secrets, but it's my understanding that most game developers who want to target the PS3 use a job queue that the individual cell processors grab tasks off of as needed. This isn't necessarily the best way to use the Cell, but it generalizes nicely to more conventional threading models (like, frex, the one that thet PC and the 360 both use).
There's a bunch of Game Developer Magazine articles and GDC talks on the subject. In fact, since you mentioned Valve, they delivered a talk describing their approach at GDC08.
This is really a huge subject that I could (and have) talk about for hours upon hours, but elevator summary is:
Determine which parts of the engine are completely platform-specific and put them behind an abstraction. File and asset loading, for example, need to be rewritten for each console; but you can hide that behind an IFileSystem interface which provides a uniform API that the game code talks to.
The PS3 makes this hard because its abstraction point has to be someplace completely different from the other platforms. Even game features like collision and nav will have to be written differently for the Cell.
Try to keep leaf game code (entities, AI, sim) as platform-agnostic as possible...
But accept that even the leafiest of game code will sometimes need some platform-specific #ifdefs for perf or memory or TCR reasons. A lot of UI will have to be rewritten because the manufacturers have conflicting certification requirements.
Anyone who says the words "I'm not worried about performance" or "memory isn't an issue" shouldn't be on the payroll.
This question can be divided up into two separate questions. "How can I write portable code?" and "What are the divergent requirements of mainstream gaming platforms?".
The first question is relatively easy to answer. Best practices for abstracting your non-portable code are covered in Write Portable Code:
http://books.google.ca/books?id=4VOKcEAPPO0C&printsec=frontcover
Turning theory into practice, the Quake 3 source code does a pretty good job of dividing out different platforms into separate areas for a C codebase, available at http://www.idsoftware.com/business/techdownloads/ However, it does not demonstrate C++ patterns such as abstract interfaces, implemented once per platform.
The second part of your question, "What are the divergent requirements of mainstream gaming platforms?" is tougher. However, it is notable that your largest areas of change are still your renderer, your audio subsystem and your networking.
Each console platform has a series of certification requirements, available under an agreement with the respective console owners. The requirements drive consistency in user experience and are not focused on gameplay or qualitative, high level issues. For instance, your game may need to display a reasonably interesting animating loading screen, and black screens are unacceptable.
Getting your hands on this documentation as soon as possible is key to making the right choices in developing for a specific console platform.
Finally, if you can't get your hands on a console devkit, I suggest you port your code to the Mac from Windows. The Mac gets you an OS port ensuring you are not tied to Windows as well as a processor port if you support universal binaries. This ensures your code is endian agnostic.
If you support both PC and Mac, you will be well positioned to support a third platform, should you gain access to it in the future.
Addendum You wrote:
the ideal solution is to reuse as much
code as possible instead of rewriting
the whole thing for every platform
In many game porting scenarios, the ideal solution is not to reuse as much code as possible, but to write the optimal code for each platform. Code can be reused between projects and is relatively inexpensive as compared to the content that the engine takes in. A more reasonable goal is to aim for lowest common denominator content that runs on all platforms without modification (a build phase that packs the content for media is okay).
It's great to do simultaneous development. You find all kinds of bugs you wouldn't find doing just one platform.
I remember that programmers in DOS had null pointers all the time because writing to low memory didn't immediately crash them. When you ported to an Amiga, Atari ST, or Macintosh, boom! I remember telling a DOS programmer that he had a couple null pointers on an aready-shipped game. He thought for a couple seconds and grinned, "That explains a few things."
Now that games have such large budgets, it's important to ship them all at the same time so you don't waste marketing and ad budgets.
My advice on simultaneous development is to pick one lead platform, but never let the other platform(s) get more than a week behind. It will become obvious as you program which parts of the code are common to all platforms and which are different. Pull out the differences into one or more platform-specific areas.
My experience is in C/C++. It's a bigger problem if you have to port against different languages (say, Java and Objective-c).
A few years ago the Opera CEO said in an interview that the key to developing for independent platforms is to move away from any single OS/platform libraries. He went on and said that they developed their own libraries that improve OS performance.
My assumption is that big companies will have a common, Xbox, PS, windows, FooOS, separate teams. Each platform needs to be tweaked differently and requires different implementation methods. I don't think they do one source for all platforms; rather, they build one for each OS thereby, improving efficiencies. I remember EA used to release some console games earlier than the PC versions and vice versa.
Another issue is that different consoles have different hardware thus requiring different programming techniques.
there are two extremes, build one source that fits all (java for instance) but you run the risk of inefficiency or write 40 versions; one optimized for each platform
Back when I had a friend into educational computer games (before The Learning Company gutted the field), he was a great fan of creating cross-platform libraries for doing everything.
This is easier for games than other apps. If you have a word processing app to run on the Mac and Windows, for example, it really does need to look and behave like a Mac app on the Mac, and a Windows app on Windows. Write a game, and it doesn't have to conform to the native behavior, look, and feel.
If you want open source examples, you could look at source code of Quake 1, 2 and 3 engines. They are structured quite portably. (Of course, no ps3 or xbox360 support, but same principles apply)
http://www.idsoftware.com/business/techdownloads/