Update supervision with better file handling#315
Conversation
… one HEAB to arrive
|
@LukasWikander Do we know why it can not handle receiving MONR faster then every 10 ms? Checking every 10 ms sounds fast enough, but would it not be ideal to at least know how to adress this if necessecary? |
alfaro01
left a comment
There was a problem hiding this comment.
It's a big review so I skimmed the code but it looks good.
About the update-frequency issue I wonder the same as @konglobemeralt, do we know what's the cause?
I think that geofences should be classed as a safety feature and if something can break it by just sending the position a bit too fast, it's a major issue.
|
The problem is that due to the shared memory we check MONR only once every X ms. So if MONR arrives faster than that we may miss one or two. The solution would involve somehow synchronising Supervision with the arrival of MONR so that it MUST check each and every one. How to do this is another matter... @alfaro01, @konglobemeralt please leave either an approving review or request changes. I will not merge either way until this discussion has been settled. |
|
Conclusion: the vehicle must be outside of the geofence for at least 0.01 s for it to be considered as a violation. |
|
I have updated the script to reflect this. Re-review necessary. |
konglobemeralt
left a comment
There was a problem hiding this comment.
I had forgotten about this PR. But all in all I think my points have been addressed.
Would like a discussion here. As part of the test I had the "object" report MONR at a random interval between 1 ms and 7 ms because I was curious if we could get away with breaking a geofence if we reported position often enough. It seems like we do - should we do anything about it?
Everything works as expected if we just report MONR with regular 10 ms intervals.
Also, the code needs a review.