Let's Make Robots!

Standard Robotic Library


I remember back in the late 1990s when the Standard Template Library for C++ came out. It made things that took days or weeks into mere hours to solve. It was a revolution in thought, a mind blowing leap forward. 

I was thinking about robotics as I was driving home today, and it occurred to me that there seems to be a lack of standard libraries to solve standard programming problems.  To control a robotic arm, inverse kinematics library.  Put the number of arms, length of each arm, depth of the elbows, voila, you can control the arm.  How about a mapping algorithm for a wheeled robot that needs to cover an area (robotic lawn mower or iRobot Roomba-like bots)?  Put in the turn radius for the robot, length, width, axle length, etc and it will make a map of what it runs into.  Want a balancing robot?  Here's a library to make it balance.  Want to do some control of a heater?  Here is a PID library.  Have an encoder on that wheel?  Put in the distance per pulse, pins for led and pulse from emitter, how often to query the emitter, voila distance.  Learning algorithms?  Artificial intelligence? 

I am new to robotics, so maybe I am missing some resources.  But it seems that these sorts of algorithms written in an object oriented way with a standardized approach would go a long way towards making robotics more attainable and usable by more people.  None of this stuff is really rocket science. We need reentrant, object oriented code with a small footprint. Pick and choose what you need, put the pieces together and it does what you want. The Arduino seems to be the processor of choice so an SRL for Arduino would be great.

And if it doesn't exist, all of us should work together to create this kind of repository of code on LMR.  Look at the open source movement and the impact that has had with Linux.  We really could change the world. 



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

The ideoms which I believe in are

  • It's neat to see $2 million dollars of exotic hardware, but in the end - the surviving software is going to run on off the shelf components
  • A good "standard" library or framework for robotics needs to run on as many platforms as possible - For example all OS's (Mac, Linux, Windows) are currently around because each has valid reasons to exist.
  • A good framework must support being massively multi-threaded
  • A good framework must be a model of "Service Oriented Architecture" - such that in a very complex system - sub parts, and minor systems can be brought up, paused, terminated, or restarted without causing deterement effects to the rest of the system.  If you stub your toe - this won't stop you from seeing with your eyes ;P
  • A good framework needs excellent communication - It should have the ability of being distributed over multiple machine, multiple boards, and multiple systems - It should have a peer-to-peer network topology (This goes with the SOA design - where there is no central system but a distribution of equal nodes)
  • A good framework need excellent version control and extension through pluggables
  • A good framework should be able to communicate with the most popular micro-controllers - When you have PCs talking to micro-controllers - I think this is a design in robotics.  Use the best of both worlds. Computers are great for networking, visual processing, number crunching, voice recognition and other "higher" functions much like your Cerebrum,, while microcontrollers are very good for autonomous nervous like systems.  (Things which are very time critical - e.g. monitoring sensors, motor control, sensor control, etc)

I chose Java, for its current maturity, and the vast amount of well organized, and well written libraries which currently exist.  It being a compiled language might be challenging for some, but Java has many scripting engines, including Python - and interfaces can be created to support scripting.

So that's what I would want if I made a framework.

(now the plug) - MyRobotLab - (http://myrobotlab.org)


To be honest, if I wanted a robotics library, I'd probably make my own. For example, let's say I want to write it in Python because I love Python. I would find libraries for mathematics, kinematics, dynamics, AI, motion planning, collision detection and visualization. I would then write my own code for hardware abstraction (can't skip that, you really have to write it if you're making your own robot). I'll then make all the modules work with each other, and that's it. From there I just have to remember all the API and then code new hardware abstraction stuff for every new robot I make.

and very cool.  I think C++ is more used in embedded realm and can create native, tight code close to the silicon.  But, you are talking about exactly what I would want to do, but just different language.  Same lovely church tucked in the countryside, different pew is all

An Arduino based library to control a robot arm the way you mentioned could be written. You would also need to add different arm configurations and servo ranges. For example my 13Kg/cm servos have an input range from 600uS to 2400uS for 180 degrees but different brands and models use other ranges.

which is just good object oriented design, a servo would be abstracted away as an interface.  (Just an example, not real code here.)

class IServo



    void GoToDegree( float degree) ;


In the InverseKinematics class anyplace it uses a servo, it uses an IServo *.  Write a class which inherits from IServo with the implementation details of interfacing to the hardware for the different types of servos in that class.  Override those servo objects in the InverseKinematics library with your own, and you have a working robotic arm.  Make the arm configurations and the specifics of the arm in different overrideable classes, and the same process is possible. 

robotArm.GrabAt(200,200,0) ;

would then do the same thing no matter what arm configuration, what servo was being used (assuming the hardware integration is correct!).



It's a great idea, but only half the equation is solved with the (admittedly brilliant) plug-in-the-numbers approach. What platform would it be on? What OS would host it? And if you understood the concepts well enough to plug in the relevant information to something as complex as Ik in a library that could be put on a microcontroller, wouldn't the need for a library be beside the point? Markamas mentions Willow garage's ROS, which is cool if you build a compliant machine or have a half million dollars for a PR2, but you'll need a brain a little more powerful even than an RPi for that to be useful- it won't be much help for a Hexapod or an SHR. Consider the complexity of a library for generating a gait on a walker-keeping track of all the joints and limbs is a bigger challenge than the math that determines stride rhythm. Also, on that point, the library would be large enough that you might not want to compile the irrelevant parts into you're code.

There are other pitfalls as well-even the simplest libraries on the most popular platforms are often disappointing-ping.h and servo8bit.h come to mind here.

I hope I don't sound negative about the idea-it really is a good one and should be explored, I just was curious about the plans for implementing it.

about the Standard Template Library is that it took various algorithms and standardized the approach.  The design was very flexible so that if you came up with one of your own, you or anyone else could reuse your class and more importantly the algorithm with no change in the calling syntax.  It was also OS independent since it was C++ code so Unix, Windows all could run it equally well. 

For instance, a linked list was a different class for every type.  STL was one class to make a linked list of any type.  So, the same thing with robotics.  Every time someone wants to create a photovore robot, they have to write it from scratch.  Every time someone wants to create a walking critter, they have to write it from scratch with the help of a few formulas pulled from the internet.  The algorithm is the same, why should the actual hardware really matter?

C++ still seems to be the lingua franka of the embedded world so probably C++ would be the language.  The hardware interface would be abstracted to base classes such as BaseServo with overrides for the particular operating system.  These could then be overridden by operating system for default servos and then maybe particular servo implementations (see my response to Oddbot for more detail).

In the coming weeks, I will pick something and design it for a starting point and post it here.  Keep your eyes peeled.

Well, I know that there are a couple of libraries for Python that can do AI and such.

I will look into them.



Also, Willow Garage seem to have developed some sort of OS. But I personally don't really like it...