Prev: How to get envelope from AM signal without phase shift
Next: GMSK: how to normalize I, Q sample
From: Alfred Bovin on 10 Mar 2010 10:01
Hi.

So far I think we're talking about the same stuff.

>> The next problem is now to transform this motion given in the Earth frame
>> to the frame I use for the navigation (that is: the frame attached to the
>> position where the vehicle starts at time t = 0 as described in my
>> initial post).
>
> I'm not sure what you mean -- you want to establish a frame of reference
> around the vehicle's starting point? Why?

Because that's what I do with the odometry and the visual sensor.
I have some initial pose of the vehicle, then I drive around a bit and then
offline try to reconstruct the path taken by the vehicle with respect to
this arbitrarily positioned and oriented starting frame (what I called the
navigation frame).

I guess what I'm really trying to understand here now is how I shall
interpret this Earth centered rotating coordinate system.
I think that what I'm confused about is this whole initial alignment stuff
that all the books write a lot about.

As I have understood it, the purpose of an alignment is to determine the
initial pose of the vehicle with respect to e.g. the true north. What I then
tried discuss was the fact that I don't need this, since
a) I will not synchronize with GPSs
b) I do not care about the exact location of the vehicle, only the locations
relative to the starting point.

If I've understood the Earth coordinate thing correctly, then at my starting
point with a properly aligned system I would for example read off a position
of approx. 12000 meter in the heigh direction (the radius of Earth).
Similarly, I would get an orientation saying that I'm in Denmark. I do not
care about that, so I'll just say that at time t = 0 my Earth coordinate
system is aligned with the body of the vehicle with a zero position offset
and an indentity orientation matrix.

I hope I'm making sense and thanks for your time.





From: Alfred Bovin on 10 Mar 2010 10:06
"Rich Webb" <bbew.ar(a)mapson.nozirev.ten> wrote in message
news:vbbdp5ds298df2unqdeaoc632t0k851i4i(a)4ax.com...
>>Translating both to earth-centered, earth-fixed, then back, will make
>>your head hurt -- each way -- but both of those together may well make
>>your head hurt less than _just_ trying to write a system equation that
>>stays in WGS-84 coordinates. Particularly if you want your system to
>>work close to the poles.
>
> Yes, I've drifted away from the navigation equations in the last few
> years (no pun intended (okay, that was a lie)) and do miss the mental
> gymnastics but not so much the pain.
>
> It sounds as if the OP doesn't want a GPS reference. If the problem is
> local area navigation (e.g., something like Sparkfun's annual Autonomous
> Vehicle Competition) then his best bet might be simply to stick with a
> flat earth model and use odometry to estimate his sensor corrections.

That's correct and I was not very clear about this. I'm not interested in
GPS referencing.
As I said, I have this all-terrain vechicle and I at the moment use odometry
and visual information for estimating the path driven.

The odometry readings, however, only give information about the motion in a
plane, and I'm interested in estimating the full 3D poses for example when
driving in rugged terrains or when the vehicle is parked on a tilted
surface.

The visual system does give full 3D information, but it rather slow and may
fall out when visual features are sparse or illumanation conditions are bad.
Therefore, I thought it would make sense to investigate whether an IMU can
give better information in these cases. But you all seem to tells me, that
this specific IMU is too noisy.



From: Alfred Bovin on 10 Mar 2010 10:10
> The IMU can _help_. In particular, the IMU plus a GPS receiver will
> vastly increase the short-term accuracy of the GPS measurement. It won't
> be good enough to resolve problems with multipath on the GPS, nor will it
> carry you through a very long GPS dropout.
>
> Odometry and visual data may help, but it's problematic -- how do you tell
> the difference between a wheel slip and the sudden onset of GPS multipath?
> In theory you could make a filter that would sort this out (web search on
> "particle filter"); in practice you could spend a long time dinking with
> such a filter without getting something that is robust and practical.

Well the whole idea of using visual info was to be able to tell the
difference between actual motions and wheel slips and also so I can get a
full 3D motion reconstruction and not just the planar info from the
odometry. The full 3D pose is important when "doing stuff" in rugged
terrains.

As I wrote in another reply, the visual system is rather slow and may fail
sometimes so my thoughts came to using an IMU. What I don't know yet if
whether this particular IMU is too noisy to make a combined improment on the
visual and odometry data.


From: Rich Webb on 10 Mar 2010 10:36
On Wed, 10 Mar 2010 16:06:11 +0100, "Alfred Bovin"
<alfred(a)bovin.invalid> wrote:

