| |||||||||
IntegrationThe software modules for locomotion, servo movement and IR pinger were put together to see how they co-existed. They did not like each other's company too well initially! Careful inspection showed that the servo movement API was overwriting the PORTB locomotion bits. A couple of late nights sorting this out and it was ready to go. Initial TestsThe steering algorithm was very basic - go forward, and then look-and-avoid if necessary. The robot will turn towards a gap when comparing straight-ahead versus left and right. If there is no obvious gap, it will reverse and turn around. It works remarkably well and gets itself around most obstacles put before it. I have found the IR pinger to be very directional so it does not cover the corners of the robot. If something is straight-ahead, to the left or right, it will detect it. If it is offset by 4cm ahead, it may not. Also, a low obstacle below the line-of-sight will not be detected. However, generally it does a pretty good job and does not get stuck in corners although chair legs can be problematic. I feel quite vindicated that I have achieved the goal I set out to do, building a small robotic platform that autonomously navigates its way around a room and the basic platform is extensible and has a lot more to be expored as yet! Navigation ImprovementsTo improve the obstacle avoidance, a touch bumper switch could be added.This is a good catch-all mechanism, especially as the IR sensor goes 'blind' if too close to an object. Adding another servo to allow the main IR Pinger to have a second degree of freedom also gives much more flexibility. However, before going down that road, it should be possible to use the existing sensors to improve performance. Fixing the offset obstacle (where the front corners can hit an undetected barrier) could be fixed by moving the servo to scan the corners as well as straight, left and right. It will use more battery power to constantly be scanning while moving forward but this would hopefully detect obstacles before they become too close to detect. The servo movements while going forward will be small as it only needs to scan ahead, then over each front corner. If it detects anything 'ahead', it will then fall back to the existing avoidance mechanism. This change is just compenating for the tunnel vision of the IR sensor. Scanning the low-level barriers could use the step-detector IR scanner although I suspect that that will be quite directional too. ResultsScanning the sensor while moving has improved obstacle detection considerably. Another small change was rather than spin-left or spin right to avoid an obstacle, it reverses about 1cm before making the spin. This avoids situations where a wheel gets stuck (eg on a low-level obstacle) and the robot tries to turn around it. So now the robot seems to be able to navigate itself out of most situations other than a low-level bar that sits below the sensor height. Another issue I have noticed is how battery life effects performance. When the batteries are fully charged, the robot does run faster. It also detects obstacles at a greater distance although due to the greater speed, it sometimes does not react in time. As the batteries run down, things are more predictabe. I put this down to doing all the optimizations when the batteries were not fully charged. I beleieve if I revist those optimization and rework them for full batteries, it will work ok with simi-discharged batteries, all be it somewhat more slowly. And here is how it performs..
Some Thoughts on Range FindingHere are some thoughts on range finding that I will stick in the long-term todo list.
| |||||||||
| |||||||||