Yes they are!
http://www.audioboneheadphones.com/
Tuesday, May 4, 2010
Sunday, April 18, 2010
Sunday with Single-Camera SLAM
It's Sunday and I just felt like writing more about single-camera SLAM. I think it's quite a remarkable achievment. Basically, using a single camera that continually looks for certain features (landmarks), it is possible to create a map in real-time of the environment without knowing any odometry information (which is usually available when SLAM is applied to mobile robots), and without the ability to perceive depth (no stereo vision).
References on this can be found in the (shortly up) updated database on the resources page.
References on this can be found in the (shortly up) updated database on the resources page.
Thursday, April 15, 2010
An Amazing Paper on Vision-based Methods
Just found an amazing paper that deserves its own blog post. It's a huge survey of vision-based mobile robot navigation methods written by Kak and DeSouza in 2002. The goal, as stated by the authors, was to write about vision-based techniques from "the last 20 years". The article contains more than 150 references, and can be found here: http://portal.acm.org/citation.cfm?id=505501.505509.
I should upload the BiBTeX database again, as it contains some more new references.
I should upload the BiBTeX database again, as it contains some more new references.
Monday, April 12, 2010
More Details
I'd like to continue the discussion of the system I am proposing. I would like a flexible multi-sensor and multi-interface architecture, but the fewer the better. I am thinking of having three modes of operation, where at any time at least two modes are active. These modes are outdoors, indoors and backup. The outdoors mode is most certainly based on (D)GPS, and the indoors mode could use WLAN or RFID for example. It shouldn't be too difficult to determine if the user is indoors or oudoors and so this should be done by the system. The fewer user-issued commands the better. The backup mode has two purposes: to provide some minimal functionality even where the other modes fail (for example in a building without an indoor positioning setup), and to make the other modes just a little more stable by continuously trying to figure out whether the indoors or outdoors mode is providing correct information. In order for the latter feature to work the information from outdoors<->backup and indoors<->backup needs to be comparable, which could be a tricky issue. I guess obstacle avoidence could be said to be part of the backup mode as well since it's something that should run at all times. I am still uncertain as to what hardware the backup mode would use; Is machine vision still insufficient? Could laser rangefinders provide enough information? Or might a machine learning approach with a lot of different non-navigational sensors (as described earlier) work? The backup unit should obviously not rely on a map (or anything external), so how exactly can it help the other modes? Those are questions still needing an answer.
When it comes to interfaces I am thinking of two: an audio interface and a haptic one. The primary information channel should be a combination of speech and non-speech audio delivered through stereo bone-conduction headphones (like in the SWAN system). An electronic compass should keep track of where the head is turned, and non-speech beacon sounds should mark the path the user is to take. This essentially augments the reality by overlaying auditory beacons on the GPS (or other) grid. Here it is important not to place the beacons too far apart (it is not enough to place beacons at intersections). Speech synthesis can be used to indicate points of interests and other things that are not related to the navigation task directly. The verbosity of information should adapt to the user's familiarity with the place. The major advantage of the clear difference in purpose between speech and non-speech audio is that it makes it easy to distinguish different types of information intuitively; The mvoement instructions are always the beacon sounds. Speech recognition can be used to provide input. Additionally, the microphone could perhaps determine if the environment is too loud to convey the auditory information (being at a concert for instance). To still be able to navigate in such a situation, the auditory beacons could be translated into haptic feedback in a belt. If haptic feedback can be provided in all directions around the body, then it is quite natural to feel the beacons rather than hearing them. There might also be other uses for the haptic interface.
In the (hopefully not too distant) future where these kinds of systems are common assistive tools, a lot of additional functionality can be added beyond navigation.
When it comes to interfaces I am thinking of two: an audio interface and a haptic one. The primary information channel should be a combination of speech and non-speech audio delivered through stereo bone-conduction headphones (like in the SWAN system). An electronic compass should keep track of where the head is turned, and non-speech beacon sounds should mark the path the user is to take. This essentially augments the reality by overlaying auditory beacons on the GPS (or other) grid. Here it is important not to place the beacons too far apart (it is not enough to place beacons at intersections). Speech synthesis can be used to indicate points of interests and other things that are not related to the navigation task directly. The verbosity of information should adapt to the user's familiarity with the place. The major advantage of the clear difference in purpose between speech and non-speech audio is that it makes it easy to distinguish different types of information intuitively; The mvoement instructions are always the beacon sounds. Speech recognition can be used to provide input. Additionally, the microphone could perhaps determine if the environment is too loud to convey the auditory information (being at a concert for instance). To still be able to navigate in such a situation, the auditory beacons could be translated into haptic feedback in a belt. If haptic feedback can be provided in all directions around the body, then it is quite natural to feel the beacons rather than hearing them. There might also be other uses for the haptic interface.
In the (hopefully not too distant) future where these kinds of systems are common assistive tools, a lot of additional functionality can be added beyond navigation.
Wednesday, April 7, 2010
Haptic Feedback
I have always felt that haptic feedback is an intuitive, vast resource largely unused. From a mobility perspective it also offers advantages. I have found some articles investigating the feasibility of haptic interfaces in navigation systems. One of them is http://portal.acm.org/citation.cfm?id=857199.858004
Wednesday, March 31, 2010
Progress report 5
Since last time I posted I have been writing more about using non-positioning type sensors in a navigation system. If this approach can be made to work reasonably well, it could be used as a backup in a complete system. I have also been thinking a bit ahead on how to treat data in a system with an arbitrary number of sensors. I have the idea of a model where a position determination is a weighing of different sensor's data, where the weights might perhaps be learnt at runtime, though for example, in an outdoor environment GPS should be the most important, whereas indoors it could be a WLAN positioning system. The model I am thinking of could take other non-positioning sensors into account, which I think could act as a backup, as (if not using vision) we can get a system that is much lighter on computational resources.
This is probably one of the more confusing posts, but I am just starting to think about the model, and more details will come as I go. I'll add a new reference on non-positioning sensors to the bottom of the BiBTeX database right now. The approach used in that paper is machine learning and a "data cooking" module which they claim reduced the navigation error rate of this approach down to 2%.
I will be away for five days. Happy Easter!
This is probably one of the more confusing posts, but I am just starting to think about the model, and more details will come as I go. I'll add a new reference on non-positioning sensors to the bottom of the BiBTeX database right now. The approach used in that paper is machine learning and a "data cooking" module which they claim reduced the navigation error rate of this approach down to 2%.
I will be away for five days. Happy Easter!
Thursday, March 25, 2010
Progress Report 4
Progress is a bit slow at the moment. Trying to plan out the next section. In the meantime, I'm adding a chapter on navigation using lasers, and also refining what I've written so far. From tomorrow and on I will have no other course to worry about, which is a good thing as I'm preparing to take on the final chapters of this thesis.
Also, when fed up with writing I've been looking at programming libraries (vision, audio, speech...) and some random things that pop into my head from time to time. I just wish computer vision algorithms were better, as vision has huge potential in a travelling aid for someone who lacks it. I want a system to read informational signs in the environment and to tell me if that bus over there is the right one. I'm also giving self-containment a priority, that is, the device should try to rely as little as possible on external information (which might not exist in some places). That doesn't mean such information is useless, however.
I've also tested an ER1 robot. I am able to move it and have it recognise (and say aloud) objects and follow them. It really likes looking at CD's.
Also, when fed up with writing I've been looking at programming libraries (vision, audio, speech...) and some random things that pop into my head from time to time. I just wish computer vision algorithms were better, as vision has huge potential in a travelling aid for someone who lacks it. I want a system to read informational signs in the environment and to tell me if that bus over there is the right one. I'm also giving self-containment a priority, that is, the device should try to rely as little as possible on external information (which might not exist in some places). That doesn't mean such information is useless, however.
I've also tested an ER1 robot. I am able to move it and have it recognise (and say aloud) objects and follow them. It really likes looking at CD's.
Subscribe to:
Posts (Atom)