SparkFun Forums

[noelgra]

Thanks to Evil Genius, I have waypoint recognition sorted.
Now I have a GPS guided test vehicle (RC car) that is steering to a waypoint, but it wanders around far too much.
Is there any way I can smooth out the steering signal. I thought about a system that reads the steering value (d) and puts that into an array each time around the steering loop. This should allow an average of d to be produced, which would then be provided to the steering routine.
Has anyone any idea if this is the best way to smooth out the steering?
Any ideas or code is much appreciated.
Thanks.
Here is the code that produces the steering signal:

[do
{if (nss.available() > 0 ) {
// read incoming character from GPS
char c = nss.read();

// check if the character completes a valid GPS sentence
if (gps.decode(c)) {
// check if GPS positioning was active
if (gps.gprmc_status() == 'A') {

{d = gps.gprmc_course_to(hlat,hlon) - gps.gprmc_course();} // steer for home



if (d < 0) { d += 360; }
if (d > 180) { d -= 360; }

if (d>=2){
steerservo.write(88);} // steer 2 degrees


if (d>=5){
steerservo.write(85);} // steer 5 degrees


if (d>=10){
steerservo.write(80);} // steer 10 degrees

if (d>=15){
steerservo.write(75);} // steer 15 degrees

if (d>=20){
steerservo.write(70);} // steer 20 degrees


Serial.println("steer to home loop ");

if (d<-2) {
steerservo.write(92);} // steer -2 degrees

if (d<-5) {
steerservo.write(95);} // steer -5 degrees

if (d<-10) {
steerservo.write(100);} // steer -10 degrees

if (d<-15) {
steerservo.write(105);} // steer -15 degrees

if (d<-20) {
steerservo.write(110);} // steer -20 degrees

if (gps.gprmc_distance_to(hlat, hlon,MTR) < wptRange) // See If thge distance from current point is less than then the defined Radius
{digitalWrite(13,LOW);}

}}}}
while (z==2);}}]

[fll-freak]

Even at a fixed location, the GPS calculated position will likley vary by significant values. What does your steering do when the car is not allowed to move? My guess is the steering wheels may jitter side to side. The issue will then be one of tying to remove self location jitter.

[noelgra]

Thanks for the interest Skye.
Yes the steering does move about when the car is not moving.
But how to remove self location jitter?
Can you suggest a method or direct me to some code.
Thanks.

[waltr]

I'm thinking of adding an IMU to take care of the small variations.

[noelgra]

Hello Waltr
What is an IMU?

[waltr]

Inertial Measurement Unit. This can be done using any number of the Accelerometer/Gyro/Magnetometer boards sold by SparkFun and others.

Search SparkFun's store and forums for 9DOF and IMU. There has been much detailed discussions on using them for navigation.

[noelgra]

Is there a way to do the smoothing without adding hardware?
How about this:
in the line: {d = gps.gprmc_course_to(hlat,hlon) - gps.gprmc_course();}
If d is updated each time around the loop and stored each time so that a moving average of the last (say) 10 values of d is created.
Once we have the average we could compare the latest value of d to the average and say something like this:

if d> (daverage *1.1);
dsteer=daverage; // don't accept the latest d value, but just steer to the average
else dsteer = d;

Where dsteer is the value that determines the servo position. Would this smooth out the steering?
My eventual application is for a small water vessel so is no requirement to make sharp turns.?
With this smoothing system, when the turn waypoint is reached the average value would pump up to to approximately the full value of d for the turn.

[Evil Genius jr.]

That would help but it wont fix it completely. You might want to try a high and low pass filters. That's were you throw out steering values that are within say 5 of the previous one and also throw out one that are outside of say 15 of the previous one. I am not exactly sure how to do that in arduino code so you might want to look it up. Good luck with your project.

[fll-freak]

Self location jitter is due to many variables including atmospheric disturbances, timing accuracy, and if Selective Availability was turned on (it currently is not) the induced error signal. The biggest issue for you is likely multipath, Multipath is the effect of a signal bouncing off objects and arriving at the GPS having traveled different distances. It is nearly impossible to remove multipath in an urban environment. Try your car out in the middle of the Pacific ocean! It will likely work better.

Filters of various types and orders might help a bit with the problem. The trouble is that the fluctuation in self location is likely to be on the same order as that of your car motion. You would then not be able to tell if the change in self location was due to real motion or an error.

The only solution that I am aware of (short of having a properly crypto keyed military grade SAASM GPS) is to include accelerometer/gyro sensors. Using them as an IMU/INU you can determine what part of the motion is real. The rest must be jitter and you can filter that out.

[noelgra]

