Recently I bought a wireless Xbox controller purely for use with Microsoft Robotics Studio, to remote control the PEDRO quadruped robot and steer it around the floor. To get to this pretty simple goal, a lot of steps are needed - I already had a simulation of the robot going in Robotics Studio, and even walking, but in a very 'canned' sequenced fashion, with all the joint angles moving between key frames that are hard coded. See this blog post for a video of the rather unsteady robot simulation walking in a straight line. This method won't do if you want to control the robot in an unplanned fashion where the direction and speed of walking are able to change at any time, so a more sophisticated approach is needed.
Since then I have written several robotics studio services to support the robot. One communicates with the real physical robot (still in progress), another controls the simulated robot. These two implement the same 'generic contract' as robotics studio terms it, so other services can be built to interchangeably communicate with either the real or simulated robot without any recompilation. A third robotics studio service implements the 'generic differential drive' contract so that it can accept differential drive control signals from other services which use this contract. This service contains all the software which implements the new walking algorithm capable of rotation, walking in any direction and varying the speed of the robot. The output of this service is essentially a continuous set of joint angles which can get sent to either the real robot control service or the simulation robot service.
The beauty of allowing the walking service to accept differential drive control signals (also called skid steering) is that potentially many different services can be connected up to control PEDRO, even though the original authors of the services have not even seen the robot. The drawback is that there is not much control with just a left and right motor speed signal for a 14 degree of freedom quadruped robot! However I will allow more complicated forms of control in the software which will work with services I create, as well as the more standard differential drive control. Another cool little side benefit is that the standard dashboard service supplied with robotics studio accepts input from the mouse or game controllers like the wireless Xbox controller and so can be used to remote control your robot with a convenient wireless handheld device. Because of this, I had to buy one to try it out!
I'm still working on a video which describes the technical detail behind the actual walking algorithms, and I'll post it when its done. Of course making the robot walk in simulation, and making the real robot actually walk across your floor might be two very different things - and this is something I'll hopefully find out pretty soon as the hardware has progressed really well.
The physical robot is now fully wired up with all the AX-12 servos connected up to the onboard controller which is communicating over WiFi quite well. I can manually drag a slider up and down and move individual joints one at a time using a slightly modified version of Scott Ferguson's DynaCommander software. I haven't fitted any battery to the robot yet, so it is still tethered to a power supply, because I would like to put a dummy weight equal to the battery weight (nearly half a kilogram for the one I want to use) onto the robot to make sure it can lift and carry this weight comfortably. This way if the robot can't in practice support the heavy battery I can still source and fit a lighter battery option with less run time.
I'm currently working on the service which will replace the simulation and communicate with the real robot. When that's tested and debugged it will be really interesting to see if the walking software that works so well in simulation can work as well in reality!
0 comments
Post a Comment