Short term dead reckoning

Hello all-

My goal with my rover setup is to allow for short term dead reckoning in the event of loss of gps or a weak gps signal. The plan is the rover would automatically switch over to a dead reckoning system, until gps signal is strong enough to return to.

Because the existing navigation system works so well, I wanted to change it as little as possible. My plan is to inject estimated GPS information into the existing code. What I mean is, the dead reckoning system will give me a latitude and longitude, and I want to plug that into the existing navigation setup. The navigation system will be "fooled" into thinking it has normal GPS info.

My first hurdle comes with figuring out in the code where the best place to do this is. Where is the gps data updated? It looka like "current_loc" (an instance of the struct "Location" in firmware ArduRover v2.30 ) is what I need to alter. My problem is I can't find where this is set/updated.

Anybody have any insight into this?

Any alternative ideas to going about this?

Thanks,

Kevin

Looking at the 2.3 alpha. In the libraries folder there's an AP_Airspeed module. Possibly you could base your encoder module on. Call it AP_Groundspeed or something.

Take a look at the settable parameters in libraries/AP_AHRS.cpp and look for the parameter line: AP_GROUPINFO("GPS_USE", 3, AP_AHRS, _gps_use, 1) and the comments above it. "@Description: This controls whether to use dead-reckoning or GPS based navigation. If set to 0 then the GPS won't be used for navigation, and only dead reckoning will be used." If you find out where that is used in the rest of the code it may give you some hints on how to tweak the code to switch back and forth. Or at least tell you where gps comes into play. For example _gps_use shows up in AP_AHRS_DCM.cpp in this routine (I am using grep like a maniac to find all this):

// return true if we have and should use GPS
bool AP_AHRS_DCM::have_gps(void)
{
    if (!_gps || _gps->status() != GPS::GPS_OK || !_gps_use) {
        return false;
    }
    return true;
}

Which in turn shows up in AP_AHRS_DCM::drift_correction_yaw(void) -- which appears to have some associated airspeed stuff. You can kind of see where in this part of the code that estimates ground speed can be replaced with more direct estimates of groundspeed from GPS and/or encoders. THere's a section where it calculates position offsets to north and east:

        // update position delta for get_position()
        _position_offset_north += velocity.x * _ra_deltat;
        _position_offset_east += velocity.y * _ra_deltat;

It looks like this is doing the actual dead reckoning position estimate update. Or maybe it's just calculating error caused by wind drift. I didn't spend tons of time looking but I imagine it should be obvious if one did.

Also, there's a routine bool AP_AHRS_DCM::airspeed_estimate(float *airspeed_ret) that will likely have some hints too.

Anyway, hope that helps and hope to hear back what you find.

Replies

Bot Thoughts March 9, 2013 at 5:43pm

Looking at the 2.3 alpha. In the libraries folder there's an AP_Airspeed module. Possibly you could base your encoder module on. Call it AP_Groundspeed or something.

Take a look at the settable parameters in libraries/AP_AHRS.cpp and look for the parameter line: AP_GROUPINFO("GPS_USE", 3, AP_AHRS, _gps_use, 1) and the comments above it. "@Description: This controls whether to use dead-reckoning or GPS based navigation. If set to 0 then the GPS won't be used for navigation, and only dead reckoning will be used." If you find out where that is used in the rest of the code it may give you some hints on how to tweak the code to switch back and forth. Or at least tell you where gps comes into play. For example _gps_use shows up in AP_AHRS_DCM.cpp in this routine (I am using grep like a maniac to find all this):

// return true if we have and should use GPS
bool AP_AHRS_DCM::have_gps(void)
{
    if (!_gps || _gps->status() != GPS::GPS_OK || !_gps_use) {
        return false;
    }
    return true;
}

Which in turn shows up in AP_AHRS_DCM::drift_correction_yaw(void) -- which appears to have some associated airspeed stuff. You can kind of see where in this part of the code that estimates ground speed can be replaced with more direct estimates of groundspeed from GPS and/or encoders. THere's a section where it calculates position offsets to north and east:

        // update position delta for get_position()
        _position_offset_north += velocity.x * _ra_deltat;
        _position_offset_east += velocity.y * _ra_deltat;

It looks like this is doing the actual dead reckoning position estimate update. Or maybe it's just calculating error caused by wind drift. I didn't spend tons of time looking but I imagine it should be obvious if one did.

Also, there's a routine bool AP_AHRS_DCM::airspeed_estimate(float *airspeed_ret) that will likely have some hints too.

Anyway, hope that helps and hope to hear back what you find.
Bot Thoughts March 9, 2013 at 2:53pm

I am guessing this is ArduRover? Doesn't ArduRover use compass and encoders already? I could swear ArduPilot doesn't just lose itself if GPS goes out briefly...? As soon as I can get a copy of the ArduRover code I can probably answer this for myself :)
Rud Merriam March 7, 2013 at 12:07pm

I am curious how you are going to generate estimated GPS. I am working on a swarm where I cannot use GPS or compass so am interested in dead-reckoning and other techniques.

This reply was deleted.

ArduRover User Group

Replies