Subject:
|
Re: Another way to avoid Float
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Fri, 26 Jan 2001 19:38:48 GMT
|
Viewed:
|
1464 times
|
| |
|
|
> In term of rotation precision, the two middle wheel have 160 mm between • them.
> So when the robot rotate 360°, each wheel run on a circle of 160 mm • diameter.
> this gives 160*PI / 40*PI wheel turns = 160/40= 4 turns = 4*48ticks = 192
> ticks for a 360° turns.
> So after a 360° rotation, one wheel will have +192 ticks and the opposite • wheel
> will have -192 ticks.
> the diff will be 192 + 192 = 384 ticks.
> the precison of sensor is 360°/384 = 0.93 ° / tick
This is all well and good, but the all consuming problem with location
tracking is slippage. What happens if one wheel slips? What about if it hits
an obstacle at an angle? If you find some way around these problems, It'd be
really good to hear it.
Incidentally in the Java firmware which is currently in beta (LeJOS) the
full floating point Math library is available, with all the sine, cosine,
tangent etc functions you would ever need.
|
|
Message has 1 Reply:
 | | Re: Another way to avoid Float
|
| Thank you for your answer Andy. (...) In fact I built my robot (let's call him R2D1 ) for navigation, pathfinding and auto mapping purpose. I restrict his evolution to the (flat) floor of my house. I don't know yet if I'll be able to reach all of my (...) (24 years ago, 27-Jan-01, to lugnet.robotics.rcx)
|
Message is in Reply To:
| | Another way to avoid Float
|
| For the navigation of my robot, I do not plan to use float or trig function. I will use long integer (32bits). the high 16 bit are the true integer value. the low 16 bits are 1/65535 value. let say 1 = 0x00010000 2 = 0x00020000 2.5 = 0x00028000 2.25 (...) (24 years ago, 19-Jan-01, to lugnet.robotics.rcx)
|
3 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
