Clever People
I have a standard BW ROV2 vectored thrust six thruster frame with the latest versions of QGroundControl, PI companion software and Ardusub. All standard BW hardware. For test purposes in a test tank I have a full CAT6 interface between the PC running QGroundControl and the PI.
I am testing a supplementary camera system attached to the ROV (but not wet interfaced) which through embedded code generates ROV relative position wrt. a target sheet in the water. (ASCII NMEA-like messages giving xyz metre values in the ROV reference frame). The camera has an integral high-end PRH sensor so the xyz values are able to be gravity referenced (plannimetric distances). This camera (and hence internal PRH sensor axes) are aligned well-enough with the ROV frame. This camera connects to the surface via a secondary ethernet link.
Through surface software, I can turn the distance values into fake WGS84 NMEA GGA\VTG message and pump UDP to port 27000 on the PI. The ROV outline in QGroundControl then motors about as expected (but heading is still based on where the PixHawk is facing in the world) etc.
Questions:
-
How do I override the use of the Pixhawk’s internal three-axis magnetometer-based heading calculation. I am sending a bullet-proof NMEA VTG message to the PI and would prefer to use it instead. i.e, so only the VTG value is used in the EKF.
-
Where does RMC come into it? If I sent RMC (with SOG) can it be used in the various navigation modes or it ROV SOG calculated locally from GGA?
-
How does ROV heading hold relate to the current Ardusub ‘position-hold’ mode. i.e, is it possible to define a desired heading AND location in a waypoint via QGC. Can the ROV be yawed manually whilst flying to a waypoint or whilst holding station over a position?
Assuming some of the above is viable, the intent is to have the ROV ‘follow’ a target board which is moved about in the test tank slowly. i.e, the varying fake UDP GGA sent to the PI makes the ArduSub EKF think the ROV is off-position from its position-hold waypoint and hopefully translates the ROV accordingly. Whilst I can determine the misalignment between ROV and target (i.e, camera and ROV is not head-on to target sheet), I’m not sure what the current Ardusub software could do with this value. I can turn this value into a fake VTG message BUT the ArduPilot code then needs to knows to attempt to maintain both a position AND a heading etc. A la. Dynamic Positioning on larger vessels\ROVs.
Any advice very welcome.
Tony