|
Cellular forums Home > Archive > GPS > June 2006 > GPS Attitude Determination
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
GPS Attitude Determination
|
|
| daMike 2006-05-23, 5:48 pm |
| Hello, I'm a student who is working on his master thesis concering
attitude determination (automotive area)! Hopefully some of you can
help me out with some unclear points! I could figure out a thin red
line towards car attitude:
1. get date from both receivers (carrier phase, # of SV, etc.)
2. calculate single difference phase
3. calculate line-of-sight vector
4. make a first "Line-Bias" guess to obtain a rough baseline solution
5. take pitch and yaw from step 4 and put it into a min-function to get
the
integer ambiguities
6. take pitch and yaw from step 5 and calculate Line-Bias and integer
ambiguities again
7. calculate the baseline vector with known basline distance and
results from step 6
8. align baseline vector (body frame) to ECEF / ENU (local level frame)
Below you will find some question ..
1. How can I calculate the LOS vector? Can I simply use
the inaccurate position data for LOS vector calculation (via Kepler
law)?
2. For resolving the integer ambiguities it's necessary
to create a first guess of the baseline vector (floating
solution). Can I make a rough guess with the Doppler
values of both receivers to limit the search space?
3. To get the dICP the fractional part and the integrated
cycles since initialization are necessary. Does the counter
start to count the whole numbers, when the satellite is locked/
at first view or have to be some synchronization (maybe with
the CA code) between the two receivers to make sure they count
with the same offset?
Hope we can get started a mutumutal discussion on this subject!
Best Regards,
Michael
| |
| Pascal.Boulerie@gmail.com 2006-05-23, 5:48 pm |
| In January 2004, someone was talking about using _also_ gyroscope and
accelerator data (as well as odometer, especially in dense urban area
where GPS cover and signal reception quality is bad).
http://georezo.net/forum/viewtopic....41&hl=gyroscope
| |
|
| On 23 May 2006, daMike wrote in
news:1148375831.037586.281810@j33g2000cwa.googlegroups.com
> Hello, I'm a student who is working on his master thesis
> concering attitude determination (automotive area)! Hopefully
> some of you can help me out with some unclear points! I could
> figure out a thin red line towards car attitude:
>
> 1. get date from both receivers (carrier phase, # of SV, etc.)
> 2. calculate single difference phase
> 3. calculate line-of-sight vector
> 4. make a first "Line-Bias" guess to obtain a rough baseline
> solution 5. take pitch and yaw from step 4 and put it into a
> min-function to get the
> integer ambiguities
> 6. take pitch and yaw from step 5 and calculate Line-Bias and
> integer ambiguities again
> 7. calculate the baseline vector with known basline distance and
> results from step 6
> 8. align baseline vector (body frame) to ECEF / ENU (local level
> frame)
>
> Below you will find some question ..
>
> 1. How can I calculate the LOS vector? Can I simply use
> the inaccurate position data for LOS vector calculation (via
> Kepler
> law)?
>
> 2. For resolving the integer ambiguities it's necessary
> to create a first guess of the baseline vector (floating
> solution). Can I make a rough guess with the Doppler
> values of both receivers to limit the search space?
>
> 3. To get the dICP the fractional part and the integrated
> cycles since initialization are necessary. Does the counter
> start to count the whole numbers, when the satellite is locked/
> at first view or have to be some synchronization (maybe with
> the CA code) between the two receivers to make sure they count
> with the same offset?
>
> Hope we can get started a mutumutal discussion on this subject!
>
> Best Regards,
> Michael
>
>
Not sure what a mutumutal discussion is, but the voice on my nuvi
seems to have an attitude. When I turn off the route she
calculated for me, she seems annoyed when she says “recalculating.”
--
Lew
| |
| Sam Wormley 2006-05-23, 5:48 pm |
| daMike wrote:
> Hello, I'm a student who is working on his master thesis concering
> attitude determination (automotive area)! Hopefully some of you can
> help me out with some unclear points! I could figure out a thin red
> line towards car attitude:
>
> 1. get date from both receivers (carrier phase, # of SV, etc.)
> 2. calculate single difference phase
> 3. calculate line-of-sight vector
> 4. make a first "Line-Bias" guess to obtain a rough baseline solution
> 5. take pitch and yaw from step 4 and put it into a min-function to get
> the
> integer ambiguities
> 6. take pitch and yaw from step 5 and calculate Line-Bias and integer
> ambiguities again
> 7. calculate the baseline vector with known basline distance and
> results from step 6
> 8. align baseline vector (body frame) to ECEF / ENU (local level frame)
>
> Below you will find some question ..
>
> 1. How can I calculate the LOS vector? Can I simply use
> the inaccurate position data for LOS vector calculation (via Kepler
> law)?
>
> 2. For resolving the integer ambiguities it's necessary
> to create a first guess of the baseline vector (floating
> solution). Can I make a rough guess with the Doppler
> values of both receivers to limit the search space?
>
> 3. To get the dICP the fractional part and the integrated
> cycles since initialization are necessary. Does the counter
> start to count the whole numbers, when the satellite is locked/
> at first view or have to be some synchronization (maybe with
> the CA code) between the two receivers to make sure they count
> with the same offset?
>
> Hope we can get started a mutumutal discussion on this subject!
>
> Best Regards,
> Michael
>
May be of interest:
http://trimble.resultspage.com/sear...w=Tans%20vector
http://trimble.resultspage.com/sear... />
&method=and
| |
| Dennis Pogson 2006-05-23, 5:48 pm |
| Lew wrote:
> On 23 May 2006, daMike wrote in
> news:1148375831.037586.281810@j33g2000cwa.googlegroups.com
>
>
> Not sure what a mutumutal discussion is, but the voice on my nuvi
> seems to have an attitude. When I turn off the route she
> calculated for me, she seems annoyed when she says "recalculating."
Does she get even more annoyed when you choose to ignore her amended route?
| |
|
|
"Lew" <notme@notmindspring.invalid.com> wrote in message
news:Xns97CC7D51810D
0notmenotmindspringc
o@216.168.3.64...
> On 23 May 2006, daMike wrote in
> news:1148375831.037586.281810@j33g2000cwa.googlegroups.com
>
>
> Not sure what a mutumutal discussion is, but the voice on my nuvi
> seems to have an attitude. When I turn off the route she
> calculated for me, she seems annoyed when she says "recalculating."
> --
> Lew
There is a TV show called "the O.C." where the father "Sandy" was feeling
that his life was just too boring and dull in Orange County California
living in his million dollar house overlooking the ocean and attending all
the society parties so when the GPS voice in his $75,000 Mercedes SUV told
him to turn right he rebelled and went straight instead. That 'ill teach 'em
he is still a force to be reckoned with!!!
| |
|
|
>
> "Lew" <notme@notmindspring.invalid.com> wrote in message
> news:Xns97CC7D51810D
0notmenotmindspringc
o@216.168.3.64...
>
There is a TV show called "the O.C." where the father "Sandy" was feeling
that his life was just too boring and dull in Orange County California
living in his million dollar house overlooking the ocean and attending all
the society parties so when the GPS voice in his $75,000 Mercedes SUV told
him to turn right he rebelled and went straight instead. That 'ill teach
'em
he is still a force to be reckoned with!!!
| |
| daMike 2006-05-24, 5:48 pm |
| Thanks for your interest! I'm currently working with an approach Mr.
Santiago Alban
did at Stanford University. At the moment I belief I can calulate the
SV position out of the ephemeris data. Does anybody know a source where
I can check the correctness of my calculated SV position?
Pascal: sorry, but I speak no french
Lew:mutual, of course
| |
| Pascal.Boulerie@gmail.com 2006-05-24, 5:48 pm |
| IGN-France has also started some research about using a high-resolution
ortho-photo mapping coverage database, in order to re-calibrate the
position of a GPS-guided vehicle in dense urban areas: an image
processor would check for "beacons" in the landscape (painted signs on
the road tarmac are especially useful).
| |
| darthpup 2006-05-24, 5:48 pm |
| US military uses DTM stored and referenced real time along with GPS to
correct position real time. Index of refraction of atmosphere and
effect on propagation path precludes other methods.
| |
|
| You can validate your calculations by comparing them with the precise
ephemerides. You'll end up writing two pieces of code to calculate
satellite position - one using the orbital equations and the other
interpolating between xyz positions.
| |
| Chris Malcolm 2006-05-26, 5:48 am |
| In sci.geo.satellite-nav daMike <stoeckl_m@web.de> wrote:
> Hello, I'm a student who is working on his master thesis concering
> attitude determination (automotive area)! Hopefully some of you can
> help me out with some unclear points! I could figure out a thin red
> line towards car attitude:
> 1. get date from both receivers (carrier phase, # of SV, etc.)
> 2. calculate single difference phase
> 3. calculate line-of-sight vector
> 4. make a first "Line-Bias" guess to obtain a rough baseline solution
> 5. take pitch and yaw from step 4 and put it into a min-function to get
> the
> integer ambiguities
> 6. take pitch and yaw from step 5 and calculate Line-Bias and integer
> ambiguities again
> 7. calculate the baseline vector with known basline distance and
> results from step 6
> 8. align baseline vector (body frame) to ECEF / ENU (local level frame)
You seem to be ignoring history and dynamics. You will get much better
results in you smooth your noisy data over recent history. Cars also
have non-holonomic steering and limited capabilities of acceleration
and deceleration. You can use that to further filter the data. Unless
you need to switch on and determine the attitude of a stationary
vehicle, you will be able to determine attitude by considering how the
car got there, i.e. recent track, so needing only one receiver.
--
Chris Malcolm cam@infirmatics.ed.ac.uk +44 (0)131 651 3445 DoD #205
IPAB, Informatics, JCMB, King's Buildings, Edinburgh, EH9 3JZ, UK
[http://www.dai.ed.ac.uk/homes/cam/]
| |
| daMike 2006-05-26, 5:48 pm |
| I used the follow data for SV position calculation:
Ephemeris:
sv 9
tow 458760
flags 20
iodc 229
toc 460800
ura 0
healthS 0
wn 352
tgd -5.58794e-009
af2 0.000000
af1 1.59162e-012
af0 2.17631e-005
toe 460800
iode 229
rootA 5153.6291389465
ecc 0.017933544120751
m0 0.14599609328434
omega0 -0.87556416261941
inc0 0.30586629547179
argPer 0.39342841180041
deln 1.41222e-009
omegaDot-2.57899e-009
incDot 1.73713e-010
crc 175.875
crs -6.75000
cuc -4.39584e-007
cus 1.08033e-005
cic -3.16650e-007
cis 2.60770e-008
cs 113
Time:
EpochTimeMS.tod 31882000
How can I find out, if the SV Positon
x 2.39316e+007
y 1.07674e+007
z -2.88134e+006
Trel -0.786849
I calculated is correct? I used for that calculation the following
code:
http://www.colorado.edu/geography/g...gps/ephxyz.html
Thanks!
daMike
| |
| Preben Mikael Bohn 2006-05-28, 5:48 pm |
| daMike wrote:
> I used the follow data for SV position calculation:
& #91;snip]
>
> How can I find out, if the SV Positon
>
> x 2.39316e+007
> y 1.07674e+007
> z -2.88134e+006
> Trel -0.786849
>
> I calculated is correct?
Go to IGS http://igscb.jpl.nasa.gov/ and download the corresponding SP3
file and compare.
Best regards Preben
| |
| Pascal.Boulerie@gmail.com 2006-05-29, 5:48 am |
| > Chris Malcolm :
> In: sci.engr.surveying,sci.geo.satellite-nav,sci.geo.cartography,alt.satellite.gps
>
> Cars also have non-holonomic steering
For the layman ignorant of kinematics or robotics (as here on
sci.geo.cartography), can you explain shortly what a non-holonomic
system is?
Follow-up to: sci.geo.cartography
| |
| Chris Malcolm 2006-05-29, 5:48 am |
| In sci.geo.satellite-nav Pascal.Boulerie@gmail.com wrote:
[color=darkred]
> For the layman ignorant of kinematics or robotics (as here on
> sci.geo.cartography), can you explain shortly what a non-holonomic
> system is?
It means you can't turn independent of moving some distance, i.e.,
there is such a thing as a parking problem. A consequence of that is
that you can tell where the car is pointing by looking at its track,
for which you only need one receiver. Of course you also have to know
whether it was going forwards or reversing, but that's all, and in all
but very extreme cases you can find that out by looking at the track
history too.
--
Chris Malcolm cam@infirmatics.ed.ac.uk +44 (0)131 651 3445 DoD #205
IPAB, Informatics, JCMB, King's Buildings, Edinburgh, EH9 3JZ, UK
[http://www.dai.ed.ac.uk/homes/cam/]
| |
| AndrewGT 2006-05-30, 5:48 pm |
|
daMike wrote:
> Thanks for your interest! I'm currently working with an approach Mr.
> Santiago Alban
> did at Stanford University. At the moment I belief I can calulate the
> SV position out of the ephemeris data. Does anybody know a source where
> I can check the correctness of my calculated SV position?
>
> Pascal: sorry, but I speak no french
>
> Lew:mutual, of course
Look at RTCM SC-104 document, RTCM Recommended Standards for DGNSS
services, version 2.3 Appendix C is a test case for SV position
| |
| Jim Lux 2006-05-30, 5:48 pm |
| daMike wrote:
> Hello, I'm a student who is working on his master thesis concering
> attitude determination (automotive area)! Hopefully some of you can
> help me out with some unclear points! I could figure out a thin red
> line towards car attitude:
>
Some folks at Stanford University have done this for aircraft (and other
vehicles) using several GPS receivers with antennas some 50cm apart and
using carrier phase. (google for GPS short-baseline attitude")
The technique has been used for artillery baseplate positioning, as well.
> Best Regards,
> Michael
>
| |
| J. Severyn 2006-05-30, 11:48 pm |
|
"Jim Lux" <james.p.lux@jpl.nasa.gov> wrote in message
news:e5htu6$7hp$1@nn
tp1.jpl.nasa.gov...[color=darkred]
>
> Some folks at Stanford University have done this for aircraft (and other
> vehicles) using several GPS receivers with antennas some 50cm apart and
> using carrier phase. (google for GPS short-baseline attitude")
>
> The technique has been used for artillery baseplate positioning, as well.
>
>
Yes, Sam Wormley referenced the Trimble TansVector on 23May06 earlier in
this thread. The TansVector used an array of GPS antennae on the vehicle
(usually an aircraft, but could be any movable platform) to determine
position and attitude in real-time. By the way, this is/was a product of
Trimble more than 10 years ago.
John Severyn @KLVK
| |
| daMike 2006-05-31, 5:48 pm |
|
AndrewGT schrieb:
> daMike wrote:
> Look at RTCM SC-104 document, RTCM Recommended Standards for DGNSS
> services, version 2.3 Appendix C is a test case for SV position
Is there a free version available as well?
| |
| daMike 2006-05-31, 5:48 pm |
| Does track history not slow down the whole process? I can't imagine
that an update rate with around 100Hz can be reallized by using
receiver histroy?!?
Chris Malcolm schrieb:
> In sci.geo.satellite-nav Pascal.Boulerie@gmail.com wrote:
>
>
> It means you can't turn independent of moving some distance, i.e.,
> there is such a thing as a parking problem. A consequence of that is
> that you can tell where the car is pointing by looking at its track,
> for which you only need one receiver. Of course you also have to know
> whether it was going forwards or reversing, but that's all, and in all
> but very extreme cases you can find that out by looking at the track
> history too.
>
> --
> Chris Malcolm cam@infirmatics.ed.ac.uk +44 (0)131 651 3445 DoD #205
> IPAB, Informatics, JCMB, King's Buildings, Edinburgh, EH9 3JZ, UK
> [http://www.dai.ed.ac.uk/homes/cam/]
| |
| Chris Malcolm 2006-06-04, 2:48 am |
| In sci.geo.satellite-nav daMike <stoeckl_m@web.de> wrote:
> Chris Malcolm schrieb:
[color=darkred]
> Does track history not slow down the whole process? I can't imagine
> that an update rate with around 100Hz can be reallized by using
> receiver histroy?!?
Firstly, since a car can't change attitude or speed much in 10msec, I
can't see the point of such a high update rate. People manage to drive
cars with effective control reactions times orders of magnitude slower
than that.
Secondly, since the amount of processing required in using track
history in this way is insignificant compared to processing the raw
satellite data, I can't see why it would affect update rate at all. If
the rest of the system was up to processing the satellite data at such
speeds I can't see why you couldn't use history and upate at 1,000Hz.
--
Chris Malcolm cam@infirmatics.ed.ac.uk +44 (0)131 651 3445 DoD #205
IPAB, Informatics, JCMB, King's Buildings, Edinburgh, EH9 3JZ, UK
[http://www.dai.ed.ac.uk/homes/cam/]
| |
| Happy Trails 2006-06-04, 5:48 pm |
| On 4 Jun 2006 05:39:06 GMT, Chris Malcolm <cam@holyrood.ed.ac.uk>
wrote:
>Firstly, since a car can't change attitude or speed much in 10msec, I
>can't see the point of such a high update rate. People manage to drive
>cars with effective control reactions times orders of magnitude slower
>than that.
>
>Secondly, since the amount of processing required in using track
>history in this way is insignificant compared to processing the raw
>satellite data, I can't see why it would affect update rate at all. If
>the rest of the system was up to processing the satellite data at such
>speeds I can't see why you couldn't use history and upate at 1,000Hz.
Who else has noticed what you just posted - an update rate of once per
16.67 minutes?
| |
|
| Please explain what you mean Happy Trails...
"Happy Trails" <undisclosed@obscure.com> wrote in message
news:chp582dn50h86ff
491q3f3ro9b90j2fapd@
4ax.com...
> On 4 Jun 2006 05:39:06 GMT, Chris Malcolm <cam@holyrood.ed.ac.uk>
> wrote:
>
>
> Who else has noticed what you just posted - an update rate of once per
> 16.67 minutes?
>
>
>
| |
| kashe@sonic.net 2006-06-05, 5:48 pm |
| On Mon, 5 Jun 2006 14:45:23 +1000, "TJ" <tj@tj.com> wrote:
>Please explain what you mean Happy Trails...
It means that he doesn't understand the distinction that Hz is
a rate (SI unit of frequency, equivalent to one cycle per second),
rather than a simple, cumulative count of transitions.
>"Happy Trails" <undisclosed@obscure.com> wrote in message
> news:chp582dn50h86ff
491q3f3ro9b90j2fapd@
4ax.com...
>
| |
|
| I was hoping he would do it...but the point still got across...
<kashe@sonic.net> wrote in message
news:0fu7825gk7ti4hb
bcr0hqs6ilklgjhprbq@
4ax.com...
> On Mon, 5 Jun 2006 14:45:23 +1000, "TJ" <tj@tj.com> wrote:
>
>
> It means that he doesn't understand the distinction that Hz is
> a rate (SI unit of frequency, equivalent to one cycle per second),
> rather than a simple, cumulative count of transitions.
>
>
>
>
>
>
| |
| daMike 2006-06-13, 5:48 pm |
| If you imaging the update rate of the INS sensors in the car (roughly 1
kHz) you will understand that a high update rate for GPS as well is
desirable to calibrate the sensors! Well you are right that roll won't
change much during driving but the yaw does! Hence for driving dynamics
it's essential to know the yaw as precise as possible!
Chris Malcolm schrieb:
> In sci.geo.satellite-nav daMike <stoeckl_m@web.de> wrote:
>
>
>
>
> Firstly, since a car can't change attitude or speed much in 10msec, I
> can't see the point of such a high update rate. People manage to drive
> cars with effective control reactions times orders of magnitude slower
> than that.
>
> Secondly, since the amount of processing required in using track
> history in this way is insignificant compared to processing the raw
> satellite data, I can't see why it would affect update rate at all. If
> the rest of the system was up to processing the satellite data at such
> speeds I can't see why you couldn't use history and upate at 1,000Hz.
>
> --
> Chris Malcolm cam@infirmatics.ed.ac.uk +44 (0)131 651 3445 DoD #205
> IPAB, Informatics, JCMB, King's Buildings, Edinburgh, EH9 3JZ, UK
> [http://www.dai.ed.ac.uk/homes/cam/]
| |
| Bart Bailey 2006-06-13, 5:48 pm |
| In Message-ID:<1150209816.739006.42890@g10g2000cwb.googlegroups.com>
posted on 13 Jun 2006 07:43:36 -0700, daMike wrote:
>If you imaging the update rate of the INS sensors in the car (roughly 1
>kHz) you will understand that a high update rate for GPS as well is
>desirable to calibrate the sensors! Well you are right that roll won't
>change much during driving but the yaw does! Hence for driving dynamics
>it's essential to know the yaw as precise as possible!
If you spend more time looking at the screen than the road,
you might have to include pitch as a factor. ;-)
--
Bart
|
|
|
|
|