/* Adept MobileRobots Robotics Interface for Applications (ARIA) Copyright (C) 2004, 2005 ActivMedia Robotics LLC Copyright (C) 2006, 2007, 2008, 2009, 2010 MobileRobots Inc. Copyright (C) 2011, 2012, 2013 Adept Technology This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA If you wish to redistribute ARIA under different terms, contact Adept MobileRobots for information about a commercial version of ARIA at robots@mobilerobots.com or Adept MobileRobots, 10 Columbia Drive, Amherst, NH 03031; +1-603-881-7960 */ #ifndef ARDPPTU_H #define ARDPPTU_H #include "ariaTypedefs.h" #include "ArRobot.h" #include "ArPTZ.h" #include class ArBasePacket; /** Interface to Directed Perception pan/tilt unit, imprementing the ArPTZ * interface. Functions such as pan(), tilt(), etc. send requests to the PTU. By default, a new motion command will interrupt the previous command, but the awaitExec() function sends a command instructing the PTU to wait for the previous motion to finish. Incoming data sent from the PTU is read every ArRobot task cycle (10hz). If this data contains a message giving the current measured position of the pan and tilt axes, then this is stored as the current pan and tilt positions, and a request for the next positions is sent. (This means that the pan and tilt positions are received as fast as the PTU can send them, but no faster than the robot task cycle.) If no pan and tilt positions have been received, then ArDPPTU defaults to providing as pan and tilt position whatever the last *requested* positions are (from the last use of pan(), tilt() or panTilt()). (This is the standard behavior specified by the ArPTZ interface, and lets you deal with different kinds of PTUs, some of which cannot measure their own position.) You can also always check the last pan or tilt request with getLastPanRequest() and getLastTiltRequest(). To use ArDPPTU you must set the appropriate device connection (usually an ArSerialConnection), open this connection, then call the init() method on the ArDPPTU object. Then, you can use resetCalib() to have the unit perform a self calibration routine, configure power modes, set speeds, etc. The ArDPPTU constructor will switch on power to the PTU when on a Seekur or Seekur Jr. robot. The shutdown() method (and destructor) will switch off power. If a specific DPPTU type was given in the constructor, then some internal conversion factors are set according to that type. If left as the PANTILT_DEFAULT type, then the conversion factors are automatically determined by querying the DPPTU device. PANTILT_DEFAULT is recommended. The DPPTU performs a startup self-calibration routine when first powered on. You can recalibrate by calling resetCalib(). By default the DPPTU is configured to use low power when in motion, and no power on the motors when holding a position. This is OK for most cameras. However, the DPPTU has a very high payload (especially PTU47 for outdoor use) and you may want to enable higher power modes if the PTU slips when carrying heavy payloads using setMovePower() and setHoldPower(). The DPPTU can be connected to a computer serial port (typically COM4) or through a Pioneer microcontroller auxilliary serial port. If the DPPTU is connected to the microcontroller, make sure that the baud rate of the microcontroller-DPPTU connection is at least as fast, if not faster than the connection of the computer to the microcontroller. If it's slower then the commands sent to the DPPTU may get backed up in the AUX port buffer and cause the DPPTU to behave erratically. So, if the computer-microcontroller connection is autobauding up to 38400bps, then make sure that the microcontroller aux port is set to 38400bps, as well, and consult the DPPTU manual for directions on changing its baud rate. @sa the DPPTU manuals and documentation available at http://robots.mobilerobots.com @ingroup OptionalClasses */ /// A class with the commands for the DPPTU class ArDPPTUCommands { public: enum { DELIM = 0x20, /// myQueryCB; char *myDataBuf; ArFunctorC myShutdownCB; int myDeviceIndex; void shutdown(); ArTime myLastPositionMessageHandled; bool myWarnedOldPositionData; ArTime myLastQuerySent; std::vector myPowerPorts; bool myGotPanRes; bool myGotTiltRes; ///@since 2.7.6 static ArPTZ* create(size_t index, ArPTZParams params, ArArgumentParser *parser, ArRobot *robot); ///@since 2.7.6 static ArPTZConnector::GlobalPTZCreateFunc ourCreateFunc; }; #endif // ARDPPTU_H