-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zigzags in flight path in QGroundControl (Plane teleports) #22
Comments
Two questions:
|
@slimonslimon The frame rate swings from 50 to 100 FPS.
|
You have multiple occurrences of following lines in the console output:
It seems there is trouble with the FlightGear frame rate. Are you able to check the frame rate of FG itself by enabling the FPS display? In cases where FG FPS drops, the "teleportation" will probably occur. |
@kaklik I did obtain the frame rate of FG through FPS display you mentioned. Do you know what caused the |
The bridge internally counts how often comes messages from the FG. It can be caused by "some interference" of Frequency of internal pooling loop of bridge: https://github.com/ThunderFly-aerospace/PX4-FlightGear-Bridge/blob/master/src/flightgear_bridge.cpp#L145 and frequency of FlightGear main loop (somehow connected with FG FPS - FG is single thread). To proof this hypothesis, you can change frequency of bridge here: https://github.com/ThunderFly-aerospace/PX4-FlightGear-Bridge/blob/master/src/flightgear_bridge.cpp#L98 |
But problems can be at more places and they are hard to reproduce or debug. Then the bridge should pool for messages from FG very often and only resend message to PX4. (I hope that it will be working) The last think what you can set up better is requested frequency of messages from FlightGear - now it is set to 100 Hz. But FG is single thread aplication, so real Frequency of messages will be somehow connected with FPS - it will not be large than FPS. So if you request 1000 messages per second, It will be sending message every frame. Thank you for your time that you spend with testing these things. |
@slimonslimon Thank you for your input and apologize for late reply. I will look into this further as soon as I can. |
I think this points to the fact that we need lockstep for flightgear |
@Jaeyoung-Lim Agreed! Lockstep also makes debugging models much easier. |
@Jaeyoung-Lim @lum-supakorn - It could be very cool - but there are 2 main problems:
|
@slimonslimon Right, but just pointing out that this part of SITL will never be reliable without it. If we are not able to support it, the least we should do is provide strict performance requirements on hardware to run the simulation. |
@Jaeyoung-Lim Does JSBSim not support something similar to lockstep? |
JSBSim does, but the flight gear interfaced used in this repo does not |
@Jaeyoung-Lim @lum-supakorn I suggest continuing at the discussion about the lock-step option in different issue: #8 Where I also commented on the actual possibilities. |
@lum-supakorn are you able to test modifications that were mentioned above? (Because exactly I have not hardware which has higher FPS than about 50 Hz) |
well, after long time I have improved gyroscope readouts which may solve this issue. |
Steps to reproduce:
make px4_sitl_nolockstep flightgear_rascal-electric
ormake px4_sitl_nolockstep flightgear_rascal
From time to time the plane in QGroundControl will teleport and the flight path will be drawn as shown in the figure below:
Note that the plane in FlightGear does not teleport, so I assume that the issue comes from PX4 FlightGear bridge.
The text was updated successfully, but these errors were encountered: