SITL Improvements

[auturgy]

Umbrella issue to plan a SITL Sprint Platform [ X ] All

Please be specific in requests: which vehicle and sensor models to add/improve to which simulator, etc

[khancyr]

• Json schema unification and consolidated

• Json support for gazebo

• Timeserver for SITL : alllow better mutil instance synchronisation and better lockstep with simulators

• Better ground management to allow some obstacles and ground types

• better physics definitions for rover and plane similarly to copter one's

[andyp1per]

• UART device emulators: RXs, RunCam
• OSD autotest framework to assert output

[tridge]

I'd like to be able to use a nice 3D backend for visualisation while using the internal physics for a vehicle. Ideally this would be done while allowing for collisions to be calculated in the 3D backend

[rmackay9]

My requests are similar to Tridge's above. I'd like an easy-to-start and free 3D visualisation that is closely integrated with our existing SITL. Ideally it should be as easy to start as the 2D viewer started with sim_vehicle. No extra scripts to run, no licenses or separate downloads required.

Ideally the 3D environment would provide simulated 3D cameras pointing forward and downwards which give us point clouds and RGB images that we could then pass into scripts (probably python) to convert the data into a form that can be passed into the AP flight code (i.e. mavlink message most likely)

[peterbarker]

Maybe a GSoC project for the 3D environment?

[srmainwaring]

Schema:

• Strongly support the standardisation of FDM state and sensor JSON for the simulation backends where it makes sense.

Sensors:

The range of sensors supported by PX4-SITL plus:

• wheel encoder data or odometry (depending on where you draw the line between processed unprocessed sensor data)
• odometry from other sources (visual)
• joint positions (might be useful for walking robots / grippers using serial servos that provide position feedback)
• contact sensors
• anemometer

Sensor / FDM integration

• Some sensor backends differentiate between SITL native sensors and external ones (e.g. AP_WindVane_SITL.cpp). Is there any merit in putting all simulated sensors on the same footing and treating the SITL physics / sensor backends as just another backend that can be mixed and matched? (So SITL native dynamics has the same relationship to the FCU code as say Gazebo or FlightAxis?). That might also help with putting together a visualisation package for SITL as it would formalise responsibilities between different components?

Question about visualisation backend: is the idea that the 3D backend maintains the graphics update and collision space and sends the contacts back to SITL to incorporate in the SITL dynamics engine?

[IamPete1]

would be nice to unlink the built in physics from AP, so you could connect the physics via the JSON backend, this would allow a easy path ride along flight controllers to test features such as standby mode or simulate AP_Periph sensors.

[stephendade]

+1 to consolidating the SITL backends to the JSON backend

• A few more copter, rover and boat models, like we have for plane
• Easier method to run multiple vehicles simultaneously. Perhaps a "sim_vehicle_multi.py".
• Decent set of default tuned parameters for all models (boat in particular)

[khancyr]

@stephendade we already got a swarm option on sim_vehicle.py. it can still be improved but that outside SITL scope

[JustCurious8]

@stephendade we already got a swarm option on sim_vehicle.py. it can still be improved but that outside SITL scope

Been trying some stuffs related to synchronisation of some particular actions between multiple SITL instances using GPS time, that is working well on multiple quadcopters in real time but I am not able to achieve that synchronisation with multiple SITL instances

@IamPete1 suggested using JSON backend to lock step all the instances together, according to him which requires using a external physics backend, but could allow it to use the internal one, but I am not able to figure out implementation for that

[srmainwaring]

@Notorious811 suppose we take SIM_Rover as an example and want to use its physics with the SIM_JSON backend. Both subclass from SIM_Aircraft which contains both FDM code and FCU update code:

Where SIM_JSON is concerned it is (mostly) updating the FCU with the current FDM state from the external physics model, calculating its response in terms of PWM values, then sending them back to the external physics model.

Where SIM_Rover is concerned SIM_Aircraft is both maintaining the bulk of the rigid body dynamics and updating the FCU and getting its response. SIM_Rover adds vehicle specific behaviour over that.

I think the proposal from @IamPete1 and what I was trying to express in my list of requests, is a clean split between the two responsibilities. So the parts of SIM_Aircraft which deal with the physics (rigid body dynamics and sensor simulation) are split from the part the talks to the controller code and get the control outputs.

I see a number of benefits in organising the calculation this way:

• it would ensure the FCU code is only responding to vehicle physics and not generating or short circuiting it
• it would highlight where external simulators need to be augmented with additional physics and sensor data in SITL
• it puts internal SITL physics models on the same footing as external simulations
• it lets you access the SITL physics models in other contexts - for instance you might want to have SITL physics drive another simulation engine that allows physics models to be plugged in (I'm thinking that Gazebo might let you do this as its server permits slotting in a number of physics engines already such as ODE, Dart, Bullet, Simbody).

It would probably be worth providing an extra interface that didn't require sockets to pass JSON back and forth between the FDM and FCU parts to keep the AP testing infrastructure simple and make it easier to debug.