Difference between revisions of "Motor control"

From Wiki for iCub and Friends
Jump to: navigation, search
(Motor control in Yarp, a brief tutorial)
(Motor control in Yarp, a brief tutorial)
Line 1: Line 1:
 
== Motor control in Yarp, a brief tutorial ==
 
== Motor control in Yarp, a brief tutorial ==
  
Motor control in Yarp is done through a device driver. For more documentation please see: [http://www.example.com Yarp on SF] and the related classes. The project on the iCub repository under src/simple_headcontrol is a good example to start playing with motor control. This example uses a remoted device driver which exports exactly the same interfaces of the actual device driver ('''initialization is different'''). Clearly, the main difference between the two is in terms of efficiency, if you're developing a low-level control loop you might want to be local, on the other hand a simple sporadic position control can be effected through the remote device driver. Let's assume we have started the server side already (e.g. using yarpdev).
+
Motor control in Yarp is done through a device driver. For more documentation please see: [http://yarp0.sourceforge.net/specs/dox/dev/html/yarp_motor_control.html yarp2 documentation] and the related classes. The project on the iCub repository under src/simple_headcontrol is a good example to start playing with motor control. This example uses a remoted device driver which exports exactly the same interfaces of the actual device driver ('''initialization is different'''). Clearly, the main difference between the two is in terms of efficiency, if you're developing a low-level control loop you might want to be local, on the other hand a simple sporadic position control can be effected through the remote device driver. Let's assume we have started the server side already (e.g. using yarpdev).
  
 
In practice, we start by preparing a set of configuration parameters:
 
In practice, we start by preparing a set of configuration parameters:
Line 64: Line 64:
 
         pid->enablePid(i);
 
         pid->enablePid(i);
 
     }
 
     }
 +
 +
if needed we can check the position of our axes by doing:
 +
 +
  enc->getEncoders(q);
 +
 +
which reads the values of the motor encoders into a vector of doubles of size ''jnts''. Admitting we know where to go we can now issue a:
 +
 +
  bool ok = vel->velocityMove(control_velocity);
 +
 +
which for example accelerates all axes to the velocity described by the vector ''control_velocity'' (in degrees per second). Similarly you can do:
 +
 +
  int i;
 +
  for (i = 0; i < jnts; i++) {
 +
      tmp[i] = 40.0;
 +
  }
 +
  pos->setRefSpeed(tmp);
 +
 +
which sets the reference speed for all axes to 40 degrees per second. Now you can do:
 +
 +
  bool ok = pos->positionMove(control_position);
 +
 +
where ''control_position'' is the desired position. This starts a movement of all axes toward the desired position. The position and velocity commands can be intermixed (presently we have a bug though which make the controller to get stuck, sorry!). When done with the robot, the application can finalize the control sequence by disabling the amplifiers and closing the device driver.
 +
 +
  for (i = 0; i < jnts; i++) {
 +
      amp->disableAmp(i);
 +
      pid->disablePid(i);
 +
  }
 +
  dd.close();
 +
 +
== Notes on the local device ==
 +
The EsdMotionControl class in libYARP_dev is an example of a local device driver. The procedure to instantiate it is conceptually identical to the sequence illustrated here apart from the parameters passed to open() which are more numerous and complicated. These are typically stored in a .ini file and loaded through the Property class and the fromConfigFile() method.
 +
 +
== An alternate client ==
 +
Another client is available in the iCub repository at src/simple_client.
 +
 +
== Efficiency issues ==
 +
Encoder values and commands are read or written through streaming ports. All other calls are RPC with return values and thus potentially slower.

Revision as of 19:29, 25 July 2006

Motor control in Yarp, a brief tutorial

Motor control in Yarp is done through a device driver. For more documentation please see: yarp2 documentation and the related classes. The project on the iCub repository under src/simple_headcontrol is a good example to start playing with motor control. This example uses a remoted device driver which exports exactly the same interfaces of the actual device driver (initialization is different). Clearly, the main difference between the two is in terms of efficiency, if you're developing a low-level control loop you might want to be local, on the other hand a simple sporadic position control can be effected through the remote device driver. Let's assume we have started the server side already (e.g. using yarpdev).

In practice, we start by preparing a set of configuration parameters:

 Property options;
 options.put("robot", "icub"); // typically from the command line.
 options.put("device", "remote_controlboard");
 Value& robotname = options.find("robot");
 yarp::String s("/");
 s += robotname.asString();
 s += "/head/control";
 options.put("local", s.c_str());
 s.clear();
 s += "/";
 s += robotname.asString();
 s += "/head";
 options.put("remote", s.c_str());

where the local and remote parameters are used to set the port names for the connection to the server side. To create the driver we use the PolyDriver:

 PolyDriver dd(options);
 if (!dd.isValid()) {
     ACE_OS::printf("Device not available.  Here are the known devices:\n");
     ACE_OS::printf("%s", Drivers::factory().toString().c_str());
     Network::fini();
     return 1;
 }

which instantiates the driver. If the parameters are correct and the server side has been prepared the local driver also connects to the remote one. The next step is to get a set of interfaces (pointers to) to work with, for example:

   IPositionControl *pos;
   IVelocityControl *vel;
   IEncoders *enc;
   IPidControl *pid;
   IAmplifierControl *amp;
   IControlLimits *lim;

and:

   dd.view(pos);
   dd.view(vel);
   dd.view(enc);
   dd.view(pid);
   dd.view(amp);
   dd.view(lim);

if everything went ok the pointers are now different from NULL (check it!). We can thus start with checking how many axes we can control by doing:

   int jnts = 0;
   pos->getAxes(&jnts);

and then starting up the controller and the amplifier:

   int i;
   for (i = 0; i < jnts; i++) {
       tmp[i] = 50.0;
   }
   pos->setRefAccelerations(tmp);
   for (i = 0; i < jnts; i++) {
       amp->enableAmp(i);
       pid->enablePid(i);
   }

if needed we can check the position of our axes by doing:

 enc->getEncoders(q);

which reads the values of the motor encoders into a vector of doubles of size jnts. Admitting we know where to go we can now issue a:

 bool ok = vel->velocityMove(control_velocity);

which for example accelerates all axes to the velocity described by the vector control_velocity (in degrees per second). Similarly you can do:

 int i;
 for (i = 0; i < jnts; i++) {
     tmp[i] = 40.0;
 }
 pos->setRefSpeed(tmp);

which sets the reference speed for all axes to 40 degrees per second. Now you can do:

 bool ok = pos->positionMove(control_position);

where control_position is the desired position. This starts a movement of all axes toward the desired position. The position and velocity commands can be intermixed (presently we have a bug though which make the controller to get stuck, sorry!). When done with the robot, the application can finalize the control sequence by disabling the amplifiers and closing the device driver.

 for (i = 0; i < jnts; i++) {
     amp->disableAmp(i);
     pid->disablePid(i);
 }
 dd.close();

Notes on the local device

The EsdMotionControl class in libYARP_dev is an example of a local device driver. The procedure to instantiate it is conceptually identical to the sequence illustrated here apart from the parameters passed to open() which are more numerous and complicated. These are typically stored in a .ini file and loaded through the Property class and the fromConfigFile() method.

An alternate client

Another client is available in the iCub repository at src/simple_client.

Efficiency issues

Encoder values and commands are read or written through streaming ports. All other calls are RPC with return values and thus potentially slower.