SITL: add JSON backend example for velocity commanded vehicles

[kenjiked]

Summary

Adds a dependency free JSON backend example for vehicles that ArduPilot commands by velocity rather than by joint angle, together with the Rover parameters that model needs.

Classification & Testing (check all that apply and add your own)

• Checked by a human programmer
• Non-functional change
• No-binary change
• Infrastructure change (e.g. unit tests, helper scripts)
• Automated test(s) verify changes (e.g. unit test, autotest)
• Tested manually, description below (e.g. SITL)
• Tested on hardware
• Logs attached
• Logs available on request

Tested in Rover SITL on macOS. Started the backend, ran ardurover --model JSON:127.0.0.1 with the included default.parm, uploaded a two waypoint mission (30 m north, then 30 m east), armed and switched to AUTO. Both waypoints were reached, closest approach 0.27 m and 2.96 m. No hardware was driven from this.

Nothing outside libraries/SITL/examples/JSON/python/ is touched, and no existing file is modified. flake8 passes with the repository configuration.

Description

libraries/SITL/examples/JSON/pybullet/walking_robot.py models a walking robot whose twelve leg joints ArduPilot drives directly through twelve servo outputs.

Walking robots sold as complete products work the other way around: the gait controller stays on board and the joints are not exposed. The autopilot asks for a forward speed and a turn rate, and the on-board controller decides how to walk. Unitree's Go2 is one such vehicle. Tracked and differential platforms that accept a velocity command over a serial or network link present the same interface.

This adds a backend for that case, so Rover's navigation, mission and failsafe code can be exercised against a velocity commanded vehicle. The vehicle model is a plain unicycle with a first order lag standing in for the on-board controller. It uses only the Python standard library, so it runs without pybullet or any other simulator.

default.parm carries the matching Rover parameters. Two are easy to get wrong and are documented in the readme:

• ATC_STR_RAT_FF is the steering fraction required for one radian per second, so it is 1 / max turn rate. Left at the default while the model turns at 1.2 rad/s it under states the gain by a factor of four, and the vehicle yaws about the target heading without making meaningful forward progress.
• CRUISE_SPEED and CRUISE_THROTTLE have to describe the same vehicle as the model's maximum speed.

The readme also records two things that cost me time and may help anyone writing a similar backend:

• The skid mixer in AP_MotorsUGV computes motor_left = throttle + steering, so a positive turn rate means the left motor runs faster. With that sign inverted the vehicle settles pointing 180 degrees away from the target and yaws forever, which is not obvious to diagnose.
• ArduPilot sends 0 on servo channels it is not driving. Scaling that as a PWM value yields full reverse, so values outside a sane band are treated as neutral.

[Georacer]

Hello! I've tested it with your instructions and it works: the rover moves around.
Also, nice to have a simple JSON+python demo.

It's a little awkward having to launch it from the simulator directory, but... eh. It's not the end of the world.

One thing: While I understand your argument about AP issuing desired velocity commands, you make it sound like this was the whole point of demonstration for this PR.
However, I don't see how this particular demo is different to any stock AP rover application.
Could you say a little more?