What I Did On My Day Off (video)
A few weeks ago I read through Phil Pi's wheel encoder document several times, and took the sample programs apart a line at a time. The document and code are dense but great, and I suggest making them required reading for anyone building a robot. I had plans for this knowledge, but time has been short.
Today I had a day off with nothing that needed doing. So I could finally put in time on a project I had in mind (The Erco inspired one). The project involves my BS2e powered CBA robot, wheel encoders, a compass sensor, a say it module, and an LCD for debuging.
So I sat down and entered the code zone, not even kids or a barking dog could distract me. I made good progress during the day and only just stopped because my NiMH batteries were spent. They are back in the charger, but that means I can't make a video of what I completed as I planned.
But I'll attach the in progress code for curious souls who want to take a peak:
CBA Sayit.BSE - the main module which uses the say it module.
MotorsAndSensors.BSE - the motors and sensors module called in response to tasks.
It's multi-bank and fairly big, but could be stripped down and run on a BOEbot with some porting work. Given that the source for this project came from BOEbot samples it isn't hard. This project put me in an "I heart PBasic" mood as it is a no drama programming environment.
Today I had a day off with nothing that needed doing. So I could finally put in time on a project I had in mind (The Erco inspired one). The project involves my BS2e powered CBA robot, wheel encoders, a compass sensor, a say it module, and an LCD for debuging.
So I sat down and entered the code zone, not even kids or a barking dog could distract me. I made good progress during the day and only just stopped because my NiMH batteries were spent. They are back in the charger, but that means I can't make a video of what I completed as I planned.
But I'll attach the in progress code for curious souls who want to take a peak:
CBA Sayit.BSE - the main module which uses the say it module.
MotorsAndSensors.BSE - the motors and sensors module called in response to tasks.
It's multi-bank and fairly big, but could be stripped down and run on a BOEbot with some porting work. Given that the source for this project came from BOEbot samples it isn't hard. This project put me in an "I heart PBasic" mood as it is a no drama programming environment.
BSE
18K
Comments
It was connected properly as it plugs into the app mod socket and I was able to communicate using the default pins, so it's pretty goof proof.
Long story short, I need to find a new way to do my compass/odometry demo.
Martin, you sure know how to build drama and keep us coming back!
When I get the new one I can do the uber-demo. In the mean time I'm working on a smaller one.
The key thing going on is that the robot has a command set in the EEPROM. Current commands include: move, turn, turn on one wheel, match compass heading, and halt. Future commands will include goto XY, grip, and release. In my first program I was processing commands directly from the Say It module, although I planned to write them to EEPROM for replay. Since the Say It module died, I can just use the EEPROM.
As it moves you may notice the robot stop, alter course, then continue. That's Phil's code which compensates for lack of encoder granularity. Originally had my own servo and encode routines. But I read Phil's encoder document and began copying his code. By the time I was done it was Phil's encoder code which just smidgen of my code.
At the end I zoom in on the LCD which shows the heading, the XY position, and the current command (HALT in this case). The idea is now that the robot knows its XY location it can compute a vector to any other XY location and go there.
MotionScriptMain.bse - A generic motion script program. It replays commands and arguments from EEPROM.
MotorsAndSensors.BSE - The motor and sensor routines. All the odometry work is done here.
Gripper.bse - Bank 2 filled up so I moved the gripper code here
Here's a video of a script being replayed:
http://www.youtube.com/watch?v=OPb_5ag9ZVc
Here's the byte stream motion script for the robot in that video:
Commands DATA TaskTurnCompass, NORTH
DATA TaskPause, 255
DATA TaskMoveXY, 60, 60
DATA TaskMoveXY, 60, 70
DATA TaskMoveXY, -60, 70
DATA TaskMoveXY, -60, 60
DATA TaskMoveXY, 0, 0
DATA TaskTurnCompass, NORTH
DATA TaskHalt
All in all it was much more work than the simple path lets on. Trig using eight bit integer math where negative numbers in division are forbidden is no picnic. Even if your wheels don't slip or drop encoder counts, math truncation errors mount up. For example moving to 60,60 results in 59,59 and this compounds with each movement over time.
Be proud of your results, you achieved VG accuracy given that you had potential errors creeping in from the compass, encoder sensors, trigonometry and integer math. Way cool, Bravo! BTW, which compass sensor are you using?
My compass is Parallax's Hitachi HM55B Compass Module mounted on the back of the Ping bracket. It's a good sensor and the three wire synchronous serial interface is easy to use. Mounting it on the Ping saves room on the protoboard, and it's simple to adjust the compass reading for the declination of the Ping sensor.
If I was buying one today I might consider an I2C model if I could find other I2C sensors. The BS2e's larger EEPROM and scratch pad RAM make a big difference in the kinds of programs I can write. But I keep bumping up against the 16 pin barrier.
Time for the next step. I use the compass sensor to zero out heading errors, but errors distance from origin will likely compound over time. So I need some way to zero that out as well. I can think of two ways:
One way is to use the corner of the room as a baseline. Have the bot move South until it hits a wall, then move East until it is in the corner. Set XPOS and YPOS to some accepted value. I think this would work, but it strikes me as a bit brute force. Plus driving into a corner wastes time and invites getting stuck.
What I'm going to do instead is mark the origin point, and use a sensor to allow the robot to know it is over the origin. The RFID sensor and tag seems like just the ticket. But my local Radio Shack didn't have the RFID sensors on sale. But Amanda Ward was kind enough to act as my proxy to buy one. So if I get a chance I'm going to try that this weekend.
I now have the adapter and display on their way from gravitech.