I am running the HITL mode on jMAVSim using a Pixhawk 1. I am working on using offboard mode to control the velocity. I was testing just sending vx = 5, vy =0 and vz =0. The X and Y positions act how I expect them to, but the Z position fluctuates. The fluctuation is usually around ~5m. You can see the local_position_ned.z from the analyze widget.
This happens in hold mode, altitude mode and offboard mode (it only happens if I set z=0 in offboard mode).
How do I stop the fluctuation? Could it be the weight or some kind of wind parameter causing it? Is it normal?
Since you’re doing that in HITL, you could easily try to tune the altitude loop a bit and see if it makes a difference. The params would be https://dev.px4.io/en/advanced/parameter_reference.html#MPC_Z_VEL_P (and other
Thank you for the suggestion! However, I tried to use PID tuning but it seemed to not make much difference.
Plus, the velocity Z set point changes (even though I am sending Vz=0 in offboard mode constantly and the position is staying the same). You can see it in the photo but here is the link if you like: https://review.px4.io/plot_app?log=3e8a8989-76cf-4046-bfc4-f52b38462407 .
I also tried changing the weight of the drone but that seems to not make a difference either.
Hm, and you don’t see this in SITL I assume?
Does this still happen if you lower the integral (I) gain of altitude and try to increase the proportional §?
Right now I cant run it in SITL but I will try your suggestions.
Are you using the correct cygwin console?
I’m not sure about that. How do I check that?
Oh yes, I am! I did follow this earlier. I am still following it.
Strange, maybe @MaEtUgR can help…
I also just realised that most of my flights have this error, if that could cause such a problem. I don’t know how I missed the error though.
Sorry for any delay in answering.
the Z position fluctuates
I presume you also played with this parameter: https://dev.px4.io/en/advanced/parameter_reference.html#MPC_Z_P
For parameter tuning you might want to try using these values: https://github.com/PX4/Firmware/blob/dc50a564ddf9444dc7cb63114db429404971520b/ROMFS/px4fmu_common/init.d-posix/rcS#L130-L132 they are used for SITL and work acceptable in jMAVsim.
Does the HITL simulation work responsive in X, Y direction or could it be some kind of delay somewhere in the system? Do you have a fast computer or might it be at the limit? Usually HITL runs more responsive for me than SITL even.
Right now I cant run it in SITL
Read https://dev.px4.io/en/setup/dev_env_windows_cygwin.html#windows-crlf-vs-unix-lf-line-endings first.
The error clearly looks like you edited the file sitl_run.sh and saved it using a windows specific editor that switches every new line in the file to CR LF instead of just LF. Cygwin needs to have the files with unix style line feeds to work correctly. More info: https://stackoverflow.com/questions/1552749/difference-between-cr-lf-lf-and-cr-line-break-types
Use e.g. Notepad++ or Visual Studio Code to switch the line endings.
If you didn’t edit anything and still have the problem you might have setup git for windows to check out the files in CR LF style. In this case either reconfigure your windows git (it asked you all this stuff during installation and I wrote commands in the cygwin docs linked above) or just use the git within Cygwin for this project.
most of my flights have this error
That is an error which can happen in SITL especially if performance is an issue or you run the simulation for a long time. Are you using the latest PX4 master? Because since lockstep (improved simulation timing when some relatime deadlines are missed) was introduced by @JulianOes these problems vanished for me.
Thank you for the reply!
I will try to tune the parameters again soon, after editing the sitl_run file.
I am using the latest PX4 master, I updated it recently and it still gave the same error, but I will check again.
I am sending velocity data in the offboard mavlink message, so the X and Y velocity setpoints follow exactly what I am sending. The estimated values of X and Y follow these setpoints closely.
The Z velocity is the only one that does not follow what I am sending it. The Z velocity setpoint fluctuates (in the graph jMAVSim drone Local_position Z fluctuating) which makes the estimated z values go up and down too. I don’t think this could be caused by the computer being too slow, since X and Y are fine.
I may try and see if I can test it on a faster computer though, if possible, to rule that out.
Maybe as an additional reference of possible values, I use the HITL jMAVSim with these vehicle customized values:
param set MPC_Z_VEL_P 0.25
param set MPC_Z_P 0.85
param set MPC_Z_VEL_D 0.0
param set MPC_Z_VEL_I 0.085
These are of course tuned for the real drone and not HITL but it looks fine in simulation. I didn’t check the logs in detail though. Are the high tracking errors already visible in the simulation’s drone state visualization (without graph)?
Yes, I can see the drone moving up and down quite clearly.