Over the past few years I have been reading about UML Statecharts and state machines in general, but never found a construct that I liked for small embedded systems. Most designs have some events being fired from outside processes, but in most of the stuff I do the event processing belongs inside of the state machine itself!

I created some macros in C that make it very easy to create a state machine that supports entry actions, transaction testing, and exit actions, all living inside the same case statement, making it very simple to understand and maintain.

It will be very clear what is going by viewing this example . However, I should explain the meaning of the "_EXCLUSIVE" macros...

With the entry action, transition test, and exit actions all inside the same case statement, the default is to execute them in order, potentially finishing all three in a single call. This might be good in some cases, but causes problems when expecting predictable timing through the state machine.

The "Exclusive" versions of the macros only allow one of the three parts of a state to be performed each time in. This means it will always take at least three calls to the state machine to pass through a state.

Try it out, and have fun...

I stumbled upon a very good book about robotics called Robot Modeling and Kinematics , by Rachid Manseur. It is completly about modeling robot arms, and nothing about navigation, etc.

One of the neatest things is that it comes with a bunch of programs that create VRML files to simulate robot arms according to parameters you specify. You run the program, type in some specifications for an arm design, and you can view the resulting animated simulation in your web browser. It uses tons of matrix math, which I don't know much about, but it actually is a fun way to learn about matrix math...;-)

For the FIRST Robotics competition this year, my team used a very simple, one joint robot arm. It worked well, and I don't think I would change it, except perhaps to add a single-axis wrist. I was able to model our arm very easily using the programs that came with the book, and this will help with future designs of robot arms...

I'm actually glad that I didn't find this book until after the FIRST build season; no telling what I would have suggested for out robot after seeing the cool ideas in the book.

One more thing, there are a number of mistakes in the book, but you can download an errata file from the publisher's web site here.

I will post more as I get into modeling robot arms...

I hope that all of the FIRST team memebers reading this had a successful build season, and my best wishes for competition.

I obviously never posted any code to run the DOS chip thing from the robot controller. Hopefully there was enough information posted so that someone could get it running an an RC. I would love to hear from anyone who has run the chip.

I will do some more work on this, and it will definately be ready for next year!

Jim

Actually, I don't have too much to update, I have been totally swamped with the FIRST Robotics programming challenge.

Next week I hope to integrate the DOS chip with the IFI robot controller, so I will post the new code at that time.

Jim

Part I of this series talked about low-level communication with the module, which is done through a single, hardware dependent function. It also talked a little about how to execute some of the module commands.
Read More...