Passive wheel for odom!

[Scott Monaghan]

I just wanted to give a shout out of thanks to whoever suggested using passive wheels for odometry for a tracked bot on our ROS2 discussion call last night!

As i mentioned on the call, I want to add tracks to robud (github.com/scottmonaghan/robud). On the call I got the helpful advice that due to slippage the odom from the track wheels will be nearly useless. I currently have an optical mouse sled that works pretty well on my hardwood floor but put it on a shiny flat surface and it is useless too.

Someone then mentioned the idea of using one or more passive wheels to collect odom and it is one of those simply perfect ideas I have been kicking myself for not considering it.

Right now my thought is to add a non-marking inline skate wheel on a bearing with slight suspension  and an encoder to replace the mouse. This will be more reliable, lower cost, and decrease the power load on my strained Jetson nano. 

Thanks again! This group is great!

- Scott

--

Scott Monaghan

413.244.9344

scott.m...@gmail.com

www.linkedin.com/in/scott-monaghan

Resume: https://tinyurl.com/yxhq5eul

[Pito Salas]

Hi Scott,

Interesting... I am in the final stages of getting a tracked robot based on Linorobot up and running. And of course I have encoders on the powered track wheel. So this is bad news for me. 

Can you (or anyone) say more why there's more slippage with tracked wheel vs. a conventional differential drive with two powered wheels? Is that in general or more specifically based on the terrain on which the tracked vehicle would be going?

Thanks!

Pito Salas
Faculty, Computer Science
Brandeis University

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAMzUCWNNZiDMFG-bpzH%3DnbGVp_9Ah4BOKKmAJrLbNQgTRMdKRg%40mail.gmail.com.

[Chris Albertson]

This is a great idea.   I was thinking of how to handle this too.  But I wonder if a passive wheel would roll without some kind of spring pressure?

Mathematically can you do odometry with just one wheel?     How can it know a turn from a straight line?   You would also need an IMU.

 I have a 6-wheel 'bot" and only 2 wheels have encoders.   There is a lot of slippage and the odometry is not good. 

One other idea...   A friend asked for help with his new robot vacuum cleaner.   I forget the brand but I noticed a really smart idea the company did.   There is a camera that points straight up.  Just a basic web cam.    They get optical flow odometry from the ceiling.   The assumption must be that if there is a floor that needs to be vacuumed, there must be a ceiling.   I might try an experiment, place my iPhone on the floor and pull it with a string while recording video then see if I can get software to tell me how far I pulled the string.  If that works the idea will be used on my "dog-bog".

--

You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAMzUCWNNZiDMFG-bpzH%3DnbGVp_9Ah4BOKKmAJrLbNQgTRMdKRg%40mail.gmail.com.

--

Chris Albertson
Redondo Beach, California

[Scott Monaghan]

As I understand it there are 2 major issues:

1. When turning, the contact points on the ground surface are such that you are essentially skid turning. This gets the job done for rotating your bot but the wheels turn more than the actual bot rotation. This is compounded by the fact that they will behave differently on different surfaces. Now, I actually anticipated this issue so for heading adjustments I always planned ignoring the wheel encoders and using my imu (with magnetometer) I use the Adafruit breakout of the BNO055 and its a delight. I also use this for heading correction when driving straight, rather than trying to adjust based on wheel encoder speed and it works like a dream (at least for me)

2. The other issue I hadn’t anticipated is that I was told that tracks are just prone to slipping, especially when they experience changes in surface friction (moving from carpet to floor, moving from level to incline-ramp). The reason there is intuitive after being explained: if the contact friction is uneven across one of your tracks, you’re going to get some unpredictable loads on whatever is driving your tracks.

Anyway, thats the best that I understand it.

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/01D58556-906F-422D-A7DB-20B57310623D%40gmail.com.

[Chris Albertson]

Theoretically, a two-wheel differential drive can have perfect odometry.  The wheels contact at tiny geometric points and never slip.   So if you know the wheel rotations and the robot geometry, in theory it is perfect.   Of course in the real world it does not work as well but with wheels we can have some hope.

