I add here 2 pictures of QGControl parameters list where I have this issue with parameter displayed in red instead of white, probably indicating some error but there is no explanation nowhereā¦
@Jaeyoung-Lim @admins I donāt get any answers from you guys, Iām still struggling with my problem and I canāt find any resources to deal with it.
Can you have a look at that ? As a main feature the Collision Prevention System should be working and having a clear procedure to check for it in case of failureā¦
Thanks
The red color of parameters mean, it is change from default value.
The initial version of my PX4 Vision was v1.11.0b, and with that version, the Collision Prevention was operated in Position mode.
However, today I updated the version of PX4 Vision to the latest version (v1.12.3 Stable) and confirmed that the Collision Prevention function did not work.
Iām checking to see if itās a PX4 parameter setting problem, but I havenāt been able to solve it yet.
1 Like
Ok thanks for these precision.
So it should work if I go back to v1.11.0b, but in that case I had an issue with the calibration of the motors: QGControl kept asking me about the calibration (unplugging the drone, plug the battery in, replug the drone and the calibration should be done) even though I made it.
If you have more info about this issue Iām interested and Iāll wait for your update regarding the PX4Vision compatibility.
Thanks
@VincentD Thanks for the detailed report. Note that the collision prevention feature does not yet support acceleration setpoints while the new default implementation of position mode uses these. You can revert back to using the previous implementation also on the newest PX4 version by setting the parameter MPC_POS_MODE to 3 (instead of the new default 4). See Parameter Reference | PX4 User Guide. That will revert how stick input is mapped to motion to the old implementation that supports collision prevention.
2 Likes
Oooh thatās a great news ! Iāll try this today and let you know how it went.
As a general remark: this kind of issue should be precised in the documentation for example. I lost a ton of time on this matter 
Thanks for your help !
1 Like
@MaEtUgR I just tested a flight with the new parameter and I got a weird behaviour in Position Mode.
It seems that the Collision Prevention does work but in Position Mode I lost control on Roll and had a partial control on Pitchā¦
I recalibrated my remote controller, tested in Stabilized Mode and everything worked well. But as soon as I switched to Position Mode, I lost control on Roll, and Pitch was really bad.
Are there other parameter I should change to get along with MPC_POS_MODE ?
Thanks
It seems that the Collision Prevention does work
@VincentD Cool that you could test it that quickly, happy that information was useful. Yes youāre right we should definitely add this to the docs.
I switched to Position Mode, I lost control on Roll, and Pitch was really bad.
I wouldnāt know why. Is there a general issue. Is this only with collision prevention? Does this also happen in a normal simulation flight? If not could you share a ulog file uploaded to https://logs.px4.io/ of when it happened such that I can analyze what could be the issue?
It seems that the Collision Prevention does work but in Position Mode I lost control on Roll and had a partial control on Pitchā¦
@VincentD Could you check if CP_GO_NO_DATA is enabled?
If this is disabled, it will prevent you from flying outside of the FOV of the depth camera
Actually itās the opposite, CP_GO_NO_DATA is disabled by default so it already prevents from going outside of the FOV of the camera.
If I enable it I will be able to fly outside the FOV, so the test this morning was with this feature activated (canāt go outside FOV).
@Jaeyoung-Lim @MaEtUgR I just come back from complementary tests and here is what I noticed:
- As stated with
MPC_POS_MODEin default mode (4) Collision Prevention doesnāt work - With
MPC_POS_MODEin mode (3) with no other modification, Collision Prevention works but reduce almost totally any other movements than going forward slowly (no Pitch at all). - With
CP_GO_NO_DATAenabled (putting on 1 instead of 0 by default), I get the Pitch and Roll control back.
So basically it only works with MPC_POS_MODE in mode (3) and CP_GO_NO_DATA enabled (different from 0).
Knowing this now seems logic as the CP_GO_NO_DATA parameter by default prevents from moving outside the FOV, and pitching in front of an obstacle is by definition moving outside FOV hence the lock on Pitch control I guess.
Enabling it kills this behaviour and give back the full control.
I also noticed some decrease in the precision of the movement in this MPC_POS_MODE (3), like more vibration and an increased āinertiaā. I will re-test in better conditions to confirm that because I had some wind today.
Do you know if updates on that matter are planned ?
Thank you very much for your help !
1 Like
Thank you very much for the answer.
I was also struggling with this issue in SITL for over a week, now it works by setting MPC_POS_MODE to 0 or 3.
1 Like
@VincentD @s.khatiri Not a proper fix, but I have set the defaults to what appears to work for the px4vision for now: Fix px4vision defaults by Jaeyoung-Lim Ā· Pull Request #18504 Ā· PX4/PX4-Autopilot Ā· GitHub
1 Like
Thanks @Jinhyeong-Lee for this udpate on the Github, it will be helpful for people.
Be careful, itās MPC_POS_MODE=4 which is a problem not MPC_POS_MODE=3, you should correct it on Github.
Thanks again ! If any proper fix is done, please update this thread for everyone.
Be careful, itās
MPC_POS_MODE=4which is a problem notMPC_POS_MODE=3, you should correct it on Github.
@VincentD Could you elaborate what you mean? I have set the MPC_POSE_MODE to 3. Is this not correct?
Sorry if it wasnāt clear.
In your Github post you mentioned that the problem came from MPC_POS_MODE=3 but itās actually coming from MPC_POS_MODE=4, but I just saw you edited the post and itās now correct so all good !