Ideas

The ideas below are posted for your inspiration and my ledger. All ideas are rarely explained in intense detail. I'm merely planting a seed by developing a list. Later in life I can reflect, rethink, and bring them to life. All ideas have a link to Google Drive. Please contribute. I will post them on reddit ideas too.  Enjoi.

:: Modern Metal Detection Contribute on Google Drive

Introduction

Have you ever went metal detecting? While the rewards can be worth it - it's a terribly inefficient and physically exhausting exercise. You move your arm left-right-left-right-left... While handheld detectors can be helpful for surveying small areas, if you're looking to cover a large area (a beach for instance), you'll be begging for a more streamlined approach that requires less manual effort and turns up more reliable results.

motorized bike detector

Let's combine a bunch of technologies to brainstorm a more reasonable approach to metal detecting.

1. Let's replace your feet. The metal detector should be motorized.
2. Let's replace your memory. Often, especially as a beginner, you'll scan an area more than once. The detector should be aware of it's position with at least centimeter precision. This wouldn't be precise enough with GPS, but very possible using your own localized triangulation system. The detector would be programmed to scan a geographical area without visiting the same location twice.
3. Let's replace the coil. The detector should be capable of providing high-resolution images of the area it is inspecting. These images can be created by using an X-Ray machine. The images should be saved to an onboard computer.
4. When the images are saved to the computer, an image algorithm properly stitches them together and takes note of any interesting object's coordinates within the localized triangulated zone.
5. The motorized detector should be remote-controllable. This feature not only protects the user's health from dangerous X-Rays, but, allows the detector to enter dangerous zones, such as, minefields.
6. Once the detector has completed it's survey of the area, or, in real-time, from a distance, the user can inspect the detector's output (by logging into the machine) and decide whether particular objects are of interest, or just junk. Because the detector has marked the coordinates of each point, it can be reprogrammed to revist these points (with the X-Ray off) and guide the user to the objects one-by-one.

Some other features: The detector could drop flags, it could even implement a digger.

Problems

I'm far from an expert on X-Ray photography and I'm not sure what the exposure time is for these devices.
Would work well only on flat areas (fields or beaches)...

Comments(0)Leave Comment

:: Air Drums Contribute on Google Drive

Update

After posting on reddit, @grumbel showed me that a very similar device to what I describe below has already been created. Thanks, @grumbel!

Introduction

I grew up on a lot of punk rock and casually find myself playing the air drums when listening to my favourite metal bands. How cool would it be if the air drums actually made sounds? What if you could play drums without actually having a drum-set?

air drums idea

Equipment

You'll need accelerometers to detect jerking motions (your hands beating on invisible drums). These accelerometers could communicate via bluetooth, wifi, or even a custom channel to a receiver that sends it into your computer using USB. The other device is a simple receiver that does any conversions and feeds it into the computer & DAW:

air drums diagram

Detecting the position of the hands and feet.

There a couple of ways you could do this. One way would be to set up positional sensors on your wrists, elbows, and shoulders to measure the pitch, yaw, roll and translation of your arms. This problem is well known and studied heavily in robotics. When applied to robots it's called the Six Degrees of Freedom. 6DoF. The other option is to use a Triangulation system to detect the position of your hands and feet in the x-y-z plane. This method offers much less sensors attached to your body.

MIDI Controller

The device would be MIDI controller so that integrating it into DAW like LOGIC, Fruity Loops, or Ableton would be a breeze.

Educating the kit.

So how would you set up a kit? The idea is that you would train it. By hitting a button in your DAW it could go into record mode. Then you flick your wrist (air drum) at some point in space. The accelerometer attached to your hand registers the x, y and z coordinates and sends them wirelessly to the device. The device listening for these coordinates sends them as a response to the DAW, which registers that point in space as a drum. You are then able to map that registered point to a sound inside your DAW - whether it's a tom, snare, crash, ride, cowbell, what-have-you.

Operation

After you've downloaded a template kit, or trained your own - you'd put the device into play mode (as opposed to record mode) and try it out. When you flick your wrist in the vicinity of one of your registered coordinates, the DAW would play your instrument.

This 'vicinity' should also be configurable in the DAW. If your drums are all very close together, then, having a high vicinity value may cause some drums to bleed into others. Having a too low vicinity value may make it hard to 'find' your drums and cymbals.

Monetization

Consumer Goods. Sell at music stores across the world. Or, open up shop and sell online only.

Problems

Delays. Everything mentioned above has to be done in as-real-time as possible. I've played guitar with as small as 30 ms latency and it is very noticeable and makes playing hard because you're brain get's out-of-sync.

Comments(0)Leave Comment

Introduction

We definitely have the technology to make a lot of Mario Kart aspects a reality. Imagine getting into a go-kart and donning a helmet with a built in HUD that shows a map of the course, the placement of the players...etc. All the helmets or go-karts are equipped with sensors and small computers. These computers are capable of communicating with a central server that lives in the office - or whatever. It is this main server that takes the data sent from each individual go-kart and appropriately updates everyone's HUDs. Here's a screenshot of the video game:

real life mario kart

Let's go through each key feature...

#1. Shows what place you're in. This could easily be determined by calculating the GPS coordinates of each vehicle. If the GPS coordinates turned out to be unreliable (which I'd guess that they were), then, there are other ways. GPS is really just triangulation. So build your own triangulation system inside the track...

#2. This is where it get's interesting. Mario Kart has the concept of mystery boxes. Because you're wearing a HUD, these mystery boxes could be painted on the course for all players. Here's a list of the mystery boxes and a description of how each could work...All players can launch their item by a button on the steering wheel.

real life mario kart mystery boxes

