My code to command the robot to go x distance or turn x degrees works great .. .the issue is that due to slight differences in the motor speeds, the robot could be off by as much as an inch in a 2 foot span. So I decided to change the system over to a target based one.
The code is inspired/copied from David P Anderson's find_target and odometry code. I did add some tweaks of my own, and I've not yet started on using an RTOS.
I added a function that allows me to specify a target coordinate (x,y). Then I added find_target to my timer loop and call it every 30ms. The function looks at the distance and angle and commands the motors to those speeds. By using he distance left to set the speed I get nice fast and crisp movements. Before I added/fixed the code that your set the speeds proportionally, the robot was all over the map oscillating like crazy. Have a look at tonight's results.
The robot starts at 0,0. I then commanded it to go to 5,5 (that in inches BTW) and then to go to -10, 3. The pink and yellow lines are there for reference. The blue line is the plot of the X and Y coordinates reported by the robot. I have the printout function send data every 40ms (a bit too fast really) so the point markers are really close.
To dos:
1. Add the ability to create a point array from the drive pattern routine. Then have the robot traverse the array.
2. Figure out how to call the print routine every X ms. Because it uses an interrupt, it'll have to be outside the timer routine that I use for the PID and find_target.
3. Find a suitable and ready to go RTOS to port my code to. I'd rather quit fooling with ms timers and just run all the processes concurrently and have a central function call each when it's their turn.
Onward,
Jay
