We did a bit of testing and digging today, and found that using SET_POSITION_TARGET_* requires using Guided mode, which in its current implementation requires having both a position estimate and a position target. When setting just velocity targets the initialisation process includes setting the position target to its current position.
In a simulated vehicle (which includes a GPS signal) we were able to use the velocity target mode, but it moved a short distance before slowing and stopping, presumably reaching an equilibrium between trying to maintain a constant non-zero velocity while also trying to maintain a constant position.
We were able to get accelerometer-only position estimates (on a Navigator, not simulated) to at least occur internally by setting EK3_SRC1_POSXY, EK3_SRC1_VELXY and EK3_SRC1_VELZ from “GPS” to “None”, and setting a global origin, but from what we could tell the internal position estimates were not being output over MAVLink (via the AHRS2, GLOBAL_POSITION_INT, and GPS_RAW_INT messages that were being sent), so there’s not an obvious way to feed back the current position as the vehicle moves and allow the position target to be updated.
We’ll try to do some more testing, but at this stage while we in principle agree that it should be at least allowed to try to maintain velocity without a position sensor, it seems there are some aspects of the current implementation that are stopping that from happening. It’s also very possible that even if we manage to enable it, the velocity estimates from integrated accelerometer data will be far too noisy to have usable performance.
If we can find a reasonably simple way of enabling it then we’ll try to do so (it would be nice to at least have the option, in case “poor performance” is still “good enough” for some use-cases), but we’ll have to see how complicated and time consuming that is to do.