The green shell and shells are non-seeking. The reds are seeking. When you shoot them, they go in a straight line. The shell, before you launch sits in front of your kart. And when you have three, they circulate around your kart. All of this should be animatable (is that a word?) on your HUD. And when you launch it, your HUD can animate that as well until it makes contact with another player. This is, of course, all sent to the server. If the server detects a hit, it sends a signal to the go-kart that is struck and causes it to slow down, spin out (slightly), or whatever.

Banana Peels are easy too. Dropping the banana peel with the button on your steering wheel will send a signal to the main server. The main server will register the coordinates of this banana peel. Any subsequent player that lands on these coordinates will spin out.

If the player launches a mushroom item, the server responds by increasing the maximum speed of their kart for the duration of the mushroom.

I'll let y'all use your imaginations to think about the other items would be implemented..

#3. Time is simple. When the HUD says "GO", start a timer, and when the GPS (or equivalent) coordinates cross the finish line, stop the count.

#4. Because the coordinates of each go-kart are being broadcast to the server every, say, 100 milliseconds, the server is very capable of understanding how to register which lap the player is on by how many times it crossed a specific point.

#5. Again, because the coordinates of each go-kart are being broadcast the the server - the server is very capable of crunching this data and sending to each HUD, the location of all players on a map.

I'll let you think about how #7 would be determined by the server. Very simple stuff.


I don't have any experience with augmented reality, but I know this is totally possible, and may even already exist. By crossing real-life data computation with the video games we all love, you can come up with really great ideas. Augmented reality is going to change everything when Project Glass is released in 2014. Depending on how Google decides to open their Project Glass API... this could ride atop their software.

Monetization

Charge people in the same way go-kart places already do. Or come up with a more modern price model.

Problems

Legal issues with Mario Kart copyright. You would not be able to brand and market it this way unless you were sponsored by Nintendo, of course. You'd need to change all of the items and HUD positions etc. Would have to look into this. But even as a hobby, this would be an amazing project to work on.

Comments(0)Leave Comment

Introduction

Imagine a flight simulator inside your browser... except instead of computer graphics, it's a live video feed of a RC helicopter, AR Drone, or custom machine. You are able to maneuver this helicopter using the same controls as a simulator. In fact, joystick and gamepad control are coming to your browser soon. The API specification is in draft and javascript libraries like gamepad.js are actively being worked on. What could you do with this technology?

The RC device would communicate to your computer on a licensed channel, WiMax, or even pop a SIM card on board and communicate via 3G. Your browser takes input from control pad, or mouse and keyboard, sends it to the server (probably on the same machine) using websockets, they're handed to a C++ program that accesses the COM ports of the computer. The signal is fed over USB cable to a device (radio) which is subsequently modulated to said frequency. This signal is read by the device, demodulated and the right action is taken (i.e. turn left, or reduce third motor speed to 2900rpm).

Motivation

High speed delivery is impossible because all delivering parties are subject to traffic. What if your pizza was delivered to you in five minutes? What if a grocery store used these to deliver groceries? What if the post office dropped mail at your house using them?

Monetization

Charge for deliveries. Cost would be directly proportional to: weight, cost of air license in that geographical area. And inversely proportional to: expediency.

Problems

Cities are typically restricted airspace. Potentially dangerous. If the device malfunctions, you need a recovery plan. If there is a hardware malfunction (say, broken wing - or the device detects it is out of control...) - deploy a parachute. If there is a communications problem, subtract it's current GPS coordinates from the GPS coordinates of it's take-off to lead it back into a clear communications channel. Once back on communications channel, report said problem to browser (mission control). Must be operating on a channel that is resistant to jamming, or else you'll have hackers crashing these things left right and centre.

Comments(0)Leave Comment

Introduction

The idea utilizes four pieces of hardware. A laptop, a camera, a mobile pocket printer, and a smart phone.

  1. Turn your smartphone into a wifi hotspot.
  2. Connect to this hotspot on your laptop and toss the computer in a backpack.
  3. Put the pocket printer on your waste and plug it into the computer.
  4. Put the camera around your neck and plug it into the computer as well.
  5. Write a basic Linux script to detect when new photos appear on the camera's memory device.
  6. Write a basic Web server so that you can send simple commands to the computer from a web browser on your smartphone.
  7. Walk around busy cities taking photos of people.
  8. When you're happy with a photo, issue a command to the laptop by clicking button in smartphone's web browser.
  9. Laptop responds by FTPing that photo (using your phones wifi hotspot) to a public facing web server.
  10. Public facing webserver responds with short url of how to get to that photo on the internet.
  11. Laptop issues command to pocket printer to print out that short url "Hey, I just took your picture, check it out at http://pho.to/3jdkf"
  12. This piece of paper is given to the random stranger who can view the photo when they get home (or instantly from their smartphone) and decide to purchase it.
  13. Move onto next person!

This is something I'll certainly be hacking together when I get a job and some spendable income.

Problems

  1. Cell phone data plans. Make sure you have unlimited.
  2. Won't work in places without cell service. Linux Script could queue the photos if it detects no internet connection.
  3. Printers are expensive. Why isn't there a Open Source 2D Pocket Printer?

Comments(0)Leave Comment

Introduction

Web servers that are mechanically attached to telescopes with microcontrollers. Users have buttons in the browser that control telescope's X Y Z, zoom level, focus... Users can choose their location. Nevada? Australia?...etc depending on what Sky they want to view. Feed telescope images to browser in real time. Set up competitions to find and identify objects?

Monetization:

Charge users by the minute. hour?...

Comments(1)Leave Comment

gstast (at) gmail (dot) com:
That is such a good idea. So can anyone move or zoom the telecope? Or how does that work? I would like to help. find me on G+ Stas Todromovich or @protostas