But tank treads, even in theory can't be perfect.  A tank-turn requires slipping and the pivot point on the stalled track is unpredictable by science.    So you simply have to guess and you can not always guess right.

The way out is to use multiple sources of odometry such that the errors from each source are not coupled.  With independent errors you can combine IMU data with imperfect tank trank odometry and maybe add optical flow to the mix and get "good enough".   Some robots go as far as using two IMUs just to create more data sources to reduce error.   Place one in each end of the robot.  The imu measures the pivot point so there is no need to guess.  the two working together are better then either one.  For example tank-trak odometry is VERY accurate when the tank is stationary but IMU is not accurate when stationary, it drifts.   The combination is better than either.      Someone far smarter than me back in the 1960s invented a way to fuse this data and today you can just google "Kalman Filter" and see the solution.

The concept is simple.  The filter estimates the robot position and then looks at what each sensor measured and then looks at how good the sensors were and trusts them or not based of their performance.   Which are bast changes over time. if doing turns or stopped of whatever.   It does this perhaps 20 times persecond.  The math is hard but you use library code to do it.  ou don't have to write it.

Point is that even in theory tank track data is not good in turns but is very good at other times.   but gyros are good in turns

I'm seriously thinking of placing April tags on the ceiling. Then if by chance the robot walks under a tag it gets a dead-on perfect fix and resets its location and orientation.

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/01D58556-906F-422D-A7DB-20B57310623D%40gmail.com.

[Scott Monaghan]

Mathematically can you do odometry with just one wheel?     How can it know a turn from a straight line?   You would also need an IMU.

In RoBud's case I get absolute heading from the IMU (BNO055). I'm not using ROS so I've got more low-level access of how to do everything. So if the robot is moving straight forward or backward I'd record from the passive wheel odom. When it is turning I ignore the wheel and update the heading based on the IMU.

If you wanted to do traditional odom from like a 2 wheeled robot, you could add 2 passive wheels around the axis of rotation.

Scott Monaghan

413.244.9344

scott.m...@gmail.com

www.linkedin.com/in/scott-monaghan

Resume: https://tinyurl.com/yxhq5eul

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHse0yTwUDtqTQ7mwE3Frvwt%2BOgL9U7kOR4mx7QXPctSZg%40mail.gmail.com.

[Alan Federman]

wheel odometry isn't very accurate no matter what you do, because slight errors accumulate over time. Navigation in autonomous systems requires SLAM and obstacle avoidance. In a differential drive robot it is easier to drive 1 meter back and forth several times end end up within A few cm, the it is to navigate a 1m square and end up within 5 cm and 5 degrees of your original heading. 

  This is because of Motors being different, needing to control them via PID, friction and momentum. In the case of geared brushed motors, there is coil bias, so running the motor back and forth the same amount of time won't return the wheel to the same place. BTW, how well are those wheels aligned?

Dusty robotics, uses a laser surveyor system to accurately position their robots. I don't imagine they rely on wheel based odometry very much at all

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAMzUCWNEL-MooYqtqBp2GzivT3saPFKcQ_vepxSxvy%3D9xyTYLg%40mail.gmail.com.

[Dave Everett]

Yep, wheel odometery is pretty bad. You can improve it with proper calibration.

See Borenstien: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjyz4rUrYz1AhUDSGwGHfwmArAQFnoECAoQAQ&url=http%3A%2F%2Fwww-personal.umich.edu%2F~johannb%2FPapers%2Fpaper58.pdf&usg=AOvVaw15ZoJlOetCNqegAfMlYl7K

This calibration is based on a square and returns very good results. I would usually calibrate on a 4m square and get much better results than 5deg and 5cm. The calibration attempts to correct for all the things we usually don't pick up, like absolute wheel diameter etc.

