last_letter integration with APM:Plane

[Andrew Tridgell]

Hi George,

I've added drones-discuss list to the CC

For those on drones-discuss, this discussion started in regard to a new
wiki page George created on using the last_letter ROS based flight
simulator with APM:Plane SITL:

http://dev.ardupilot.com/wiki/simulation-2/sitl-simulator-software-in-the-loop/using-last_letter-as-an-external-sitl-simulator/

we're discussing moving away from wall-clock time, with the aim of
making SITL runs with last_letter be completely repeatable, with the
physics being completely independent of host clock speed.

> What is the highest rate that you are comfortable with ardupilot SITL
> running, so that I can check the stability of l_l at that rate?

I think we'll need to experiment to see what works. Keeping it as a
multiple of 50 and 400Hz would be nice, so it is a nice multiple for our
INS system. We could for example do the comms at 400Hz and have
last_letter do two time steps per sample allowing for an 800Hz physics
model.

> Do you want to propose an extended fdm packet to carry the additional
> information? Every piece of measurement and information is available within
> a simulation environment. Go crazy!

yes, creating our own format makes sense. Right now we fake up some
things, like using the altitude to fake up barometric pressure and
temperature. We also fake up the true vs apparent airspeed.

I also think we should be able to send the packets directly from
last_letter to the C++ ArduPlane.elf, instead of relaying via the python
script. I suspect the python script is a bit of a bottleneck.

The key though is the synthetic time handling. That will need some
changes in the ArduPilot code. I'll prototype those when I get a chance
using the copter/rover python simulators we have in SITL now. Then once
that works we can extend to using it with last_letter.

Cheers, Tridge

[George ZP]

Hi Tridge,

In the premises of realistic and predictable simulation, I would also like to propose this as an end-goal. Instead of having the SITL code fake all those aforementioned readings, by using only a very limited set from the old FDM packet information, we could move this task to last_letter.
Let the simulation calculate ALL sensor messages (for example all the sensors of the PXF cape) and model the errors as well and communicate them to SITL. From there, the HAL can do its work.
The reason I propose this is that it allows us to have a more complete testing environment, aided by the simulation.

Examples:

1. My primary goal for now: Incorporate a heat dissipation model. We all know how temperature shifts in the atmosphere badly affect barometric altitude estimation. Ambient temperature drift is not implemented in l_l yet, but it's quite trivial to do so, once the interface is decided upon. What isn't trivial, and it's what I have my eyes set on currently, is come up with a model to simulate the rise in temperature inside the APM case, which I suspect affects the altitude estimation just as badly. Temperature drifts of up to 10degs at boot have been recorded and users need to reboot their systems before flight to combat this.
2. Have realistic sensor rates and error models and let the software developers find algorithms to solve the related issues from the seat of their pants, with as little flight testing as possible. Sensor boards offset from the CG, tilted at an angle, with a pre-specified noise spectrum profile are some things that come to the top of my head.
3. Examine fault conditions easily. Albeit the aerodynamics model for a plane is not trivial at all and all we have (even for JSBSim) is an approximated polynomial function of the predicted behaviour, we can do some pretty handy things with it: Fake servo lock-ups, weight shifting, loss of mass etc.

All the above, and many more, are topics that would make a great simulator for UAV development. The task to orchestrate all these under a single software solution seems complicated, but I look forward to the challenge.

Have a nice day,

George

On Thursday, March 19, 2015 att

[Andrew Tridgell]

Hi George,

> In the premises of realistic and predictable simulation, I would also like
> to propose this as an end-goal. Instead of having the SITL code fake all

> those aforementioned readings, by using only a *very limited* set from the

> old FDM packet information, we could move this task to last_letter.
> Let the simulation calculate ALL sensor messages (for example all the
> sensors of the PXF cape) and model the errors as well and communicate them
> to SITL. From there, the HAL can do its work.

I'd be very happy for last_letter to do more of that sensor emulation,
although I don't think we will be able to emulate the full Pixhawk
sensor suite. We now sample the lsm303d accelerometers at 1600Hz for
example, and I don't think it will really help to do that sort of sample
rate from last_letter.

Another thing I'd like to keep is an easy way to control the simulation
environment. Right now you can do:

param set SIM_ACC_RND 3

to add 3m/s/s of accel noise. That sort of interface is very useful.

You can see all of the simulation parameters here:

https://github.com/diydrones/ardupilot/blob/master/libraries/SITL/SITL.cpp#L31

I definately do like the idea of better temperature modelling in the
FDM. Quite a few people are doing high altitude flights (above 20km) now
with ArduPilot, and it is nice to be able to simulate that before
flying. We do that now in JSBSIm, but I think it could be improved.

> What isn't trivial, and it's what I have my eyes set on currently, is come

> up with a model to simulate the rise in temperature *inside* the APM

> case, which I suspect affects the altitude estimation just as badly.

We actually use the temperature from a digital airspeed sensor if
available, as that sensor is usually close to ambient air temperature
(out on a wing).

There are 5 temperature sensors in a typical Pixhawk plane, and will be
even more on the next board. We only use 2 of them for now (baro and
airspeed sensor), but we are considering doing temperature calibration
of the IMUs using their temperature sensors.

> Temperature drifts of up to 10degs at boot have been recorded and users
> need to reboot their systems before flight to combat this.

it is often a lot more than 10 degrees

> 3. Examine fault conditions easily. Albeit the aerodynamics model for a

> plane is not trivial at all and all we have (even for JSBSim) is an
> approximated polynomial function of the predicted behaviour, we can do some
> pretty handy things with it: Fake servo lock-ups, weight shifting, loss of
> mass etc.

yes! One of the things that I hope to get out of the collaboration is
some of this special case handling. For example, I hacked up support for
balloon launches in SITL using JSBSIm, but it was an awful hack. There
are all sorts of special considerations with balloon launched planes,
and having proper support for it in a simulator would be really nice.

same with catapult launches, parachute landings, dropping objects,
losing a servo, blocked pitot tubes (from rain) etc etc.

> All the above, and many more, are topics that would make a great simulator
> for UAV development. The task to orchestrate all these under a single
> software solution seems complicated, but I look forward to the challenge.

me too!

Cheers, Tridge