As shown in the figure, I want the ROV to rotate uniformly around a central point, the head of the ROV is always towards the center of the circle, and the body of the ROV is always in the radius of the circle, so that the trajectory of the ROV is a circle with a diameter of ‘d’.
To achieve this, I added a yaw angular velocity ‘w’ and a transverse linear velocity ‘v’ to the ROV, and then controlled the speed by changing the PWM value. In theory, ROV will move in a circle with radius ‘r= v/w’, but I found that this control effect is not very good. ROV is susceptible to various factors in the process of movement, so is there a way to directly control the speed? In this way, the ROV can move in a circle.
Hi @robotmark,
How are you approaching this? Are you using a custom flight mode that tries to maintain a yaw rate and lateral (body-frame) speed for the vehicle (or an external equivalent using MAVLink telemetry), or are you doing something like commanding consistent yaw and lateral thruster outputs via manual control?
Control accuracy is dependent on the accuracy and precision of the encoded understanding of the vehicle’s dynamics and the environment it’s operating in. Notably,
- feed-forward control (i.e. with no feedback from sensors) is only as good as the built in models, and has no way of detecting or dealing with any drift from the intended path (due to model inaccuracies)
- thrusters are controlled primarily by thrust output, which is not necessarily directly correlated with vehicle speed, and is also not linear with PWM values
- moving water (e.g. from currents, or from the vehicle earlier in time) adds forces to the vehicle that feed-forward control doesn’t know about and hence can’t counteract
- control with feedback is still only as good as the sensor data, and derivative feedback can not handle integral drift
- e.g. accelerometer values can estimate instantaneous velocity, but because the values aren’t provided for every moment in time there’s inevitably some error (together with innate error/noise in the actual readings), which leads to slight inaccuracies in every velocity estimate, and progressively larger errors for position estimation
- this leads into the discussion in your previous post about speed
For short periods of time you may be able to use a custom flight mode that does what it can to maintain the yaw rate and lateral (body frame) speed estimate from IMU readings, but positional drift is inevitable and can’t be corrected for. The same reasoning applies to doing this externally, but error will occur faster because MAVLink telemetry has additional latency as well as lower frequency access to the sensor measurements.
Fundamentally, controlling motion in a circle with a consistent radius and center requires some sort of positional feedback, because geometry is position based. If your vehicle has accurate position measurements then you may be able to use the developmental circle flight mode that’s built in to ArduSub. Alternatively if you have something like a pole or vertical column at the location that you’re rotating around you may be able to use computer vision as a localised feedback source instead, as discussed in this post.
Thank you. I solved this problem by using computer vision as a feedback source for localization. Thanks again.
1 Like
@robotmark hi Mark. My coursemates and I are trying to set up some kind of localisation for our ROV using fiducial markers from the video stream of the vehicle. At the moment we’re using ROS packages to write the localisation software, but we haven’t managed to integrate the ROS packages with the control of the vehicle. Any information on how you got your computer vision localisation to work would be greatly appreciated. Thanks!