Planimeter to measure area

I’ve just started a new project.
I’m going to use a PS/2 mouse to make a planimeter.
These are used to measure the area of a scale drawings or maps. These are
useful because they can measure irregular shapes. There are several manual
on the web for these that describe the operation.
I thought it might be appropriate to use a mouse because the invention of
the mouse was based on the planimeter.
First I started with mouse communications. I found a library called PS2 that
had routines for reading and writing a mouse. To my dismay, it only worked
on two of the mice I had to play with.
I’ve since written low level code to replace the ones in the library but I regret
that I’m not good enough at C to create a replacement library. I’'ve just
got the code inline.
I did find the data sheet for the Elan EM84510 and the web page:
to be quite useful.
I’ve done some experiments with both an optical and roller ball mouse.
The optical just wasn’t repeatable enough for the task.
The two roller ball mice I have where quite consistent at X and Y counts
when moving the mouse over several inches and back.
I suspect they will work about as good as a commercial planimeter.
I expect to make a polar planimeter. I will make the arms out of thin
oak with the grain aligned. My work with clocks indicates there are few
materials better, short of special materials like fuzzed quarts, invar or Zerodur,
for temperature length stability.
I’ve found some chromed beads at a craft shop for the joints. I can run
a screw through these with a spring for light tension that should keep the
joints from having any play but allow almost frictionless movement.
What I lack now and am looking for suggestions is the user interface.
I have one of the standard LCD 2 line display shield and I’ve been using
a UNO board.
It has 5 user switches. I do have a pot attached that I’ve used for other
projects but don’t think I should need it here.
I expect the minimum functions to include:

  1. Cumulative count of X
  2. Reset of count
  3. Count hold/start ( useful for larger areas that can be divided.
  4. Perimeter distance total ( may be useful but not usually a planimeter function )
  5. Inch/centimeter conversion ( possible other ratios like acres, kilometers, miles etc )
  6. Calibration method
  7. Entering scale factors ( like from maps scales ratios )
    I suspect some should be done with a menu but I do hate things
    that have to have one select menus, just for basic operation.
    I’d think #3 should be default operation after power reset.
    Any suggestions would be appreciated, especially how one could effectively
    use the display and switches. I always have a harder time with user interfaces.

I did some more research into the problems with the code at:

I found these one possible problem and one real problem. I believe his gohi and golo was not optimal:

PS2::gohi(int pin)
 pinMode(pin, INPUT);
 digitalWrite(pin, HIGH);

PS2::golo(int pin)
 pinMode(pin, OUTPUT);
 digitalWrite(pin, LOW);

I believe should have been:

PS2::gohi(int pin)
 pinMode(pin, INPUT_PULLUP);

PS2::golo(int pin)
        digitalWrite(pin, LOW);
 pinMode(pin, OUTPUT);

I relooked at the code and realized that he was shifting the mask to insert the bit rather than shifting the data. His code was correct, just not how I'd do it. Dwight

That's an interesting idea, but I'm having a hard time relating the use of a serial computer mouse to a wooden polar planimeter. Perhaps a sketch (the pencil kind)..? Are you thinking of using the optical rotation sensors on the wooden arm joints? If so, some areas that would cause me concern /need measurement:-

  • A mouse control system (you) creates a positive feedback loop to the mouse controller (you when you see the pointer on the screen). If the pointer is missing the thingie on the screen, you adjust the mouse and the pointer converges on the thingie. You will not have a feedback loop without a full graphical display. The plotted positions will cumulatively diverge from the sensor readings as you use it.
  • The mouse ball is small (20mm diameter?) and the angular resolution is low, say 5 degrees. If you extrapolate that resolution to a 300mm long planimeter arm, you'll be out by +/- 13mm.

I could have it all backwards though...

1. The mouse is attached to the tracer arm such that the X motion is perpendicular to the trace arm. It is attached near the free end so that it has good gain. Only the X is totaled. The Y is ignored.

At the free end of the tracer arm is a pointer pin to follow the edge of the area to be measured ( no screen, on a paper drawing or map ). The pole arm has a bead pivot at both a fixed end and the joint between the pole arm and the tracer arm. 2. Each mouse mm is 15.7 counts. 6 inches is 2400 counts. I don't see the issue there? I read the mouse position at about 200 ms so that the mouse doesn't overflow ( having a count max of +-256 ). One doesn't go all that fast while following the edge of what is being measured. I keep the total as an integer of +-32K

The joint pivots are constructed such that there is a hole on either piece just large enough to let the bead go into it about 1/4 of the bead. There is to be a screw, washer top and bottom, with a light spring and areo nut clamping it. The screw goes through the bead. I'll have a picture when built.

Most planimeters have a wheel, to measure the sideways movement, near the pivot between the pole arm and the tracer arm. This sacrifices sensitivity for being able to easily drag the measuring wheel sideways for part of the tracing. With the mouse ball, both X and Y movement are equal drag and better for both sensitivity and springiness of the arms if near the tracing pointer. Dwight

I would look at a proper encoder and a decent tracking wheel if you want better performance, these days you can get good cheap encoders like this:

Hi Mark The bearing would be too tight. The encoder needs to have extremely low friction. Besides, I already have a LACISO planimeter. It has an electronic readout. One can blow on it wheel and it will turn. It has special bearings to be almost frictionless. I'm just doing this to see if it is practical to use a PC mouse. I'm a tinkerer and enjoy doing such things. I'm not looking to manufacture them. I already have the mice and a UNO board.

If it turns out practical to work reasonably well, it might be a starting point for others that may need a planimeter for some home project.

Things like, one might want to put a walkway around a number of planted areas in the back yard. They have a drawing but need to know how much gravel rock to order.

All kinds of reasons one might want such a device. If my early experiments are any indication, a roller ball mouse would be better than 1% accurate. An optical still in that order. Enough to order a dump truck load of xx cubic yards of rock and not need to buy a $200 to $300 instrument for just the one project. Dwight

I've seen some optical encoders which don't include bearing, so you can provide your own - just a codewheel and a sensor housing. Still nothing like as cheap as an old junked mouse :)

I've made some progress but it seems like I've been enlisted as a soccer coach. I'm setting up the menu as a state machine. I'll have just a few major states. Each state may have a couple substates. As an example the Area state could be measuring or on hold. The major states would be:

Area ( doing measuring ) Calibrate ( measuring a reference shape ) Scale ( map ratio and metric/English system ) Count ( raw ) Align ( both X and Y displayed ) Save ( might have a save for several results in EEPROM )

I thought more about the circumference and don't think it would be accurate or as useful. Now to define my state engine so it makes sense in C. In Forth I create my own state syntax and building instructions. Dwight

I can't think of anything else needed.