Skye
Thanks for your input.
I now have a model car steering to the waypoint, but it traces a zig zag (erratic) path.
I have tried averaging the steering signal (d) but that makes it worse. It seems that the car travels too far before it gets a correction.

Using the EM406 GPS I get one update per second. If I had a 10Hz GPS would this make the steering respond faster and therefore make for a more direct path to the waypoint?

Has anyone tried a 1HZ & a 10Hz GPS in this type of application? Which 10 Hz GPS would be best?
Thanks.

[fll-freak]

A 10Hz GPS will help but will not solve the intrinsic problem.

The dither of the position will likely only be a tenth as bad if report. But since you are now adjusting your steering ten times more often, you will still be "chasing snakes".

The root problem is that you steering is a high frequency task being controlled by a low frequency update that has significant jitter/dither.

If your car was not moving and you simply wanted to adjust the wheels towards your target, then you could time average the GPS position. (lat = lat(n) + lat(n-1) + lat(n-2) +...+lat(n-q))/q) or perhaps lat = lat * p + newLat * (1-p) where p is from 1 to 0. These (and other) techniques would smooth out the jitter and give you a better self location fix from which to make your calculations.

The problem is that your car will be moving. You can simply average out your self location values. If you do, you will always have the wrong self location.

So what is one to do?

Some years ago I worked with a $200,000 soup canned sized inertial navigation unit that combined the best of two worlds. The GPS for good long time period accurate self locations and a ring laser gyro for good micro second by micro second location information. The unit than fuzed the data together to give you gnats-*** locations and orientation. Now unless you have a spare 1/4 million, you can't buy one. But you could make a similar approach.

Based on your current speed (wheel encoders) and direction (compass or gyro) you can figure out how far you have traveled since your last GPS fix. You can then calculate a new lat/long and compare that to your new GPS fix. These you CAN average with a weight towards one or the other to get a better idea of where you are. This will subtract out some of the GPS jitter and will likely allow you to steer better.

[noelgra]

OK. I had better look into the IMU solution but I have no idea how it works, what code it needs and how to integrate it into the code I have now.
Any ideas please?

It does not matter about the steering jumping around before the car starts moving, as the drive motor will only start when the software is ready (GPS signals coming in).

[fll-freak]

It does not matter about the steering jumping around before the car starts moving, as the drive motor will only start when the software is ready (GPS signals coming in).

It nor not matter, but it is a symptom of the problem. If GPS was giving you exact coordinates, you would not see the jumping, or if the distance to the destination was several miles away, you would not see any hunting. In fact, this is a good test to prove that the issue is GPS jitter. Pick a target lat/lon someplace across town and holding up the car, see if it hunts.

Someone at the last AVR had a bot that used dead reckoning to go around the building. I saw a bult log/glob that had some details. I would hunt down that info as a good starting point. You also do not need a full 6DOF INU/IMU since you are constrained (I hope!) to the road surface plane. And since you don't care about pitch and roll, it make the problem even simpler.

[janmartin]

Skye,

you have very interesting experience with dead reckoning and GPS!

I am doing streetview rigs: http://www.diy-streetview.org
Idea is to use a 9 DOF IMU plus a GPS to log the GPS & IMU data (DCM computed) to level the images and put them on a map.

I am considering
- Sparkfun 9 Degrees of Freedom - Razor IMU - AHRS, http://www.sparkfun.com/products/10125 or
- DIYdrones ArduIMU+ V2 (Flat), http://store.diydrones.com/ArduIMU_V2_F ... imu-20.htm or
- ckdevices Mongoose IMU, http://store.ckdevices.com

It would be super-cool to have the IMU to seamlessly switch to dead reckoning when the GPS signal is lost. Like indoors. I am aware of the limitations of DR.
To the best of my knowledge commercially available off-the-shelf DR device for walking start at ca. 2000 $US.

Is there any chance at all of doing something similar with the hardware listed above?

Thanks,
Jan
janmartin AT diy-streetview DOT org

[trillium]

First let me say that I am just starting out on this, so I could easily be wrong, but - is there anything more you can improve by tweaking the interactions between the acquisition rate, (if you are using NMEA) what sentence(s) you output (or its equivalenet in binary) or your GPSs internal smoothing (if it has it)

That all varies from one chip to another. Some of the NMEA sentences will give you quite a bit of data on heading, speed, etc. The parameters that are used to decide when to sample, what to putput about it, and a zillion other things, can be tweaked within the GPS Settings substantially.

Another "signal" available to you is good old magnetic orientation.. i.e. compass.. Fluxgate compasses are out there. Or even do something with video.. (although that might easily get confused by moving objects)

That might be able to give you a sanity check you could compare your proposed heading changes with..

To get REALLY fine grained control that would seem to me to *require* some kind of combined dead reckoning/RTK/DGPS solution.