>"Rich Webb" <bbew.ar(a)mapson.nozirev.ten> wrote in message
>news:vbbdp5ds298df2unqdeaoc632t0k851i4i(a)4ax.com...
>>>Translating both to earth-centered, earth-fixed, then back, will make
>>>your head hurt -- each way -- but both of those together may well make
>>>your head hurt less than _just_ trying to write a system equation that
>>>stays in WGS-84 coordinates. Particularly if you want your system to
>>>work close to the poles.
>>
>> Yes, I've drifted away from the navigation equations in the last few
>> years (no pun intended (okay, that was a lie)) and do miss the mental
>> gymnastics but not so much the pain.
>>
>> It sounds as if the OP doesn't want a GPS reference. If the problem is
>> local area navigation (e.g., something like Sparkfun's annual Autonomous
>> Vehicle Competition) then his best bet might be simply to stick with a
>> flat earth model and use odometry to estimate his sensor corrections.
>
>That's correct and I was not very clear about this. I'm not interested in
>GPS referencing.
>As I said, I have this all-terrain vechicle and I at the moment use odometry
>and visual information for estimating the path driven.
>
>The odometry readings, however, only give information about the motion in a
>plane, and I'm interested in estimating the full 3D poses for example when
>driving in rugged terrains or when the vehicle is parked on a tilted
>surface.
>
>The visual system does give full 3D information, but it rather slow and may
>fall out when visual features are sparse or illumanation conditions are bad.
>Therefore, I thought it would make sense to investigate whether an IMU can
>give better information in these cases. But you all seem to tells me, that
>this specific IMU is too noisy.

It's not that you need GPS as such but you will need a sensor
independent from the INS package to be able to estimate, e.g., sensor
bias drift. The 3D visual system should work fine for that, to enable
you do run an occasional update cycle where you compare estimated to
observed position/orientation and make the necessary adjustments to your
operating parameters.

Ohio State University is working on a similar process, specifically with
LIDAR but the principles could be abstracted to other sensors. We're
currently working with them to apply their techniques to a 3D sonar, for
example.

Try a 'net search on "ohio state lidar navigation" for some
representative papers.

--
Rich Webb Norfolk, VA
From: Tim Wescott on 10 Mar 2010 11:24
Alfred Bovin wrote:
> Hi.
>
> So far I think we're talking about the same stuff.
>
>>> The next problem is now to transform this motion given in the Earth frame
>>> to the frame I use for the navigation (that is: the frame attached to the
>>> position where the vehicle starts at time t = 0 as described in my
>>> initial post).
>> I'm not sure what you mean -- you want to establish a frame of reference
>> around the vehicle's starting point? Why?
>
> Because that's what I do with the odometry and the visual sensor.
> I have some initial pose of the vehicle, then I drive around a bit and then
> offline try to reconstruct the path taken by the vehicle with respect to
> this arbitrarily positioned and oriented starting frame (what I called the
> navigation frame).
>
> I guess what I'm really trying to understand here now is how I shall
> interpret this Earth centered rotating coordinate system.
> I think that what I'm confused about is this whole initial alignment stuff
> that all the books write a lot about.
>
> As I have understood it, the purpose of an alignment is to determine the
> initial pose of the vehicle with respect to e.g. the true north. What I then
> tried discuss was the fact that I don't need this, since
> a) I will not synchronize with GPSs
> b) I do not care about the exact location of the vehicle, only the locations
> relative to the starting point.
>
> If I've understood the Earth coordinate thing correctly, then at my starting
> point with a properly aligned system I would for example read off a position
> of approx. 12000 meter in the heigh direction (the radius of Earth).
> Similarly, I would get an orientation saying that I'm in Denmark. I do not
> care about that, so I'll just say that at time t = 0 my Earth coordinate
> system is aligned with the body of the vehicle with a zero position offset
> and an indentity orientation matrix.
>
> I hope I'm making sense and thanks for your time.

I now understand why we've been talking at cross purposes.

If the inertial sensors were good enough to do a reasonable job all by
themselves you'd need to take the earth frame into account to get the
earth's rotation vector and local acceleration due to gravity correct.

If they're not good enough (they aren't), then you absolutely positively
must merge their data with some suitably good absolute position
measurement. This is why folks have been suggesting it repeatedly. You
don't want to use GPS -- fine. But you must use something other than
just your inertial measurements -- what's it going to be?

If there were some absolute reference that you could use, and that
absolute reference worked in your preferred coordinate frame, then your
preferred coordinate frame will work just fine. What are you going to use?

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: How to get envelope from AM signal without phase shift
Next: GMSK: how to normalize I, Q sample