Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Linux robots



markw at mohawksoft.com wrote:
>>Yes.  Rip open a $5 serial mouse and use its encoder.  I've seen this
>>outlined in an old Circuit Cellar article, though I doubt I still have it.
>>You should get pulses at the mouse's 300DPI.  You might even be able to
>>just mount the mouse pushing up against your wheel without modifications.
> 
> Hmm, that has some interesting prospects I hadn't considered. The one
> problem I have is that I need two: I have a diametrically opposed wheel
> setup.

OK, $10  ;)


> I very much like the idea of an interrupt driven and kernel buffered
> system that I don't have to write or debug. If I rip apart the mouse, I
> could use an axis for each wheel and the buttons for contact sensors. I
> could use select to wait on the serial port. Since the encoders are read
> at the same time, maybe the relational movement will also be more
> accurate.
> 
> I need to think about this, it is a very good concept. Very good inded.
> Thanks.

OK, here's another one, making even less work for you:  gpm has a -D debug 
option that will spew mouse events out to stderr.  Call that and read its 
output and you don't even have to write the serial mouse interface code. 
And, depending on what mechanism you use, the events will be buffered so you 
don't miss any.





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org