Proxy

Now the interesting part. Aldebaran modules are modular. We never #include another module file and instead ask to a proxy to find the corresponding module. If the module does not exist, an exception is raised. You can be in the mainBroker (local call) or myBroker (remote call) syntax. They are identical:

//C++ sample #include "alproxy.h" try { getProxy("ALMotion")->callVoid("walk",1) } catch(...) { //motion library is not loaded or walk function doesn't exist //or 1 is not a motion compatible parameter }

#python sample #some proxy are created by default try: motion = ALProxy("ALMotion") motion.walk(1) except RuntimeError,e: # motion library is not loaded or walk function doesn't exist # or 1 is not a motion compatible parameter

Now, suppose mainBroker and myBroker executables are not connected but we want to call remote commands:

//C++ sample try { // we have to explicitly write IP and port because brokers are not connected ALPtr<ALProxy> motion(new ALProxy("ALMotion",IP,port); // pointer automatically destroyed after try block // or ALProxy *motion = new ALProxy("ALMotion",IP,port); // don't forget to delete proxy manually motion.call("walk",1); }

ALProxy(std::string moduleName) get an access to module. LPC if module is local. RPC if module is remote. For remote access, the proxy executable should be connected to the moduleName executable.
ALProxy(std::string moduleName, std::string IP, int port) get an access to module. LPC if module is local. RPC if module is remote. For remote access, the proxy executable doesn't need to be connected to the moduleName executable.
callvoid(std::string methodName, parameter1, parameter2....) call methodName. No return value
type variable = call<type>(std::string method name, parameter1, parameter2....) call methodName. Type return value.
int ID = pCall(std::string method name, parameter1, parameter2....) parallell/post call methodName. Not blocking function. Return function ID to monitor it





Copyright © 2010 Aldebaran-Robotics - All rights reserved