Previous versions of the DRVR code would predict a course, move, stop and repeat. The time taken to start and stop the robot for each move was substantial.
This update runs the robot at 25% speed continually and updates the course every second. This has improved the traversal time from 15-20 minutes to less than 7 minutes. The video above is a 10x time lapse of one loop.
The choice of 25% speed for 1 second, was to keep the move time approximately the same (We were running 50% speed for .5 seconds) and to give the computation time to run (.2 sec) I also improved the performance of a few routines by using numpy functions version python loops. The computation time was taking around 1 second, before I made those easy changes.
One of my frequent pieces of advice holds true: Make it work first, then optimize. Using python loops was easy and let me understand the algorithm before I replaced it with numpy routines. It didn't matter until I started pushing real-time processing.
In the video you can see some oversteer by the robot where it zigzags a bit towards the grass and then towards the middle of the path where it should be going mostly straight. That's because the prediction algorithm isn't matching as closely as it should, which causes the turn calculation to over correct. The prediction algorithm relies on some hard coded numbers rather than being calculated based on the speed, direction, and time. I think that'll be the next refinement and allow me to dynamically change the speed. To do that I'm going to need to collect some measurement data and add some math.
The path planning is also very simplistic. While it goes around the bench nicely in this video, it sometimes cuts it too close and catches a wheel on the bench. It's a bit hit or miss. I need to increase forward margin, so it starts turning sooner in a future update.
On other notes, I've started playing with ROS (Robot Operating System). It appears to include a lot of useful functionality. I'm still investigating, but once these changes are working I may move to that framework.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.