Cheap planar position sensor based on PS / 2 Mouse, MatLab + MBED + PS / 2 Mouse

    Well, try number two.

    In this post I will try to talk about one of the parts of my graduation project.
    Using a mouse type controller as a planar position sensor.

    What is the plus of the Mouse?

    Formulation of the problem.

    • Getting coordinates from a mouse controller in the MatLab software package

    First, a little theory.
    Working with a mouse in MatLab will be implemented by working with rs232 (on a different com port), the MBED controller will communicate with the mouse and issue 3 bytes packets to the com port upon request. In MatLab, with the help of a simple block diagram, packet analysis will be performed, followed by analysis into control signals and data signals.

    Why was the method of communication through rs232 chosen? Because this way allows you to implement the work with the mouse through the standard MatLab blocks, thereby leaving the possibility of use in all modes (Simulink, RTW, xPC).

    Let's take a look at MBED now.

    As we can see, the controller has just a crazy amount of ports, out of this variety we need only 4, and 2 of them will be powered :)

    Here is what it looks like in a prototype board. The

    mouse works with the end device via 2 DATA and CLOCK ports, by names I think it's not difficult to guess what is what;)
    In our case, we connect CLOCK to the 28th leg of the controller, and DATA to 26.
    We take power from GND and VU legs.

    The program for the controller is extremely simple

    ///////////////////////////////////////////// ///
    //////////////////////////////////////////// ////
    #include "mbed.h"
    #include "PS2Mse.h"
    PS2Mse mse ( p28, p26 ) ;
    Serial pc ( USBTX, USBRX ) ;
    int  main ( )  {
        mse. wr ( 0xf0 ) ;
        mse. wr ( 0xff ) ;   // reset
        mse. rd ( ) ;   // ack byte
        mse. rd ( ) ;   // blank * /
        mse. rd ( ) ;   // blank * /
        mse.wr ( 0xf0 ) ;   // remote mode
        mse. rd ( ) ;   // ack
        char  mstat ;
        char  mx ;
        char  my ;
        while  ( 1 )  {
            while  ( pc. getc ( ) ! = 0 )  {
                mse. wr ( 0xeb ) ;   
                mse. rd ( ) ;       
                mstat  =  mse. rd( ) ;
                mx  =  mse. rd ( ) ;
                my  =  mse. rd ( ) ;
                pc. printf ( "% c% c% c \ r \ n " , mstat, mx, my ) ;

    PS2Mse. cpp
    dumpz .org / 17295
    ////////////////////////////////////////////// //
    ///////////////////////////////////////////// ///

    As we see everything that the program executes, it waits for any character from the host (PC) and in response gives the current values ​​of coordinates and mouse buttons in the form of a 3-byte packet.

    Consider what happens next.
    Here's what our block for working in MatLab looks like.
    Let's look inside the Mouse block.

    As we can see here, everything is quite simple too, the first byte is being analyzed, 7 flag bits are extracted from it
    • 1 - First mouse button pressed
    • 2 - The second mouse button is pressed
    • 3 - Third mouse button pressed
    • 5 - X increment sign
    • 6 - Y increment sign
    • 7 - Overflow on X
    • 8 - Y overflow

    The second and third bytes are increments in X and Y, respectively.

    As we can see, using a mouse is very simple.
    If someone is interested, then there will be metrological studies of the mouse.


    By the way, a little clarification, my diploma is about something else, the sensor was “asked” to me (as usual at the institute) to help another specialist;)
    My diploma is about completely different things, and more specifically about the Lego balloon and compass :)

    Nus let's try to explain a little why all this fuss was.
    There is a task of controlling a two-link nonrigid manipulator.
    Many methods have been tried to determine the final position of each link, from tensometers glued to the links, ending with crazy ideas with laser distance sensors.
    The ultimate goal is to determine where the link still moved after supplying control pulses to the servos, since the link is non-rigid, and also the design has some inertia, then it makes no sense to use tachogenerators and counters of the engines themselves.

    Under MatLab, sharpening was carried out precisely for this modeling / programming, selection of PID and similar controllers. A link with approximately the same tasks in the diploma

    In general, the topic of managing non-rigid manipulators is a favorite topic of the specialty of the Control System, so much has already been written about this topic.

    The mouse was taken because the ready-made proximity sensor in the price clearly exceeds the cost of the mouse.

    I tried as best I could to explain, on March 9 I will take a picture and try to explain in detail.

    Also popular now: