ArduPlane v2.76 Vs 2.73 tested in STABILIZE Mode

Hi Jean-Louis,

I've spent a few hours on the HIL code today and I think I have something that may help you get flying HIL again.

The first thing is I found your HIL_STATE messages are actually more rapid than I thought. I thought they were too slow as I looked at this graph:

as you can see that apparently shows that HIL_STATE messages are coming in every 300 thousand microseconds, so about 3Hz or so. That is why I told you it was too slow.

It turns out however that your HIL setup (is it MissionPlanner?) is using the wrong units for the time_usec field in HIL_STATE. It should be in microseconds, but its actually sending it in 10ths of microseconds. So the above actually shows 30Hz rate, as can be seen in this zoomed graph of the same data.

that is one seconds worth of data, and it clearly has a lot more than 3 data points!

So the next thing to work out is if we could make HIL_SENSORS less sensitive to timing, to make it more usable again. I have made a number of changes towards that:

the first change was to add the SIMSTATE message to HIL. The SIMSTATE MAVLink message contains the state of the simulator. It means that telemetry logs contain both the true attitude of the aircraft as well as the APM estimated attitude. That message is used in SITL, so it was easy to add it to HIL as well. By graphing ATTITUDE.roll and ATTITUDE.pitch against SIMSTATE.roll and SIMSTATE.pitch it became much easier to diagnose HIL issues. It also contains the true position of the aircraft, which is useful for testing dead-reckoning.

The next change was to change the HIL GPS driver to run correctly at 5Hz. The driver was previously reporting "new data" on every HIL_STATE message. That meant the DCM driver was seeing GPS updates at 30Hz or more, which it is not designed to handle. I've changed the HIL GPS driver to only report new positions at 5Hz. That reduced the CPU overhead of HIL a lot too, as the GPS updates in AP_AHRS_DCM are quite expensive.

Next we needed to find a way to make HIL_SENSORS handle bad HIL timing. As I've explained in my previous messages HIL can never really be accurate - the timing of the sensor data over the serial port is far too erratic. The old HIL_ATTITUDE code coped with that by just disabling DCM completely, but we can't do that any more as we need an AHRS subsystem for many of the new controllers to work (see my previous explanations). So what I did was add a new parameter that only exists in HIL called HIL_ERR_LIMIT. That is the amount of error (in degrees) between the HIL_STATE attitude and the DCM attitude that is allowed. If the error ever goes above that limit then DCM is asked to reset its rotation matrix to match the HIL_STATE attitude. I've set the default to 5 degrees, so you won't ever get an error in DCM attitude while in HIL of more than 5 degrees.

The next problem to solve was the slow servo outputs. The 2.76 release includes a lot of scheduling improvements that make APM fly better, but make HIL fly worse. The changes prioritize flying the aircraft over sending telemetry updates to the GCS. That is the right thing to do for a real aircraft, but it slows down the servo updates for HIL, as the GCS is the one that sends servo updates to the simulator. So I've added a additional send of the SERVO_OUTPUT_RAW message in Attitude.pde (see the set_servos() function) when in HIL mode. That means it will try to send servo updates to the GCS at the full 50Hz.

The problem with the last change (the fast send of SERVO_OUTPUT_RAW) is that I don't know if your HIL system is using SERVO_OUTPUT_RAW or RC_CHANNELS_SCALED. Those two messages can both be used for HIL. My HIL system uses SERVO_OUTPUT_RAW, but I don't know what yours uses. Do you use MissionPlanner? If you find it still flies badly then change this code in Attitude.pde:

    if (comm_get_txspace(MAVLINK_COMM_0) - MAVLINK_NUM_NON_PAYLOAD_BYTES >= MAVLINK_MSG_ID_SERVO_OUTPUT_RAW_LEN) {
        send_radio_out(MAVLINK_COMM_0);
    }

to this:

    if (comm_get_txspace(MAVLINK_COMM_0) - MAVLINK_NUM_NON_PAYLOAD_BYTES >= MAVLINK_MSG_ID_RC_CHANNELS_SCALED_LEN) {
        send_servo_out(MAVLINK_COMM_0);
    }

