Quote:
|
Originally Posted by jonathan lall
Well now that it's out in the open, we've toyed with this concept for some time as a terrain-mapping navigational system, but we never got past the conceptual stages because of the specs on the sensor devices. I was pushing for some research into this the past two years on my team actually, and we did (we believe) figure out how to get two mouse inputs into the controller (we would place one on either side of the robot and judge distance and pitch from those readings), but the main problem with this was purely technical on the sensor side. Simply put, your robot would have to be going very slowly for the sensor to be able to position you. A robot that blasts off at say 10 feet per second in autonomous mode is by a large margin (I don't have the numbers offhand) too fast for such a device. The framerate is not high enough such that the sensor (which is really a camera) can take two frames and compare them. Thus, no movement would be detected. Perhaps we've missed something, but our preliminary research into this lead us to that conclusion.
|
I'm not sure what sensor you are refering to specifically, but I'm fairly confident that a mouse can resolve at that speed accurately with the correct optics. If it's "zoomed out" by a factor of 5, wouldn't it logically follow that it's seeing 1/5 the movement, and hence it's normally 12 inch per second max become a 5 foot per second max? I'm not saying it's a solved problem, but it's certainly not a desperate situation by any means.
Mr. Putnam is using an accellerometer to gauge odometry, and the mouse to measure rotation. I was planning on using a mouse for both, each one going through a PAK-XI and then to a serial port. This is possible through Kevin Watson's new serial port driver. This would make debugging hard, as Max Lobovsky pointed out, because you couldn't use printf's to send data back to your laptop anymore, as all the ports would be used. His idea was to multiplex the two streams...
Questions Questions!