locked
What are the steps to create the "monitor program"? RRS feed

  • Question

  • After reading (Professional Microsoft Robotics Developer Studio, By Kyle Johns and Trevor Taylor) and testing many tutorials (online) and experimenting the existing manifests by LEGO or IRobot, I still don't understand the basic underlying concept of programming the "monitor program". I really wish someone could guide me on creating this.

    Here's what I want to accomplish. I have a PIC microcontroller 18F4550 connected to H-Bridge circuits to control 2 motors, and this PIC is connected to the PC via USB and i already got the firmware working and the PC now recognise the PIC (HID compliant).

    i created a simple service using VPL, in which I use Game Controller connected to Generic Differential Drive and Simple Dashboard. Now if i understand the concept correctly i need to have the monitor program downloaded in the uC for this to work. What should i write in the monitor program for this to work?. I have intermediate understanding of coding using C/C++.

    do i have to write a function in the monitor program, for example to start the motor:

    void StartMotor()
    {
    TRISB = 0x0; //Port B as output
    
    and so on..
    }

    How do i let the MRDS know that the function StartMotor is the configuration for starting the motor? is that the right way to go?

    Really need someone could help me with this confusion. 

    Wednesday, April 25, 2012 10:37 AM

Answers

  • Hello again,

    I put together the VEX interface (http://vexmsrs.codeplex.com/) which uses a slightly different uC - 18f8520. (You might be able to leverage a large part of it for your work. Either way, it might give you some ideas.) Pull down the project and take a look at three pieces:

    1) VEXRobox - This is the uC portion of the interface. The main loop just sits and waits for information to come in the serial port. The system gathers a command packet in ReceiveCmd.c which is a generic command using a verify simple state machine (which knows the packet format and shifts the expectations of what the next byte received should do. Once a complete packet has been assembled and verified, it is sent to the dispatch command routine which dispatches the command and sets up the result values. These routines are generic, but if you go down the motor logic tree, you see it knows nothing about start/stop, it only knows about the power to apply to the motors. (The MRS service knows about start/stop/power/reverse....)

    (I will point out that I have a heart beat built into the system so that if it loses connection that it will set all PWM channels to 127 - stop. You might want to implement something like this if you have any possibility of harm to someone or the robot if the cable gets yanked out.)

    It is basically just a while loop that gets a command of how much 'power' to send to the PWM pins. It looks complicated because I've got the VEX second processor heart beat to contend with and the generic fashion that it handles the sensors with. If you ignore these complicating factors, it is just a simple while loop.

    2) VEX - This is a whole lot of garbage code meant to just format and serialize data to and from the uC. All it 'knows' about is a bunch of IO, motor and interrupt ports on the uC. It assigns usage to each pin it knows about, but that this more for my sanity than anything else. All of this code boils down to just serializing access to the serial port to send one coherent command to the uC.

    In your case, I'd define a few command packets that match your hardware expectations. e.g. data packet struct SetDrivePower { byte leftPower; byte rightPower; byte enableDrive }. This would set the two PWM channel values and flip the IO ports that control power to the drive.

    Think of the uC code as just an extension of the VEX service. It is really just a a single task that is implemented on multiple processors.

    3) VEXService - This is the glue that connects between the two worlds - the MRS generic interfaces (e.g. DriveOperations) and the generic port realm of the service. Look at the VEXDrive source and you see that it just scales the input request to the range of values expected by the generic interface and coordinates several things. (e.g. stop sends 127 to both motors which is stop for this system. For your system, send the 'neutral' power to both motors and set the drive enable to false.)

    Think of the VEX services as just implementing the request of the VEXDrive service. (In your case, you could then connect the GameController service to the VEXDrive service to drive your robot. See the various VPL samples both in my sample code and on the tutorials.)

    In your case, I doubt you need the equivilent of the VEX service at all and can have the drive service connect to your USB connection and send the data packets directly. If the uC commands match up with the service operations, then great. (If they don't, then you got too carried away with the uC code and probably should simplify it to match the service operations.)

    If you have specific questions about this code, you can reach me at EdHarfmann at Comcast dot net. I hope this has helped clarify some things for you. I hope this has helped.

    Ed Harfmann

    Wednesday, April 25, 2012 12:43 PM

All replies

  • Hello again,

    I put together the VEX interface (http://vexmsrs.codeplex.com/) which uses a slightly different uC - 18f8520. (You might be able to leverage a large part of it for your work. Either way, it might give you some ideas.) Pull down the project and take a look at three pieces:

    1) VEXRobox - This is the uC portion of the interface. The main loop just sits and waits for information to come in the serial port. The system gathers a command packet in ReceiveCmd.c which is a generic command using a verify simple state machine (which knows the packet format and shifts the expectations of what the next byte received should do. Once a complete packet has been assembled and verified, it is sent to the dispatch command routine which dispatches the command and sets up the result values. These routines are generic, but if you go down the motor logic tree, you see it knows nothing about start/stop, it only knows about the power to apply to the motors. (The MRS service knows about start/stop/power/reverse....)

    (I will point out that I have a heart beat built into the system so that if it loses connection that it will set all PWM channels to 127 - stop. You might want to implement something like this if you have any possibility of harm to someone or the robot if the cable gets yanked out.)

    It is basically just a while loop that gets a command of how much 'power' to send to the PWM pins. It looks complicated because I've got the VEX second processor heart beat to contend with and the generic fashion that it handles the sensors with. If you ignore these complicating factors, it is just a simple while loop.

    2) VEX - This is a whole lot of garbage code meant to just format and serialize data to and from the uC. All it 'knows' about is a bunch of IO, motor and interrupt ports on the uC. It assigns usage to each pin it knows about, but that this more for my sanity than anything else. All of this code boils down to just serializing access to the serial port to send one coherent command to the uC.

    In your case, I'd define a few command packets that match your hardware expectations. e.g. data packet struct SetDrivePower { byte leftPower; byte rightPower; byte enableDrive }. This would set the two PWM channel values and flip the IO ports that control power to the drive.

    Think of the uC code as just an extension of the VEX service. It is really just a a single task that is implemented on multiple processors.

    3) VEXService - This is the glue that connects between the two worlds - the MRS generic interfaces (e.g. DriveOperations) and the generic port realm of the service. Look at the VEXDrive source and you see that it just scales the input request to the range of values expected by the generic interface and coordinates several things. (e.g. stop sends 127 to both motors which is stop for this system. For your system, send the 'neutral' power to both motors and set the drive enable to false.)

    Think of the VEX services as just implementing the request of the VEXDrive service. (In your case, you could then connect the GameController service to the VEXDrive service to drive your robot. See the various VPL samples both in my sample code and on the tutorials.)

    In your case, I doubt you need the equivilent of the VEX service at all and can have the drive service connect to your USB connection and send the data packets directly. If the uC commands match up with the service operations, then great. (If they don't, then you got too carried away with the uC code and probably should simplify it to match the service operations.)

    If you have specific questions about this code, you can reach me at EdHarfmann at Comcast dot net. I hope this has helped clarify some things for you. I hope this has helped.

    Ed Harfmann

    Wednesday, April 25, 2012 12:43 PM
  • Thanks again Ed,

    1) the VEXRobot that you referred to is it the one in the folder of VEX/samples/vexrobot ? because all i can see in that folder are the two hex files. can you point out which file is the uC code?. 

    EDIT: i mean the source file for the uC.

    EDIT: i downloaded the wrong file, but now i got the source files, and im studying it if i hv any question i'll let you know later.

    Thank you for your time.



    Thursday, April 26, 2012 10:18 AM
  • We have not seen aresponse from you in some time.  To better track active open issues we are
    marking this thread Answered. I hope the issue is resolved.  If it is not
    resolved please start a new question as this one will remain Answered and will
    not get the necessary attention
    Thursday, May 3, 2012 8:14 PM
    Moderator