I’m writing an app that helps lock-smiths with safe manipulation, mainly by creating the charts they need on the fly. When trying to gain entry to a safe via manipulation, a detailed analysis of the "wheel-pack" is required and accomplished by charting the relative depth of a “fence” over a “gate”. If all gates are lined up on the pack, the fences lever will drop into the cam gate and the lock will open. If anyone’s interested in a much more detailed explanation, you can find an awesome treatment by Matt Blaze here (starting around 3.3): www.crypto.com/papers/safelocks.pdf
Making the charts is important, and all it really requires is accurately measuring two places on the dial over and over and over, and recording the dial distance between two sounds. So, say the “drop-in” point is between 10 and 15, a sound event might occur at 11.5 and 14.5, or the next time around it might occur at 12 and 15. The lock-smith makes a chart of distance between these numbers and looks for say, a narrowing of numbers, on a chart, or maybe just the lowest place on the chart.
I’m using an old-school radio-shack Telephone Pickup (suction-cup mic) via my Androids headphone jack, to listen for the sound events. And to precisely measure on the dial where the events occur, I’ve simple mounted the phone to the dial with velcro and use SensorManager to figure the distance between the sounds based on how far the phone has been rotated from audio spike-event to spike-event. Which is fine, but I’d like to do it without mounting the phone to the dial. A couple companies used to accomplish it by having a webcam look at the dial itself, but that seems much less accurate than just mounting the phone as I can get more precision using fractional degrees of rotation.
Once you enter the drop-in location, you always will hit one sound, then backup the dial to the next sound, so I was thinking I could simply, listen for the sound event, and then once the dial reverses direction measure to the next sound event, but this would require that the dial move at constant, which won’t happen in real-life. And I guess I could do it by using a dynamixel or servo to move the dial for the locksmith, but again, not a good solution. So my question is if any of you smart folks can think of way that these related rates (distance between sound events and change of dial position) can be quantified without mounting the phone to the dial?
Not a full answer but a few of ideas I can throw at you:
from a control systems engineer point of view I can tell you that the way to accurately measure a rotation without direct access to the shaft is with an encoder.
So maybe you can use Android accessory mode to read an encoder (through an Arduino) that you'll mount on the dial (probably placing a rubber disc on the encoder shaft and touching it against the safe-dial).
This whole effort would be just to avoid sticking the whole phone to the dial and gain some extra precision.
A different approach could be to attach something else on the dial that would generate click noise that you could filter on the sound to differentiate from the safe sound. But that would definitely lower your precision.
Related
Description :
I'm trying to find a way to calculate the distance between the application, and nearby Bluetooth devices.
That, or only detect devices that are x meters away from the device with the application.
Tried so far :
I tried using the Bluetooth's signal strength, but it is not reliable, as it has so many variables other than the distance (rotation of the device, objects between the 2 devices, etc). For example, I kept an eye on a device that was still on a table, and the numbers went up by 10 mBw without neither of the devices moving.
I also thought of using GPS for distance calculation, but GPS's accuracy is vary big compared to the accuracy I'm looking for (+-1m).
I look for lowering the strength of the Bluetooth signal before searching (on newer Bluetooth versions), to find less devices within a lower range. But the people who have tried it say it is unreliable because even at the lowest energy for Bluetooth, the Bluetooth was able to find devices that are about 10m away.
Examples around us :
If anyone has an Apple Watch and a Mac, they'd know that it is possible to unlock your Mac by simpley being close to your Mac while wearing your Watch.
Also, car keys. When you get close enough to the car while carrying the key on you, the car is unlocked.
Notes :
Assume all the devices are Android devices with high their hardware. It's a special implementation, not for everyone
A good discussion of techniques for calculating distance using Bluetooth devices is here: https://vimeo.com/171186055#t=40m15s.
With respect to the Apple Watch and Mac, Apple is using Time-of-Flight via peer-to-peer WiFi to determine proximity at that level of accuracy.
Typical automatic remote keyless entry systems utilize radio pulse, not bluetooth. More advanced systems, like Tesla's Phone key, uses Bluetooth on the phone device, but relies on the driver to physically touch the door handle to complete the process.
This might be possible but not much accurately.
You should approach to it like this:-
You should measure the signal strength, and then measure the distance using the speed of bluetooth (it usually travels 1cm in 100ps). Timing it would be difficult though.
Then, using the data you can easily measure the distance ( it is usually less that 10 m but can go farther).
You would get an answer but it would be really an approximate one.
As per me, the exact measuring is not possible.
I want to be able to take in a file for music, analyze it and then make lights light up to the music. The only problem is, with the board that I built, using Processing has a big delay on the code that runs and it has maybe a obvious 10 ms gap. I need a way to either bring the program back into Arduino, or somehow lower the response time. Any ideas?
It's unclear how you're dealing with the serial communication and where the bottlenecks would start to show up (audio processing/serial comms/both/something else/etc).
Regardless, if you want to do sound analysis on Arduino alone, that will be a challenge, as you'll have a lot less resources to do the FFT number crunching on an 8-bit micro controller.
I would go either of two ways:
Do the sound analysis as efficient as possible on the computer and map it to lights so the software(Processing) only sends minimal data to the firmware(Arduino)(just light data, on a need to know basis). If you have a ridiculous amount of lights you might want to use a serial converter than can handle higher baud rates, but in most cases you shouldn't need that.
Do a minimal sounds analysis on Arduino. If you got your light animations right, you can make something sound reactive using just the amplitude and a bit of easing without getting into FFT/MFC or anything fancier. If you really really want light responsiveness to frequencies consider using a 7 band frequency analyser chip like MSGEQ7. There are Arduino breakouts that make that easier.
I'm writing an app in Google Android 2.1 that needs to know which direction (n/w/s/e) the device (HTC Hero) is facing. The sensor and its listener are working great, but the values I get from the sensor are totally crappy. e.g. it tells me I'd be facing north when the device is facing SW or so...
This seems to be a known problem with android devices. The "solutions" I found on the web look like this:
shake the device around
move the device like an eight
tap on the devices back
This is thought to trigger the sensors recalibration. And: the thing with the "moving around" works for me... but that's not very professional I guess...
so - how do I trigger the recalibration of the orientation sensor from the SDK? I need the sensor to be properly calibrated without any fancy stuff that would make users of this app look like complete idiots while they are "manually" recalibrating their phones...
Is there any way to do this "right"?
EDIT:
Or: is there any way to determine PROGRAMMATICALLY, if the device is correctly calibrated or not? As a fallback-option so to speak... then I could warn the user that the device needs "manual" recalibration.
I don't believe there is a way to know programatically if you compass sensor is calibrated correctly unless you use a secondary data source like GPS. If you can use GPS then when the user is moving you can compare the GPS movement with the compass heading and correct. Remember that local magnetic fields can screw up the compass readings and the devices has no idea if you are out in the middle of a forest or next to a transformer.
With these micro devices there is always a bit of skew you'll have to deal with. If you check the values for the accelerometer as well you'll see that at rest they aren't always returning 9.8 m/s^2 (or at least consistently between devices).
In your help you may just need to tell the user to rotate/twist their phone in a figure eight to reset the compass.
I assume you are referring to the Magnetometer inside the Hero.
Callibrating it is a tough one and will/should always require user interaction for a realiable callibration. There are seperate strategies to deal with that. You could ask users to hold there device in north direction and then recallibrate. If the users don't know where north is, you can ask them to direct zhe device towards the sun and based on location and time you can calculate where that is.
Leaving callibration aside, I would guess that your problem is that the readings you get from the sensor are inaccurate. Of course callibration is a prerequisite for accurate readings, but there are also other factors in play.
It is common practice to complement sensor data from one sensor with the data a different sensor to increase accuracy. You could use the GPS to determine a heading when the user is moving. If he's moving slowly however, this is inaccurate as well. You could integrate the data reported by the Accelerometer to guess about orientation changes (not the absolute orientation). But honestly a Gyrometer would be more ideal in this case.
Systems that work like this are sometimes called Inertial Navigation Systems (INS) because they can, given a fixed point in space, determine their subsequent relative position and orientation accurately without further external data. Using a Kalman filter is common practice to recallibrate the system from time to time when an absolute position (e.g. retrieved via GPS) is available.
Although it is unrealistic to implement a full-fledged INS, you can certainly draw a few ideas from how they work to make your orientation readings more accurate.
I need to obtain the velocity of an android device, based on the accelerometer values. I made a code that allows me to get the accelerometer values, and then I calculate the velocity, using the formula:
v = v0 + at. (vector calculation)
My problem is that my velocity only increases and never decreases. I think the problem is that the device never gets an negative acceleration.
Can you help me with this?
Obtaining velocity from the accelerometers might not be possible (forget reliable) because at constant speed there will be no acceleration (other than gravity). You might be better off obtaining GPS location data and their associated time samples and computing velocity by distance over time.
Are you subtracting out the force of gravity? The device is always accelerating -- even if it is just sitting on your desk, it is accelerating at 9.8 m/s^2 away from the center of the Earth.
You can use a combination of the accelerometer and the digital compass, in phones that have them, to determine a speed and direction as mentioned in this post.
If all you need to do is determine if the person is walking, all you need is the accelerometer. Just process its output for foot steps.
There are plenty of tutorials on the web for detecting foot steps with an accelerometer.
There an app note here: http://www.analog.com/library/analogDialogue/archives/41-03/pedometer.html that gives a decent mathematical background and an example algorithm. Its of course up to you to extract the math and rewrite it for Android (the example code is written in C). I don't currently know of an open source android library with a footstep detection algorithm.
If you implement something, I would like to get the code, don't forget to post back the results.
So I want to make a new music player for Android, it's going to be open source and if you think this idea is any good feel free to let me know and maybe we can work on it.
I know it's possible to speed up and slow down a song and normalize the sound so that the voices and instruments still hit the same pitch.
I'd like to make a media play for Android aimed at joggers which will;
Beat match successive songs
Maintain a constant beat for running to
Beat can be established via accelerometer or manually
Alarms and notifications automatically at points in the run (Geo located or timer)
Now I know that this will fall down with many use cases (Slow songs sounding stupid, beat changes within song getting messed up) but I feel they can be overcome. What I really need to know is how to get started writing an application in C++ (Using the Android NDK) which will perform the analysis and adjust the stream.
Will it be feasible to do this on the fly? What approach would you use? A server that streams to the phone? Maybe offline analysis of the songs on a desktop that gets synched to your device via tether?
If this is too many questions for one post I am most interested in the easiest way of analysing the wave of an MP3 to find the beat. On top of that, how to perform the manipulation, to change the beat, would be my next point of interest.
I had a tiny crappy mp3 player that could do double speed on the fly so I'm sure it can be done!
Gav
This is technologically feasible on a smartphone-type device, although it is extremely difficult to achieve good-sounding pitch-shifting and time-stretching effects even on a powerful PC and not in realtime.
Pitch-shifting and time-stretching can be achieved on a relatively powerful mobile device in realtime (I've done it in .Net CF on a Samsung i760 smartphone) without overly taxing the processor (the simple version is not much more expensive than ordinary MP3 playback). The effect is not great, although it doesn't sound too bad if the pitch and time changes are relatively small.
Automatic determination of a song's tempo might be too time-consuming to do in real time, but this part of the process could be performed in advance of playback, or it could be done on the next song well before the current song is finished playing. I've never done this myself, so I dunno.
Everything else you mentioned is relatively easy to do. However: I don't know how easy Android's API is regarding audio output, or even whether it allows the low-level access to audio playback that this project would require.
Actually, you'll have 2 problems:
Finding the tempo of a song is not easy. The most common method involves autocorrolation, which involves quite a bit of calculus, so I hope you've studied up.
Actually changing the beat of a song without pitch shift is even harder, and still results in sound artifacts in the song. Typically it takes a long time to edit audio in this way, and it takes a lot of tinkering to get the song to sound good. To actually perform this in real time would be very, very hard. The actual process involves taking the Fourier Transform of the audio, shifting the frequency, and taking the inverse Fourier Transform. More calculus, this time with imaginary numbers.
If you really want to work on this I suggest taking a class in signals and systems from an Electrical Engineering department.
Perhaps an easier idea: Find the tempo of all the songs in a user's library, and just focus on playing songs with a close beat to the jogger's pace. You still need to do #1 but you don't need to worry about #2.
Changing the audio speed on the fly is definetly doable; I'm not sure if it's doable on the G1.
Rather than writing your own source I would recommend looking at the MythTV source and/or the mplayer source code. They both support speeding up video playback while compensating the audio.
http://picard.exceed.hu/tcpmp/test/
tcpmp did all that you asked for on an iddy biddy Palm Centro... And More, Including Video! If it can be done on a Palm Centro, it sure as heck can be done on the Android!!