One of the reasons I find this project so much fun is that I have really set this aside as a "hobby", and am not letting myself feel guilty for jumping around or "not sticking to the plan". I also have not "forced" myself to work on it when I really didn't feel like it, or had too many other things going on. The down side of this is that if I'm not carefully, I end up loosing focus, and make no progress. To prevent things from going "stale" or getting "swamped", I've been keeping a list of things I want to do, and where I want to head. Sometimes this list is in my head, sometimes "written down", meaning in the computer. Here's some of my thoughts. All in all, enough to keep me busy for a couple years or so.
At this time, I have the Nomad walking (sort of). I know I need to make the walking engine better, but a core part of the problem is communication. Before I can fully address the communication issues, I need to know all of the things I want to communicate. Up to now, all I've done is work on making the Nomad walk. This is mostly sending communication to the Nomad. I need to get some things in place that have requests from the PC going to the Nomad, and data coming back.
I'm going to start with a Ping:))) sensor or two, as well as some PIR sensors. I believe I'll end up with one or more groups of sensors on a Pan/Tilt unit.
Key to future plans for the Walking Engine is knowing the attitude of the Nomad decks. One of the goals of the Walking Engine is keeping the deck level on uneven terrain. To sense this I'll be using a two and/or three axis accelerometer.
On other significant sensor I would like to develop would be some type of touch sensor for the feet. I want to sense when the foot is in contact with something, both on the bottom surface, or from the sides. This would ideally feed back to the walking engine to let the system know when the foot is on the ground.
While video and communication seem odd bedfellows, in this case they are tied closely together. The long range plan is for the Nomad to be a "free range" robot, and use 802.11x wireless communication. While there are other more direct wireless protocols, including things like xbee with a longer range, the IP will link directly to a laptop, and also allow transmission of video (and audio). I will be using an Axis 213 PTZ camera. The connection module for this camera has a serial port. The plan is to use this serial port for communication with the microprocessors. I've looked into the API for the camera enough to see that it "should" work. The distance from "should" to "is" is filled with potential potholes.
At any rate the plan is to get the camera in May, work out the IP and Serial Communications, and also determine the best way to get the IP set up as "wireless". In addition to conventional 802.11 hardware, I may look at some higher powered (and longer range) alternatives meant for building to building links. My main concern with these units is power consumption. If I need to run a 2,000 foot power cable, it really doesn't matter that the communication is wireless.
The SG6-UT Arm is a pleasant surprise. I really didn't expect this for a while, but now that I have it, it adds some interesting twists. First, if the Arm is in place, will the video camera also be installed, and if not, what will I use for communication? The most significant issues have more to do with how to control the arm. Should the arm be controlled by the same microprocessor as the Nomad? Should they each have their own microprocessor? Should there be one "master" microprocessor, and multiple "device" microprocessors? See the discussion on Microprocessors below.
Most significantly, a control and communication protocol needs to be worked out. The arm involves a whole different set of kinematics. I haven't even begun to come to grips with this.
In addition to "command and control", I can see possibilities for different/additional end effectors. The gripper is a good general purpose tool, but I could see some attachments (or something) for collecting samples of water, dirt, plants, etc. Being able to bring sensors in contact with objects also opens up new possibilities.
I suspect I'll end up doing some basic work on command and control, and let a lot of the other stuff wait for a while.
In addition to being an "accessory" for the Nomad, I also plan on using the Arm for a real live "useful" application. I "need" to have an automatic fish feeder for our "fry" (baby fish) tanks. Commercial automatic feeders do not have fine enough control on the amount of food dispensed. This project may, or may not see the light of day, but will require some type of custom dispenser, as well as "pick and place" programming. I may also add some sensors to test water characteristics and check the water level.
I am happy with the basic concept of the walking engine, but there is a lot of work to do before it is really "useable" for anything other than a demonstration. Among the things that need to be addressed are:
The entire walking engine is based on the PC side. This is fine for development, but is not practicable from an operational and performance standpoint. How much of the engine should be moved to the robot is a key part of development. The Propeller offers a number of possibilities on how this could be done (one cog per leg is one possibility, there are numerous others). Possible solutions range from simply sending end points of the gait steps to the Nomad and having the Nomad handle timing and "servo ramping" to having the entire kinematics engine onboard the processor(s). I'd like to see as much as possible onboard. There may be incremental steps taken, and a number of versions tried.
I am also less than thrilled with the coordinate system(s) I used in developing the engine, and this will need to be addressed. How to merge the walking system coordinates with sensors and the Arm will prove an interesting challenge.
I also only have a basic walk working. This does not yet support "rotating", and I don't have any "adaptive" features in place. By adaptive features, I mean keeping the robot level on uneven ground, or when stepping on an obstacle such as a rock or block. I'd also like to take a stab at climbing stairs.
I'm not sure how much work I'll be doing on this before I work with the sensors and Video camera (and possibly even the Arm) because of how the "entire package" might affect the design and programming of the Microprocessor(s) - see below.
One reason that I want to do some "playing" with sensors and the Arm, etc. before I get too far down the road on the walking engine is so that I can get a plan laid out for what the microprocessor(s) will be, and what division of labor there will be. I am reasonably certain that there will be more than one microprocessor involved with the Nomad. I could see an entire Propeller dedicated to just the walking engine, and another Propeller tasked with overall robot management and control. In this scenario, the master would get input from the sensors, communicate with the PC, and send walking commands to the Walking Engine Prop (or even the Arm). I can also see "sensor groups" with something like an SX processor communicating back and forth with the main unit.
More questions than answers, and lots of possibilities.
The PC software is ready for a "refractoring". The walking engine is OK, but needs an overhaul in terms of coordinate systems. The user interface is currently a kludge of things put in place for various testing and development, and isn't very useful, and less than "user friendly".
My next step is to probably leave the walking engine as is, but re-do the user interface. In addition to making control of walking easier, I want to get some sensor feedback working. Besides having fun with sensors, I really need to get my arms around the communication requirements. This will help determine how much of the walking engine "has" to move onboard. It may also require me to totally re-think how the Nomad and PC will be communicating.