It's also improved by keeping the wheels narrow and ensuring they have adequate grip. However, avoid a few obstacles on your way to a destination and you'll find your robot starting to lose position. A few years back I started experimenting with path planning, I ended up reducing it to a small function, with trajectory planning reduced to 2 lines of code and all navigation handled by wheel odometry only. This was the 1st phase as I intended to pick up landmarks later on. It was fairly good in an environment with hard surfaces. There's some video here:

https://www.youtube.com/watch?v=dgdUqZOr13w

It's only a short journey, but it's a small workshop :)

I would run that robot back and forth between the 2 destinations maybe 10 times before the error was too large to work. I was also planning on a realignment routine back at home base to help correct these errors. However an IMU and landmarking would have helped enormously.

Quadrature encoding helps also, as motors do not stop and start immediately, quadrature will allow you to know not only that the wheel is turning, but in what direction so you can keep track of the apparent position better.

Dave

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/2092458520.409076.1640867199108%40connect.xfinity.com.

[Chris Albertson]

The big problem with wheel odometry is what happens when you drive off the hardwood floor.   It works poorly on carpet and grass or anything but a smooth surface.

One idea I want to try on the next robot chassis is an optical flow sensor.  Like one of these.  https://docs.px4.io/master/en/sensor/optical_flow.html

They are popular with robot drones because obviously wheel-odometry can't work for a flying robot.  The cost is about $20.

My "dog-bot" will have leg odometry and I'm very curious to see how this will work.   One theory is that it has four legs and all of them can't slip at once. and I can detect a slipping leg because it is moving relative to the ground at a speed different from the other legs.  the other theory is that they all slip so badly that trying to get it to work is hopeless.   I shall see.     But an optical flow sensor mounted on the belly and pointed down should work and for another $20 I can aim second one at the ceiling.   

I do have a drone like the one in the above link, but I've been afraid to let it fly autonomously.   A few times I tried but I have to keep a hand on the kill switch if it takes off for "parts unknown"  they can fly up to 60 miles per hour and be lost very quickly.   But when I hit the switch the drone falls like a stone and even from 25 feet takes beating when it hits the ground.     So testing is hard because I need to drive out to the desert where there are miles of open land. 

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAG61pbdLVzPWNdHG5uaoPpv%2Bpi%3DCfjHMpcz9K1wmbSa%2BGjRs4Q%40mail.gmail.com.

[Michael Wimble]

The problem with odometry is the problem of all closed loop systems. Attempting odometry with an open loop system is likely to be useless after a small driving distance. A closed loop system can work well, but only against what the loop entails. If your closed loop is based upon wheel encoders, then all you know is how the wheels spun. Which has only a casual relationship with how the robot moved on a surface.

You can use visual odometry with cameras, as I do with my T265 camera and it can work fairly well. You can even do optical odometry with just a LIDAR, which works, for example, in one of the hector-SLAM packages. Just choose a loop system which is measuring what you want, such as where you are in a room, not how the wheels spun.

[Steve " 'dillo" Okay]

On Friday, December 31, 2021 at 10:43:05 AM UTC-8 alberts...@gmail.com wrote:

The big problem with wheel odometry is what happens when you drive off the hardwood floor.   It works poorly on carpet and grass or anything but a smooth surface.

One idea I want to try on the next robot chassis is an optical flow sensor.  Like one of these.  https://docs.px4.io/master/en/sensor/optical_flow.html

They are popular with robot drones because obviously wheel-odometry can't work for a flying robot.  The cost is about $20.

Do you really need a distance sensor if your robot is on the ground ? It seems like the reason you need the depth sensing on a drone is for measuring altitude.

Optical flow is certainly something I'd like to implement on Tenacity and I'm starting to appreciate why a lot of robots have a 6-8 cameras on them. 

I don't have the encoders on the motors hooked up to an MCU. I know other SAWPPY-builders have but the wiring is a big pain and I really don't want to completely rewire my robot for the 10th time, esp. when it seems like the main thing I would get out of it is not going to be very accurate.

'dillo

[Pito Salas]

