There are three main issues we are facing, and I am not sure if they are all separate issues or if they are correlated.
1. Ocsillations - They vehicle started oscillating in the roll, and slightly in yaw. We managed to reduce/remove the ocsillation by tuning the PID controller for roll rate and yaw rate.
2. Yaw with an extensive pitch angle - In our work we often need to look underneath objects. This means that pitching the entire vehicle up and manouvering it in heavily pitched position is normal. After the change from pixhawk1 to Navigator the behavior of the vehicle in this position has changed. In pixhawk1 the yaw movement was as if the Z-axis was pointing straight up towards the surface. With the Navigator it seems like the yaw movement follows a Z-axis pointing straight up from the vehicle.
3. Roll static error - After manouvering the vehicle as described in 2. and then reducing the pitch angle to level out the vehicle, it has gained a static error in roll angle which does not diminish. The control mode needs to be toggled stabilize - manual - stabilize for the vehicle to level out.
Do you have any ideas what can cause these issues, and potentially how to resolve them?
If any additional information is needed, please reach out.
Sorry for the delay on getting to this - it’s been slightly confused by the duplicate post, and our main ArduSub developer is currently unwell.
You seem to have solved this one already. The default PID parameters should hopefully work reasonably well for a BlueROV2, but may need tuning for custom (or heavily modified) vehicles.
I brought this up and was told it was an intentional change in ArduSub 4.1, and is unrelated to the flight controller hardware. I believe it was technically a bug that the yaw was acting in the earth frame instead of in the vehicle’s body frame (which is why it was changed), but given your description it seems like it was acting as kind of a useful proxy for roll control when heavily pitched, where roll happens to be a more useful axis to control than yaw. That should reasonably be fixed by making it easier to control roll and yaw independently, but that’s challenging with existing gamepad-style controllers.
It would be useful to have a discussion on this, since if the old behaviour is technically incorrect but happens to be relied upon and/or more useful then it’s not something that should be changed without discussion on how best to do so, and the implications.
That’s a bug, thanks for reporting it
We’ll need to wait for @williangalvani to determine the best course forwards. If we’re rolling back the earth->body yaw change then that issue may fix itself, but if we do something else then the bug will have to be dealt with properly, and Willian is best suited to either fix it or indicate where in the codebase the issue lies.
Hi @EliotBR, thanks for answering my questions in such a thorough manner. I can see the logic behind having rotations happen in regards to the body frame, and surely in some situations that would be the most intuitive way of control as well. However, in our case it makes the drone really hard to maneuver in certain operations. Having the pilots relearn how to control the drone is a rather large task, so an ideal solution for our use would be to introduce a parameter to toggle between earth and body frame.
If you decide not to roll back/make changes to the current setup I would appreciate some guidance to locate where in the code base the changes were made, and the complexity of the change so that we can create out own ardusub fork and try to implement the changes ourselves.
Hi @krisaue, we’ve been discussing this internally, and it seems like the most logical behaviour at this point is to create a parameter that allows you to select whether you want the control to be in body frame or earth frame, which should default to earth frame (since that’s the previous behaviour, and was apparently being relied upon).
I’ve raised an issue about it that you can follow for progress. We’re planning a minor ArduSub update release soon, so hopefully we’ll be able to sneak this change in within the next couple of weeks
I’m using the latest stable ArduSub firmware with a custom, 5 thruster configuration and I can confirm that the “roll static error” issue. To me, this happens both in the roll and pitch axis though. It’s just like the ROV decides that the target of the self leveling is just at an angle.
It can be reset with going to manual mode and then back to stabilize again. I’ve also noticed that the angle only “offsets” after moving the drone with the controller. It does not really happen if you let the drone stay in one spot and not move it.
Also, if you don’t mind me asking - how can I build an older version of fimware with a custom frame to get rid of this issue? I tried going back to sub-4.0 branch but the build does not seem to work for me, it errors out.
@williangalvani - as promised, I compiled your code with the modified custom configuration and tested it on the drone. It worked great! Checked for the corner cases you were talking about, didn’t notice anything wrong.
I only noticed that the roll/pitch toggle button doesn’t work. In the roll/pitch toggle mode, you can’t use the right joystick to change the roll/pitch and it also doesn’t work for controlling the forward/backward motion. But I would guess that’s probably intentional. Other than that, the issue appears to be fixed.
When will the pitch/roll control be integrated? I can test it if you need to. Thanks!
Hi!
Thanks for addressing this issue so quickly. I tried to use the navigator build you provided but I am unable to locate a parameter that lets me change control frame. @romebuster did you try this .bin-file, or only your own build?
@krisaue upload this file ardusub410beta4-togglefix.bin (1.8 MB)
in BlueOS. Then refresh the parameters and you should see a CONTROL_FRAME one. Set it to 0 for the old 4.0 behavior. The default is already 0, so you don’t really have to look at it.
Thanks, this solved our issues regarding manouvering. However, we are experiencing that the vehicle does not stay in place when switching to depth hold, but thrusts hard and dives. I have read in other forum post that this has been an issue in the past, but should be resolved now. We are doing some more testing trying to locate the error. Have you experienced this @romebuster ?
Tested this again just now and i don’t see the issue. When I switch from stabilize to depth hold, it levels at roughly the same depth it was at before switching. Same happens when I switch from manual to depth hold.
