Laser DRO sensor

[SillyOldDufferModerator @sillyoldduffer]

 

Posted by John Hinkley on 08/07/2020 15:09:25:

…

would it not be possible to utilise the bluetooth capabilities of a wireless mouse to communicate the output to a program running on a computer, tablet or phone in much the same way as Yury has done for the TouchDRO system? See Here.

Regrettably, I don't have the knowhow to implement the idea and write the necessary code to interpret the quadrature output into a meaningful display.

…

What does the panel think?

John

 

By using a suitable computer it may not be necessary to sink deep into techy detail. You could just use the mouse as a mouse – remove the buttons and wheel, but retain it's built-in wireless connection, whether Bluetooth or USB dongle. Provided the host recognises mice for you, mouse movements can be detected without worrying about quadrature decoding, wifi protocols, & event management etc.

My choice for this would be a Raspberry Pi 4 running Linux (Raspbian). In UNIX almost everything is a file, including the mouse, so all the DRO program need do is read a file. In Linux the mouse (and keyboard etc) appear as devices in the /dev/input directory. Each mouse appears as a separate file named 'mouse0', 'mouse1' etc.

As working out which one is yours can be tricky they all feed into one device ie "/dev/input/mice", which captures all mouse events whether touchpad, USB, wireless or Bluetooth.

The mouse sends a stream of 3 byte binary records (24 bits long) where:

• First byte, as an 8 bit unsigned integer, reports button presses
• Second byte, as an 8 bit signed integer, reports relative movement in the X direction
• Third byte, also an 8 bit signed integer, reports relative movement in Y

Mouse data read this way is 'raw', ie unconstrained by the size of the screen or windows. When mouse position is read by software working in a graphical context, the windowing system unhelpfully converts raw mouse readings into absolute X,Y coordinates fixed between window 0,0 and window width, height. Equally unhelpfully for a DRO developer, it scales pointer and cursor movement to suit the GUI's human interface )

GUI programming looks hard – raw is what's needed for a DRO.

Testing /dev/input/mice on my Ubuntu workstation, a slowly moving mouse reports X,Y in steps of 1 or -1. However, fast movement is reported in bigger increments, eg -16. Ordinary mice as owned by me aren't very accurate, and I can't comment on the accuracy of a laser mouse, especially if it's moved quickly.

A basic python program that just prints x, y as the mouse is moved:

Whether or not an ordinary user is allowed to read /dev/input/mouse seems to vary. If not, run with sudo.

The output is a stream of positive and negative numbers showing how the mouse is moving:

Seems to work.

I'm testing on a Workstation with a wireless mouse and USB receiver dongle. A RaspberryPi 4, which has Bluetooth, should work the same way and/or with a Bluetooth mouse. So much for the input problem.

Output: Raspberries can serve X to a remote client over Wifi or Ethernet, or a plug in HDMI TV, HDMI monitor, or small HDMI screen, or the GPIO can be used to drive a I2c LCD, LED or TFT device as commonly done in Arduino projects.

So, I'm suggesting a mouse DRO could be a simple file read file, data format, and display application not needing any complicated programming or deep understanding of computer and electronic innards. Lots of unknowns about accuracy and response times but it looks achievable to me in principle.

Dave

 

Edit Typos galore

 

 

Edited By SillyOldDuffer on 09/07/2020 15:12:27

[KWILParticipant @kwil]

Ian,

It has a dovetail on both sides, one side fixed and the other side has has a captive block (just like a gib) with cap head screws to lock it, just the same as you can lock your cross slide, but pulled vertically. The vertical part (against which the jig plate is presently mounted) can also be used for other things such as back toolholder and is fixed to a T slot across the top edge.

Harrison called it a Single toolpost and auxiliary rear slide .

Edited By KWIL on 09/07/2020 15:22:09

[Robert Atkinson 2Participant @robertatkinson2]

One issue with mouse sensors is that their intended use has a human in the control loop by definition. This means that even faily gross error are corrected subconsiously. In the machine application even small errors will accumulate. A good high contrast, regular pattern for the sensor to look a would help but you may still accumulate errors.

Robert G8RPI.

Edited By Robert Atkinson 2 on 09/07/2020 16:19:04

[Frances IoMParticipant @francesiom58905]

the article by Mark Noel answers some of the accuracy + repeatability questions –

[John HinkleyParticipant @johnhinkley26699]

Kwil,

No need to apologise – that's what happens in a tea/bar room conversation!

Despite Dave (SOD)'s comprehensive reply – for which many thanks – I'm inclined to think it's not going to be worth the effort. I was trying to think when I last did any programming and came to the conclusion it was when I went to evening classes (aged 37) and studied GCE "O" level computer studies. That was 36 years ago! Yes, I got an A grade but we've all passed a lot of water since then and I'm not about to start re-learning that particular skill..

John

[Michael GilliganParticipant @michaelgilligan61133]

Posted by John Hinkley on 09/07/2020 14:07:01:

Oh well. Another seven years on the back burner, then!

John

.

That should give you plenty of time to read this, John

**LINK**

http://www.dicklyon.com/tech/OMouse/OpticalMouse-Lyon.pdf

MichaelG.

[Michael GilliganParticipant @michaelgilligan61133]

Too late to edit:

This is a useful reference to Avago sensors: **LINK**

https://www.bidouille.org/files/hack/mousecam/Understanding%20Optical%20Mice%20White%20Paper.pdf

Dated 2006 … so there may be a newer version available

MichaelG.

[Author]

Posts