Notifications
Clear all
2021-10-02 12:23 am
Excellent, thank you (I can learn without having to display my ignorance 🙂
Anything seems possible when you don't know what you're talking about.
2021-10-02 1:10 am
@thrandell @robotbuilder
OK, now I learn that it's just an approximation (no wonder it didn't make sense !)
I still think that the formula for the new x and y should be using the updated theta (i.e. newTheta) since they're now being updated based on being angled in the new direction.
PS - I agree with robotbuilder, it seems much easier if you have a target location and orientation in mind to rotate to face target, move to target and rotate to desired orientation.
Anything seems possible when you don't know what you're talking about.
Topic starter
2021-10-02 3:08 am
I applaud your curiosity to learn something new. You’re right about the robots initial pose being arbitrary. A pose is identified by the x and y coordinates and the angle from the x axis that the vehicle is facing. Hence, (x,y,th). My source for these calculations is a paper written by Edwin Olson titled “A Primer on Odometry and Motor Control”. A pictures worth a thousand words.
http://web.mit.edu/6.186/2005/doc/odomtutorial/odomtutorial.pdf
I agree with your comment that encoders are mainly useful for motor control feedback. That was my intention. Prior to this robot I was using timers and those are pretty crude in comparison.
Tom
To err is human.
To really foul up, use a computer.
2021-10-02 3:20 am
Perfect, thanks for the URL. I'll see if I can find out why theta can't start at zero 🙂
It probably seems weird, but I always like deriving the formula for all of my own projects. I've made all kinds of stuff from V plotters to simulated pendulum-based harmonographs to solving a brachiograph.
I have the delusion that it keeps my brain lubricated.
Anything seems possible when you don't know what you're talking about.
2021-10-02 5:30 pm
My source for these calculations is a paper written by Edwin Olson titled “A Primer on Odometry and Motor Control”. A pictures worth a thousand words.
http://web.mit.edu/6.186/2005/doc/odomtutorial/odomtutorial.pdf
Thanks for your help Tom, I read the paper and I now understand how the formulae were generated and have a much better understanding of the approximation used (and its limitations).
But I still think that the original theta can start at zero 🙂
Anything seems possible when you don't know what you're talking about.
2021-10-03 4:50 am
@thrandell
Your efforts inspired me to look some more into odometry navigation. Just how well can a robot determine its current position and orientation from the encoder data and an initial x,y position and orientation. Looking at the image below I thought about what might be required computationally.
When one motor is going at a different (but constant velocity) to the other motor the robot will navigate a circle. As one wheel becomes slower the robot will produce a tighter and tighter circle. When one wheel stop altogether the base will rotate around that wheels position which will be at the center of the circle P. If the left wheel (in the example) begins to rotate in the opposite direction the center of the circle will shift into the axel. If at the center of the axel the robot will just rotate and not move anywhere.
To test the computations I wrote a little simulation which when I get time I will use its computational algorithms to see if it will work on the Arduino based robot base.
To enlarge an image, right mouse click image and choose,
Open link in new window
@will
Yes you can start at 0 theta as I did in the sim example below. The robot sim actually headed off at a slightly different angle to zero because when I tried to hit the two keys as the same time to start up the two "motors" I must have hit one slightly before the other.
The source I used to figure out the code was at,
http://www.seattlerobotics.org/encoder/200010/dead_reckoning_article.html
2021-10-03 3:56 pm
I prefer the "point and run and repoint" approach to odometetry mostly because I have a dislike for approximations in series. The errors introduced by wheel slippage would be bad enough without voluntarily including more by using approximations.
There are always some cases where approximations are allowed, or even mandatory, such as approximating a solution to a second order equation for pendulum motion.
Could the cumulative errors be corrected (or at least minimized) by putting a couple of pylons a known distance apart ? The robot could periodically check the relative angles to each and deduce its current location. There would be multiple solutions of course, but the internal estimate of location should be enough to disambiguate the true location. I'm not a roboteer, so it's probably a frivolous question.
Anything seems possible when you don't know what you're talking about.
Topic starter
2021-10-03 6:02 pm
Your idea of using pylons sounds intriguing.
To complete this project I’m concentrating on autonomous behavior. Next on my to do list is writing a search behavior for a robot that has no internal representation of the search space. I need good random coverage before the batteries run down. LOL.
I also noticed in the academic papers on robots that they talk about wheel velocities being determined from a rotational velocity and a translation (forward) velocity (w,v). So I was thinking that it might be fun to try to add that to my program. Maybe forward velocity in meters per second and rotational velocity in radians per second. I don’t know yet… Gotta make use of all that odometry data I’m getting from the encoders.
Tom
To err is human.
To really foul up, use a computer.
2021-10-03 6:18 pm
Your idea of using pylons sounds intriguing.
I've never gotten close to building a robot (maybe in a few years, too much else to play with now). If it was a good idea, somebody would have capitalized on it years ago 🙂
Anything seems possible when you don't know what you're talking about.
2021-10-03 8:35 pm
Your idea of using pylons sounds intriguing.
For me I like the idea of making use of natural features rather than having to structure the environment with beacons. Natural features of course means vision or at the least some kind of recognition of a natural feature. There was one little robot that used odometry navigation which made use of contact with walls to reset its position to counter drift. It used spiked plastic wheels to avoid slippage something like the image below. Unfortunately the internet site no longer exists. It was used by a games programmer and he gave the robot "emotions" to determine how it might behave at different times. You could make such wheels if you have a 3d printer.
I've never gotten close to building a robot (maybe in a few years, too much else to play with now).
That different people are interested in one thing and not another is a good thing so our need to do something fun or profitable spreads over a wide range of activities. For those interested in electronics there are lots of projects to satisfy that interest.
Topic starter
2021-10-03 10:25 pm
My very first robot I called a Photovore because all it could do was drive around in the sunlight coming in through a window. My inspiration for the build was the Society of Robots web site. You’ve probably seen that one before. Anyway, your comment about a robot with ‘emotions’ made me think of one of the robots on that site. The author tired to use fuzzy logic to add 'emotions' like tired, bored, afraid,.. but alas his PIC base MCU didn’t have the memory to run his program.
Check it out at: https://www.societyofrobots.com/robot_omni_wheel.shtml
Tom
To err is human.
To really foul up, use a computer.
2021-10-03 11:50 pm
My very first robot I called a Photovore because all it could do was drive around in the sunlight coming in through a window.
Well that is really neat. Philosophizing about how to build a robot is a different ball game to actually building one that actually does something.
The Cybert robot I mentioned was simple and successful. How it responded depended on its emotional state at the time. Emotions are a fascinating subject which is an important part of understanding how the human brain works (another subject of long time interest).
Omniwheels may be functional on a flat surface but how would they work on a rough surface where the bumps are larger than the little free running wheels that make up the wheels tyre?
Topic starter
2021-10-06 6:55 pm
To err is human.
To really foul up, use a computer.
2021-10-06 7:16 pm
Thank you very much !
One of my long-range projects was going to be making a 3D solar tracker, so this will be very useful indeed 🙂
In what units do you measure "wheel speed" ?
Please, what are the #defines for CONTROL, PUNT and what is behaviour() ?
Anything seems possible when you don't know what you're talking about.
Topic starter
2021-10-06 10:19 pm
To err is human.
To really foul up, use a computer.