(I did look in the MissionPlanner HIL code, but I couldn't work out what it uses)

I've pushed all these changes into my HIL-wip branch, here:

https://github.com/tridge/ardupilot/tree/HIL-wip

I'll push them into git master when I've done some more testing.

There are also some tuning values you'll probably need. Flying a plane in HIL is really nothing like flying a real plane as the latencies are so high. So you need to adjust down the time constants in a few controllers, and you need to use smaller gains. You also need to disable the AHRS GPS delay compensation, as the HIL GPS doesn't have any lag. Finally you need more rapid AHRS drift correction.

So you need to make the following changes:

AHRS_GPS_DELAY = 0
AHRS_RP_P = 0.4
AHRS_YAW_P = 0.4
RLL2SRV_TCONST = 2
PTCH2SRV_TCONST = 2
TECS_TIME_CONST = 10
HIL_ERR_LIMIT = 5

with those changes I can fly the Rascal110 OK in HIL. It doesn't fly nearly as well as it does in SITL though. The lag in HIL is far too high to really tune it well.

btw, the Calmato is a great plane. They are popular at my local flying field. I do think that it can be tuned a lot better than the settings you have now. The Calmato is a nice stiff balsa plane which is very agile, quite similar to the AcroWot that I tend to fly these days. With the right tuning the Calmato should really fly missions extremely accurately, with very sharp and precise turns. You'll never get that in HIL though, the lag means you have to use very low attitude controller gains and high NAVL1_PERIOD. In the real aircraft I suspect you could fly with NAVL1_PERIOD of below 14 once you have tuned the roll/pitch controllers correctly.

Cheers, Tridge

tridge/ardupilot

Contribute to tridge/ardupilot development by creating an account on GitHub.

Replies

Developer
Andrew Tridgell November 23, 2013 at 12:21am
Hi Jean-Louis,

I've spent a few hours on the HIL code today and I think I have something that may help you get flying HIL again.

The first thing is I found your HIL_STATE messages are actually more rapid than I thought. I thought they were too slow as I looked at this graph:

as you can see that apparently shows that HIL_STATE messages are coming in every 300 thousand microseconds, so about 3Hz or so. That is why I told you it was too slow.

It turns out however that your HIL setup (is it MissionPlanner?) is using the wrong units for the time_usec field in HIL_STATE. It should be in microseconds, but its actually sending it in 10ths of microseconds. So the above actually shows 30Hz rate, as can be seen in this zoomed graph of the same data.

that is one seconds worth of data, and it clearly has a lot more than 3 data points!

So the next thing to work out is if we could make HIL_SENSORS less sensitive to timing, to make it more usable again. I have made a number of changes towards that:

the first change was to add the SIMSTATE message to HIL. The SIMSTATE MAVLink message contains the state of the simulator. It means that telemetry logs contain both the true attitude of the aircraft as well as the APM estimated attitude. That message is used in SITL, so it was easy to add it to HIL as well. By graphing ATTITUDE.roll and ATTITUDE.pitch against SIMSTATE.roll and SIMSTATE.pitch it became much easier to diagnose HIL issues. It also contains the true position of the aircraft, which is useful for testing dead-reckoning.

The next change was to change the HIL GPS driver to run correctly at 5Hz. The driver was previously reporting "new data" on every HIL_STATE message. That meant the DCM driver was seeing GPS updates at 30Hz or more, which it is not designed to handle. I've changed the HIL GPS driver to only report new positions at 5Hz. That reduced the CPU overhead of HIL a lot too, as the GPS updates in AP_AHRS_DCM are quite expensive.

Next we needed to find a way to make HIL_SENSORS handle bad HIL timing. As I've explained in my previous messages HIL can never really be accurate - the timing of the sensor data over the serial port is far too erratic. The old HIL_ATTITUDE code coped with that by just disabling DCM completely, but we can't do that any more as we need an AHRS subsystem for many of the new controllers to work (see my previous explanations). So what I did was add a new parameter that only exists in HIL called HIL_ERR_LIMIT. That is the amount of error (in degrees) between the HIL_STATE attitude and the DCM attitude that is allowed. If the error ever goes above that limit then DCM is asked to reset its rotation matrix to match the HIL_STATE attitude. I've set the default to 5 degrees, so you won't ever get an error in DCM attitude while in HIL of more than 5 degrees.

The next problem to solve was the slow servo outputs. The 2.76 release includes a lot of scheduling improvements that make APM fly better, but make HIL fly worse. The changes prioritize flying the aircraft over sending telemetry updates to the GCS. That is the right thing to do for a real aircraft, but it slows down the servo updates for HIL, as the GCS is the one that sends servo updates to the simulator. So I've added a additional send of the SERVO_OUTPUT_RAW message in Attitude.pde (see the set_servos() function) when in HIL mode. That means it will try to send servo updates to the GCS at the full 50Hz.

The problem with the last change (the fast send of SERVO_OUTPUT_RAW) is that I don't know if your HIL system is using SERVO_OUTPUT_RAW or RC_CHANNELS_SCALED. Those two messages can both be used for HIL. My HIL system uses SERVO_OUTPUT_RAW, but I don't know what yours uses. Do you use MissionPlanner? If you find it still flies badly then change this code in Attitude.pde:

    if (comm_get_txspace(MAVLINK_COMM_0) - MAVLINK_NUM_NON_PAYLOAD_BYTES >= MAVLINK_MSG_ID_SERVO_OUTPUT_RAW_LEN) {
        send_radio_out(MAVLINK_COMM_0);
    }

to this:

    if (comm_get_txspace(MAVLINK_COMM_0) - MAVLINK_NUM_NON_PAYLOAD_BYTES >= MAVLINK_MSG_ID_RC_CHANNELS_SCALED_LEN) {
        send_servo_out(MAVLINK_COMM_0);
    }

(I did look in the MissionPlanner HIL code, but I couldn't work out what it uses)

I've pushed all these changes into my HIL-wip branch, here:

https://github.com/tridge/ardupilot/tree/HIL-wip

I'll push them into git master when I've done some more testing.

There are also some tuning values you'll probably need. Flying a plane in HIL is really nothing like flying a real plane as the latencies are so high. So you need to adjust down the time constants in a few controllers, and you need to use smaller gains. You also need to disable the AHRS GPS delay compensation, as the HIL GPS doesn't have any lag. Finally you need more rapid AHRS drift correction.

So you need to make the following changes:
- AHRS_GPS_DELAY = 0
- AHRS_RP_P = 0.4
- AHRS_YAW_P = 0.4
- RLL2SRV_TCONST = 2
- PTCH2SRV_TCONST = 2
- TECS_TIME_CONST = 10
- HIL_ERR_LIMIT = 5
with those changes I can fly the Rascal110 OK in HIL. It doesn't fly nearly as well as it does in SITL though. The lag in HIL is far too high to really tune it well.

btw, the Calmato is a great plane. They are popular at my local flying field. I do think that it can be tuned a lot better than the settings you have now. The Calmato is a nice stiff balsa plane which is very agile, quite similar to the AcroWot that I tend to fly these days. With the right tuning the Calmato should really fly missions extremely accurately, with very sharp and precise turns. You'll never get that in HIL though, the lag means you have to use very low attitude controller gains and high NAVL1_PERIOD. In the real aircraft I suspect you could fly with NAVL1_PERIOD of below 14 once you have tuned the roll/pitch controllers correctly.

Cheers, Tridge
tridge/ardupilot

Contribute to tridge/ardupilot development by creating an account on GitHub.
Developer
Andrew Tridgell November 20, 2013 at 1:30pm
Hi JL,

It would be useful if you could post tlogs and flash logs of the experiment with 2.76. That may allow us to determine what is failing.

It would also be useful to run a few more experiments to narrow down the issue. Specifically:
- does it happen in other modes?
- does it depend on having some specific settings in the roll/pitch controllers? (eg. integrator)
- does AHRS.error_rp show large values indicating a DCM breakdown?
- does it depend on the value of AHRS_GPS_DELAY ?
It is very hard to tell from a video, but it is possible that you are seeing a HIL artifact. The HIL code does not simulate GPS delay, which means the new AHRS_GPS_DELAY code will cause the accelerometers and GPS data to get out of sync, whereas in a real aircraft (or in SITL) it serves to bring them into sync. HIL can be great sometimes, but it does suffer from a high degree of timing sensitivity.

I have tried to reproduce the error in SITL and haven't managed to reproduce it so far. That may be that I'm just not moving the sticks in the same way you are, or it may be that it is airframe dependent.

If you can post some logs and try some of the above experiments then hopefully we can work out what is going on. Thanks!

Cheers, Tridge

This reply was deleted.

ArduPlane User Group

Replies