Inspiration: I got this idea watching the intern assigned to me, slide the launchpad back and forth on the desk while he was talking to me.
I really like the form-factor of the launchpad, but outside of it being... well, a Development kit, it doesn't relate well to people who don't already know what you can do with a Microcontroller.
e.g. One of the things that makes the Evalbot such a good platform is how it relates to the consumer right away. I've been looking to find something like that for the Launchpad.
So, watching this launchpad slide back and forth on the desk while my intern discussed his week's workload progress-- the idea of cemented itself.
What if we could make one of our launchpads into a fun measuring device— like a tape measure?
Overall Concept:
Distance is fairly simple to measure.
If moving in a straight line—You can also measure distance by a point of origin, knowing time and a direction.
You will also need to know the unit of measurement (inches, feet, miles etc). Maybe something like an odometer of sorts.
High Level things I need:
I’d need a processor. -Ideally this would be on a platform that could be battery powered.
I’d need a way to input point of origin (maybe a button click).
I’d need a way to count time (I am pretty sure we can use the clock cycles on the processor).
I’d need a way to know which direction I’m headed.
or I’d need to find a way to let the processor know that I’ve reached my end point (maybe another button press?)
Problem Statement: Biggest issue is that without some sort of unit of meaurement— the time is variable between users (I could click move the thing faster and end click than maybe someone else).
Brainstorming--
- Maybe I could use an accelerometre? -- I need to look into that, are they sensitive enough to be able to pick up movement. When would measuring begin occurring and how would it differentiate between movements?
- Does this exist already? I know there are hacks for Odometres today: http://hackaday.com/2011/01/19/make-your-own-odometer-from-scraps/ How can that example help?
- Another idea for determining the end point--- I could use RF access points and use the broadcast strength of the nodes… Issue there is that I’d need 2 points versus just one. *granted lately I have been really fascinated with using the broadcast strength of wireless nodes as indicator as a useful measurement outside of QoS (that could be a blog post on it’s own).
-I'd like to use the MSP430 Launchpad. It's cheap, it's got push buttons and can run off a battery pack... But the issue of determining the distance travelled or time/position seems a little complicated. This would require a hardware addition/modification-- which I'm frankly, terrible at.
-Another one is to use the Eval-Bot. It's got battery power, can run on its own. It's wheels travel on a set timing and could count the rotations x circumference x time... and get a distance. There are bump sensors that instead of using them to detect what it runs into-- I could use the button press as a start and have the bot move forward and then the bump sensor to designate a stop. From the start to the stop would transmit the data. **appealing, because it could actually store the # of wheel turns + when it hits the bump sensor into memory-- and even to the SD Card. We could have it log it's trajectory when it started, when it hit it's bump sensor, what angle it turned and the wheel rotations then-- eventually with the bot + the travel paths you'd be able to measure the size of a room. Useful? Not sure.
Issue is that the Evalbot is normally at least 50+ dollars (on a good deal) and therefore not as attractive.
End Market:
This would be an ideal introduction to the MSP430 Launchpad to someone who just wanted proof on what a micro could do. This relates well to the mechanical/home depot DIY audience versus the Capacitive Touch Demo that is cool-- but for most non-EE/ECE degrees wouldn't imagine where they could use it. This would be a much more relate-able demo + actually be useful.
For the Evalbot? This would really be just a good Computer Science type of exercise in writing code. The peripherals are all there, just the use cases and programming needs to occur. A good lab exercise. Even better if you can transmit the information via wireless to a computer-- or find ways to optimise its path in the least amount of turns. (e.g. If you run into a 90 Degree Corner (both bump sensors activated simultaneously), the bot should assume it found a Room's Corner -- turn 180 degrees and drive straight to try and measure the room's hypotenuse).
Status:
Draft
No comments:
Post a Comment