Shawn Schaerer

I have been working on simulating a pressure sensor for humanoid robots. Pressure sensors mounted on both feet of a humanoid can provide a measure of how the weight of the robot is distributed across its entire body. This information is useful for humanoid robot balancing and stable walking algorithms.

There are a couple of different methods to simulate a pressure sensor and I have been looking at two.  The first method is to measure or read the force that is acting on the sensor and the second is to calculate the force directly using center of mass (COM) and acceleration.

Depending on the physics or game engine that you are using, getting the force on an object might not be an easy task.    I am using the Unity engine with integrated Ageia PhysX so one would think that this force information is available to Unity developers, but it is not!  On to the second method!

Simulating pressure using COM.  If we ignore external forces( servo forces should be negligible for small humanoids, but I will have to experiment with standing and squatting to be sure  ) applied to the robot, the force on a pressure sensor should be directly related to the mass or weight applied and gravity.  So basically to calculate pressure I will:

1.) Calculate the COM
2.) Calculate the applied mass using COM and 3d position of the pressure sensor
3.) Force = M*G

I think this should work.  I have read Pratt’s dissertation on “Exploiting Inherent Robustness and Natural Dynamics in the Control of Bipedal Walking Robots” and have used this information before for implementing basic walking algorithms.

As a first pass I will be implementing this on a simulated Robonova.  Keep ya posted!

robonova balancing on one foot

simulated RoboNova

I can now execute motion commands in a basic program using the direct serial link. Getting data out of the basic program is also easy, but without a properly documented serial protocol it is hard say what is going on. Bottom line writing to the first defined variable works good, but reading other variables some times send commands to the first variable executing motion sequence 1.

I will be implementing a direct serial motion system, but I will be reading and writing to the variables directly to start motions and to find out when they are complete. For this the stock 9600 baud rate will be good enough.

So after posting on the robosavvy forums, one of the members robots42 informed me that you can indeed execute the stock motions that are available in the standard BASIC program. I totally did not read the very first line of the MR3024 serial data sheet, YOU CAN WRITE TO THE FIRST VARIABLE in the basic program. I think I will do some testing and see what I come up with. I would like to be able to read a specific BASIC variable or memory location via the direct serial connection. This would allow my program to find out when a motion command is completed. I think this is possible using READ_DATA and WRITE_DATA and peek and poke.

On Sunday I started to figure out the Robonova. Very interesting robot.  I like the Idea of preprogrammed motions, so I would like to keep that functionality.  

So far I am looking at two ways of communicating with the RN-1 and robotFoundry

1.)  Get servo values and set servo positions all from the built in serial port.

2.) use the ETX and  ERX port and write a basic program to communicate with the PC.

option 1 is the easiest for end users but also the slowest.  This option also means that the predifined motions cannot be used and we would have to replicate them in  robotFoundry

option2 will allow us to transmit data the fastest, but will be a little work for the end user.  The end user would have to wireup a external 5 volt com  port and download the robotFoundry RN1.bas firmware.  Also there are some speed considerations to consider. I have read on the robosavvy forums that the MCR3024 executes one basic command every 1-2ms so this could really slow things down.  What I mean is that if we are sending Joint positions down to the RN-1 and then having these executed on the RN-1 this could take a long time to process and could be slower than the 9600 bps of the built in com port.  I will have to do the calculations and weigh the differences and come up with the best solution.