Is it possible to set the vertical translational velocity to control the altitude and neglect the x and y velocity and command the desired quaternion data or body rates (roll, pitch and yaw) simultaneously using the type mask. I read some posts about it but it was not clear how to set the type masks to neglect few things. Anyone having any insight into this? Thank you.
I think that’s tricky because for position or velocity control we use a different message SET_POSITION_TARGET_LOCAL_NED than for attitude control where we use the message SET_ATTITUDE_TARGET. In theory you could be sending both messages with most fields set as ignored except the altitude in the first message and the attitude in the second. If I was you I would try that in SITL and see what happens, or alternatively look at the position controller to try to figure out how it deals with that.
What I’m reading from your question is that you basically would want to do the same as altitude control, so roll, pitch, yaw and altitude. Could you explain to me what the thought or use case behind this is? Is the problem that you don’t have GPS or flow or is the movement by velocity control to jerky?
Hello, thank you for your extensive explanation. It helped me understand more about setpoints.
So here is what I am trying to do:
I have a controller generating desired roll pitch yaw commands along with thrust in simulink. I tested to see if the commands work with set attitude using a slider (something like the rc but working in simulink).
Now whenever I try to send the desired thrust using the controller and not the slider, the quadcopter goes to a desired altitude and then drops back to the ground. It keeps on jumping. I tried to tune the gains but have no luck. The thrust profile is too noisy it seems.
@arg1885 Are you testing this in SITL?
No I was testing it on the actual hardware platform.
So I’m assuming you were implementing a controller to control altitude, right? What data were you using for the altitude estimate? And what sort of controller is it? And do you have an estimate of the lag of the controller, e.g. how fast can you react? I would think that if the controller is tuned well and has little lag and is based on a sensor that makes sense, this should work.
I am using the vicon data to get the position estimates. I am running the controller at 20Hz. Rostopic hz /desired_thrust shows 20 hz
@arg1885 Have you tested your controller in SITL? I think it would make your development much faster if you test your controller first in SITL and make sure it is actually working.
I tested it in a simulation. It works fine.
@arg1885 So, also with the thrust scaling it works in simulation?
Yes it works in the simulation. The commanded thrust is too noisy in actual hardware implementation.
@arg1885 If it is too noisy, you might need to look into where the noise is coming from. It might be that your velocity estimate is noisy causing the thrust to be noisy.
From my experience, the commanded thrust itself should not have too much uncertainty. Can you check if the noisy thrust commands are actually coming from the controller? or the controller is smooth but the output thrust has noise?
So I have a nominal thrust value + the output of the controller which is noisy. Hence the entire thrust output becomes noisy. I will check if the PID block has any issues.
@arg1885 I think that would be a good start in identifying the problem. The thrust commands are not usually too noisy to stop you from being able to fly.
For your question on attitude + altitude setpoints, you can look at the progress in this PR which seems stale
You were right about the velocity estimates. I solved the problem. Now I am able to perform an altitude hold task. Last step remains is tuning the controller gains to compute the desired quaternions. Thank you all for your help.