I think something that's been missing for me in this thread is "why do you want odometry"? In my experience (like has been said) odometry is quite inaccurate by itself. But it does give some information. And combined with the IMU it is even better. But how are you going to use this odometry data?

Is it for navigation? Getting to a certain destination given a known starting point? Without more information (a map and coordinate system) the best you could do is to drive in a straight line from where you (think you) are to where you want to be, without regards to anything else.

If not for navigation, how else are you planning to use it? I think we need to settle on that before worrying too much about how accurate it is or isn't. I don't think we can think of odometry as a way to localize the robot over longer distances.

In our case we are using odometry in combination with the IMU and the Lidar to create a map and then use it for navigtation (classic SLAM). But we are experimenting with RTK GPS which is supposed to give us centimeter precision (but only within range of the GPS signal, i.e. outdoors.) In that case there's a real question whether we will need odometry at all. 

Pito

Pito Salas
Faculty, Computer Science
Brandeis University

On Dec 31, 2021, at 2:53 PM, Michael Wimble <mwi...@gmail.com> wrote:

The problem with odometry is the problem of all closed loop systems. Attempting odometry with an open loop system is likely to be useless after a small driving distance. A closed loop system can work well, but only against what the loop entails. If your closed loop is based upon wheel encoders, then all you know is how the wheels spun. Which has only a casual relationship with how the robot moved on a surface.

You can use visual odometry with cameras, as I do with my T265 camera and it can work fairly well. You can even do optical odometry with just a LIDAR, which works, for example, in one of the hector-SLAM packages. Just choose a loop system which is measuring what you want, such as where you are in a room, not how the wheels spun.

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/DC1C6110-84AC-4F8F-AC4B-CB0B9549B1D5%40gmail.com.

[Chris Albertson]

You need the distance sensors so that the software knows the lens the ground distance.  If the robot has wheels and is rolling on flat ground then the lens to ground distance would be constant, so I don't see a need for the sensor.

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/56559c74-457a-4ce8-8ea9-071699914795n%40googlegroups.com.

[Marco Walther]

There are two reasons for the encoders;-) One is the PID controller for
the different motor speeds. And then you can use them (or some
'combination of them') as an input for odometry. Yes, that will give you
very limited accuracy, but it gives you some idea;-)

-- Marco

> 'dillo

>
> --
> You received this message because you are subscribed to the Google
> Groups "HomeBrew Robotics Club" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to hbrobotics+...@googlegroups.com

> <mailto:hbrobotics+...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/hbrobotics/56559c74-457a-4ce8-8ea9-071699914795n%40googlegroups.com
> <https://groups.google.com/d/msgid/hbrobotics/56559c74-457a-4ce8-8ea9-071699914795n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Marco Walther]

On 1/1/22 12:40 PM, Pito Salas wrote:
> I think something that's been missing for me in this thread is "why do
> you want odometry"? In my experience (like has been said) odometry is
> quite inaccurate by itself. But it does give some information. And
> combined with the IMU it is even better. But how are you going to use
> this odometry data?
>
> Is it for navigation? Getting to a certain destination given a known
> starting point? Without more information (a map and coordinate system)
> the best you could do is to drive in a straight line from where you
> (think you) are to where you want to be, without regards to anything else.
>
> If not for navigation, how else are you planning to use it? I think we
> need to settle on that before worrying too much about how accurate it is
> or isn't. I don't think we can think of odometry as a way to localize
> the robot over longer distances.
>
> In our case we are using odometry in combination with the IMU and the
> Lidar to create a map and then use it for navigtation (classic SLAM).
> But we are experimenting with RTK GPS which is supposed to give us
> centimeter precision (but only within range of the GPS signal, i.e.
> outdoors.) In that case there's a real question whether we will need
> odometry at all.

