Beginners: please read this post and this post before posting to the forum.
0 Members and 1 Guest are viewing this topic.
A little more tricky is a bit of an understatement, there are a whole lot of angle and trig problems to solve, so unless you borrow someone elses code, it will be quite a task.
FYI - its sharp IR, not sonar, that is spinning on the servo
QuoteFYI - its sharp IR, not sonar, that is spinning on the servoI don't know what you are refrencing.
Fixing it to the robot requires lots of trig, though. You need to find the radius of the wheel and do some stuff with funtacious radians, then compare it to the chassis of ther robot, and if your robot isn't a perfect square, you get to deal with ellipses! What fun!
i meant that the robot can stop, spin in a circle and map, choose a new heading, then move again. spinning while moving makes it much much harder i agree . . .
Ive built 30+ something robots in the last 5 years, but only named like 15 of them (6 of those had the same name), and only documented about 10 of them . . .http://www.societyofrobots.com/robots.shtmlStampyhttp://www.societyofrobots.com/robot_sumo.shtmlFuzzyhttp://www.societyofrobots.com/robot_omni_wheel.shtml
actually, you can mathematically account for the robot moving while you scan . . . it requires knowing robot velocity and comparing that to the sensor update rate.as for precision, ideally you want the lowest precision possible without causing your robot to fail, not highest. higher precision slows your robot down, and makes algorithms take much longer to process (floating point, for example).in the manufacturing world, every decimal point of precision your robot has is an extra decimal point in price If you can manufacture something with less precision, it could save loads of money . . .