Dead-reckoning navigation

[john andrews]

Hello Bill, 

I've realized when i select the GPS to perform navigation 

#define DEADRECKONING 0

in the file "libUDB_defines.h" it's not related by any condition. 

However when selects the dead reckoning computations to perform navigation

#define DEADRECKONING 1

its directly related to a condition in the program which is: 

dcm_flags._.dead_reckon_enable == 1

in the file  "deadReckoning.c"  and this flag set provided it's  

udb_flags._.radio_on

in state.c file .

Why should the radio-on be set when use dead reckoning?

Best wishes, 

John,

[william premerlani]

John,

I am leaving soon on vacation for the rest of the week, and will be off grid without email access. I will get back to you when I get back.

Bill

--
--
---
You received this message because you are subscribed to the Google Groups "uavdevboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavdevboard...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/ef5696e6-a01a-43bc-b737-d740043dcf0d%40googlegroups.com.

[Roby]

Hi John,

I think that you cannot be  in Dead reckoning mode unless you connect the radio to the UDB and it sees a clean PWM input signal.

My observation is that why would you need this mode unless you were driving your plane. While the GPS mode is by default enabled since it is needed for the complementary filter used.

I think Bill or Pete can elaborate more..... Hope this helps.

Roby

[Peter Hollands]

Hi John,

(Roby, Thanks for your comments).

The code that you are referring to,  in states.c, is part of acquiringS() which is the routine run during startup, while acquiring GPS lock.

It  is structured for the normal startup process, which is that the transmitter has been turned on, and then the autopilot turned on.

After GPS lock has been acquired, he software is double checking that the radio signal from the transmitter is being received, before giving the important signal of waggling the Ailerons.

The waggle of the Ailerons implies that "All is OK" to take off with the autopilot from the point of view of MatrixPilot.

If there is no  radio signal being received, then in normal circumstances, the autopilot does NOT Waggle the ailerons, which shows the pilot that the Autopilot is not ready for takeoff.

If for some reason you want to run the  autopilot without any radio, then you can set the NORADIO option in options.h.

You can see that in the code the NORADIO option by passes the need for the radio to be on. DeadReckoning will be enabled once GPS is acquired, even though there is no radio signal.

#if (NORADIO == 1)

if (1)

#else

if (udb_flags._.radio_on)

#endif

I use the NORADIO option for my little "Chuck It"  free flying 90 gram glider.

Best wishes, Pete

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

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/d83dc15e-2555-40b3-882c-8257e719bb75%40googlegroups.com.

[Roby]

Hello Bill,

I am wondering why you added four in this line: #define DR_PERIOD (int16_t)((HEARTBEAT_HZ/GPS_RATE)+4).

Is it to take into account one time step delay in the GPS readings?

Regards,

Roby

[william premerlani]

Hi Roby,

DR_PERIOD is used to initialize a countdown clock to determine if the GPS has stopped reporting. If it has, then the GPS is no longer used in the IMU bias compensation computations. Take a look in the "dead reckoning" code:

https://github.com/MatrixPilot/MatrixPilot/blob/master/libDCM/deadReckoning.c#L142  

In order to assure the "freshness" of the GPS data, each time the GPS adjustments are applied to the IMU estimates, the clock ticks down one. Each time a valid GPS message is received, the clock is reset to DR_PERIOD. If the clock reaches zero, the GPS is no longer used and the IMU computations go into full "dead reckoning", GPS-less mode.

The the addition of "4" to the nominal reset value is to provide some margin in the logic. In other words, the clock ticks down and additional 4 more "ticks" after the GPS stops reporting before we give up on the GPS.

If and when the GPS resumes, the clock starts up again and the compensation computations resume.

Best regards,

Bill

--

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

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/4d440c5a-8205-40b1-a8f6-4a3f5ab05e28%40googlegroups.com.

[Roby]

Hi Bill,

It really makes sense what you said. Thanks for clarifying.

Is there any way I could test my UBLOX GPS for how much latency it has in terms of time ? I can not think of a simple way.

Regards,

Roby

On Monday, January 6, 2020 at 11:52:25 PM UTC+2, william premerlani wrote:

Hi Roby,

DR_PERIOD is used to initialize a countdown clock to determine if the GPS has stopped reporting. If it has, then the GPS is no longer used in the IMU bias compensation computations. Take a look in the "dead reckoning" code:

https://github.com/MatrixPilot/MatrixPilot/blob/master/libDCM/deadReckoning.c#L142  

In order to assure the "freshness" of the GPS data, each time the GPS adjustments are applied to the IMU estimates, the clock ticks down one. Each time a valid GPS message is received, the clock is reset to DR_PERIOD. If the clock reaches zero, the GPS is no longer used and the IMU computations go into full "dead reckoning", GPS-less mode.

The the addition of "4" to the nominal reset value is to provide some margin in the logic. In other words, the clock ticks down and additional 4 more "ticks" after the GPS stops reporting before we give up on the GPS.

If and when the GPS resumes, the clock starts up again and the compensation computations resume.

Best regards,

Bill

On Mon, Jan 6, 2020 at 12:44 PM Roby <roberts...@gmail.com> wrote:

Hello Bill,

I am wondering why you added four in this line: #define DR_PERIOD (int16_t)((HEARTBEAT_HZ/GPS_RATE)+4).

Is it to take into account one time step delay in the GPS readings?

Regards,

Roby

--
--
---
You received this message because you are subscribed to the Google Groups "uavdevboard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to uavde...@googlegroups.com.