Even GNSS RTK is not working well everywhere:-( In the shadow of tall
buildings or under tree cover, ... it's not good. There, you want to
have other sensors.
An IMU works ok on flat ground. But when the route gets bumpy, it will
record a lot of 'noise', which you you have to compensate with other
sensors.
The UBlox ZED-F9R is a combination of GNSS RTK + IMU (
https://www.sparkfun.com/products/16344 ) But even that would expect a
relatively smooth ride of a full size car, not the 1:10th, we normally
think in.

-- Marco

>
> Pito
>
>
> Pito Salas
> Faculty, Computer Science
> Brandeis University
>
>> On Dec 31, 2021, at 2:53 PM, Michael Wimble <mwi...@gmail.com

>> <mailto:mwi...@gmail.com>> wrote:
>>
>> The problem with odometry is the problem of all closed loop systems.
>> Attempting odometry with an open loop system is likely to be useless
>> after a small driving distance. A closed loop system can work well,
>> but only against what the loop entails. If your closed loop is based
>> upon wheel encoders, then all you know is how the wheels spun. Which
>> has only a casual relationship with how the robot moved on a surface.
>>
>> You can use visual odometry with cameras, as I do with my T265 camera
>> and it can work fairly well. You can even do optical odometry with
>> just a LIDAR, which works, for example, in one of the hector-SLAM
>> packages. Just choose a loop system which is measuring what you want,
>> such as where you are in a room, not how the wheels spun.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "HomeBrew Robotics Club" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to hbrobotics+...@googlegroups.com

>> <mailto:hbrobotics+...@googlegroups.com>.

>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/hbrobotics/DC1C6110-84AC-4F8F-AC4B-CB0B9549B1D5%40gmail.com

>> <https://groups.google.com/d/msgid/hbrobotics/DC1C6110-84AC-4F8F-AC4B-CB0B9549B1D5%40gmail.com>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "HomeBrew Robotics Club" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to hbrobotics+...@googlegroups.com

> <mailto:hbrobotics+...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/hbrobotics/A085AAF4-C6FD-4F10-8FB7-83A238A18928%40gmail.com
> <https://groups.google.com/d/msgid/hbrobotics/A085AAF4-C6FD-4F10-8FB7-83A238A18928%40gmail.com?utm_medium=email&utm_source=footer>.

[Pito Salas]

Marco

Even GNSS RTK is not working well everywhere:-( In the shadow of tall buildings or under tree cover, ... it's not good. There, you want to have other sensors.
An IMU works ok on flat ground. But when the route gets bumpy, it will record a lot of 'noise', which you you have to compensate with other sensors.
The UBlox ZED-F9R is a combination of GNSS RTK + IMU ( https://www.sparkfun.com/products/16344 ) But even that would expect a relatively smooth ride of a full size car, not the 1:10th, we normally think in.

Interesting... We haven't tested it in those conditions. I just came across that sparkfun product. It's new right? We sort of built our own  which cost less but was a major hassle :)

Are you experienced with GTK? We're learning as we go!

Pito

[Marco Walther]

On 1/1/22 2:26 PM, Pito Salas wrote:
> Marco
>
>> Even GNSS RTK is not working well everywhere:-( In the shadow of tall
>> buildings or under tree cover, ... it's not good. There, you want to
>> have other sensors.
>> An IMU works ok on flat ground. But when the route gets bumpy, it will
>> record a lot of 'noise', which you you have to compensate with other
>> sensors.
>> The UBlox ZED-F9R is a combination of GNSS RTK + IMU (
>> https://www.sparkfun.com/products/16344
>> <https://www.sparkfun.com/products/16344> ) But even that would expect
>> a relatively smooth ride of a full size car, not the 1:10th, we
>> normally think in.
>
> Interesting... We haven't tested it in those conditions. I just came
> across that sparkfun product. It's new right? We sort of built our own
>  which cost less but was a major hassle :)

I'm playing with it since 2017 or so, I started with Ublox M8N/M8T's and
doing the RTK in software (rtklib). Now, I have a couple of Ublox F9P's
as base and rovers. I got my first pair of F9P's from the
https://www.ardusimple.com/ Kickstarter campaign;-) I like their boards
because they have the [very often needed] direct link solved pretty well.

My fixed base station (currently mostly for my ardumower;-) is available
here: http://rtk2go.com:2101/SNIP::MOUNTPT?NAME=US_CA_Tracy_MW1_RTCM ;-)

And yes, I tried next to buildings and under trees at different times;-)

-- Marco

>
>
> Are you experienced with GTK? We're learning as we go!
> Pito
>
>
>>
>>> Pito
>>> Pito Salas
>>> Faculty, Computer Science
>>> Brandeis University
>>>> On Dec 31, 2021, at 2:53 PM, Michael Wimble <mwi...@gmail.com

>>>> <mailto:mwi...@gmail.com> <mailto:mwi...@gmail.com

>>>> <mailto:mwi...@gmail.com>>> wrote:
>>>>
>>>> The problem with odometry is the problem of all closed loop systems.
>>>> Attempting odometry with an open loop system is likely to be useless
>>>> after a small driving distance. A closed loop system can work well,
>>>> but only against what the loop entails. If your closed loop is based
>>>> upon wheel encoders, then all you know is how the wheels spun. Which
>>>> has only a casual relationship with how the robot moved on a surface.
>>>>
>>>> You can use visual odometry with cameras, as I do with my T265
>>>> camera and it can work fairly well. You can even do optical odometry
>>>> with just a LIDAR, which works, for example, in one of the
>>>> hector-SLAM packages. Just choose a loop system which is measuring
>>>> what you want, such as where you are in a room, not how the wheels spun.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "HomeBrew Robotics Club" group.
>>>> To unsubscribe from this group and stop receiving emails from it,
>>>> send an email to hbrobotics+...@googlegroups.com
>>>> <mailto:hbrobotics+...@googlegroups.com>

>>>> <mailto:hbrobotics+...@googlegroups.com

>>>> <mailto:hbrobotics+...@googlegroups.com>>.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/hbrobotics/DC1C6110-84AC-4F8F-AC4B-CB0B9549B1D5%40gmail.com
>>>> <https://groups.google.com/d/msgid/hbrobotics/DC1C6110-84AC-4F8F-AC4B-CB0B9549B1D5%40gmail.com>
>>>> <https://groups.google.com/d/msgid/hbrobotics/DC1C6110-84AC-4F8F-AC4B-CB0B9549B1D5%40gmail.com
>>>> <https://groups.google.com/d/msgid/hbrobotics/DC1C6110-84AC-4F8F-AC4B-CB0B9549B1D5%40gmail.com>>.
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "HomeBrew Robotics Club" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to hbrobotics+...@googlegroups.com
>>> <mailto:hbrobotics+...@googlegroups.com>

>>> <mailto:hbrobotics+...@googlegroups.com

>>> <mailto:hbrobotics+...@googlegroups.com>>.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/hbrobotics/A085AAF4-C6FD-4F10-8FB7-83A238A18928%40gmail.com
>>> <https://groups.google.com/d/msgid/hbrobotics/A085AAF4-C6FD-4F10-8FB7-83A238A18928%40gmail.com>

>>> <https://groups.google.com/d/msgid/hbrobotics/A085AAF4-C6FD-4F10-8FB7-83A238A18928%40gmail.com?utm_medium=email&utm_source=footer
>>> <https://groups.google.com/d/msgid/hbrobotics/A085AAF4-C6FD-4F10-8FB7-83A238A18928%40gmail.com?utm_medium=email&utm_source=footer>>.
>>
>

[Pito Salas]

Great! Question: for the base (caster) would it work if it was just under a plywood "ceiling" -- does it have to have truly unhindered view of the sky?

Pito Salas
Faculty, Computer Science
Brandeis University

[camp .]

> "why do you want odometry"?

 

Perhaps this is too obvious but I think the basic answer is in the next paragraph, "to drive in a straight line."

 

- Camp

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/A085AAF4-C6FD-4F10-8FB7-83A238A18928%40gmail.com.

[Marco Walther]

On 1/1/22 2:53 PM, Pito Salas wrote:
> Great! Question: for the base (caster) would it work if it was just
> under a plywood "ceiling" -- does it have to have truly unhindered view
> of the sky?

I have not tried that. But I would assume, that your roof is not just
plywood (otherwise, it would potentially have a very high water content).

Overall, I would try to put at least the base antenna really outside.
You want to 'see' satellites from maybe 10-15 degs above the horizon and
those signals would have to travel quiet some way through you plywood/roof.

I'll attach a picture of my fixed base antenna setup.

Have fun;-)
-- Marco

>
> Pito Salas
> Faculty, Computer Science
> Brandeis University
>
>> On Jan 1, 2022, at 5:50 PM, Marco Walther <marc...@gmail.com

>> <mailto:marc...@gmail.com>> wrote:
>>
>> On 1/1/22 2:26 PM, Pito Salas wrote:
>>> Marco
>>>> Even GNSS RTK is not working well everywhere:-( In the shadow of
>>>> tall buildings or under tree cover, ... it's not good. There, you
>>>> want to have other sensors.
>>>> An IMU works ok on flat ground. But when the route gets bumpy, it
>>>> will record a lot of 'noise', which you you have to compensate with
>>>> other sensors.
>>>> The UBlox ZED-F9R is a combination of GNSS RTK + IMU (
>>>> https://www.sparkfun.com/products/16344
>>>> <https://www.sparkfun.com/products/16344>
>>>> <https://www.sparkfun.com/products/16344
>>>> <https://www.sparkfun.com/products/16344>> ) But even that would
>>>> expect a relatively smooth ride of a full size car, not the 1:10th,
>>>> we normally think in.
>>> Interesting... We haven't tested it in those conditions. I just came
>>> across that sparkfun product. It's new right? We sort of built our
>>> own   which cost less but was a major hassle :)
>>
>> I'm playing with it since 2017 or so, I started with Ublox M8N/M8T's
>> and doing the RTK in software (rtklib). Now, I have a couple of Ublox
>> F9P's as base and rovers. I got my first pair of F9P's from the

>> https://www.ardusimple.com/ <https://www.ardusimple.com/> Kickstarter

>> campaign;-) I like their boards because they have the [very often
>> needed] direct link solved pretty well.
>>
>> My fixed base station (currently mostly for my ardumower;-) is
>> available here:
>> http://rtk2go.com:2101/SNIP::MOUNTPT?NAME=US_CA_Tracy_MW1_RTCM
>> <http://rtk2go.com:2101/SNIP::MOUNTPT?NAME=US_CA_Tracy_MW1_RTCM> ;-)
>>
>> And yes, I tried next to buildings and under trees at different times;-)
>>
>> -- Marco
>>
>>> Are you experienced with GTK? We're learning as we go!
>>> Pito
>>>>
>>>>> Pito
>>>>> Pito Salas
>>>>> Faculty, Computer Science
>>>>> Brandeis University
>>>>>> On Dec 31, 2021, at 2:53 PM, Michael Wimble <mwi...@gmail.com
>>>>>> <mailto:mwi...@gmail.com> <mailto:mwi...@gmail.com

>>>>>> <mailto:mwi...@gmail.com>> <mailto:mwi...@gmail.com

[Pito Salas]

Yes, the plywood is covered by asphalt shingles. And I suspected that it wouldn't work but I was going to try it just to make sure. Yes, do send the picture!

Pito Salas
Faculty, Computer Science
Brandeis University

[Chris Albertson]

I think we use wheel encoders because they are "free".  We need them so the motors run at the commanded speed even under different loads and battery conditions and once you have an encoder installed the odometry s free.  At least free in the sense that it does not require any more hardware.

This is why I'm planning on using "leg-odometry" on the dog-bot.  Not because I think it will work well but because I have to move the legs anyways and it is not much effort to add up all the steps.

To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/e79ad27e-4eb6-3d82-4db4-a674f9598e25%40gmail.com.