Detecting real object collisions using QGraphicsItem collision method

[ClintEastwood]

Hello everybody,

I have to develop a system to detect collisions among real vehicles (small robots). Thus now, I only had to move them freely and I had developped a Qt GUI to move them (this GUI only sent them the commands by a network socket). Now, I also have to detect possible collisions among them (note that the collisions would be in the real world, up to now I'm not displaying any virtual representation of the vehicles in the GUI) and I was wondering if it would be a good idea to use the QGraphicsItem class to detect the collisions even if I'm not displaying them on my GUI. I have seen the mice example about collisions in the Qt documentation and I think I could use the QGraphicsItem class to help me in my internal calculations. Do you think it would be a good use of this class or would you rather look on the internet for any other special library to detect collisions?

I have to detect the collisions in path trajectories calculated before execution, not on real time! so, I do not need a powerful performance on real time, that can be relevante for the final decision.

Many thanks in advance

[stampede]

It could work ok, I'd try to use QGraphicsItemAnimation connected to a "global" QTimeLine object (shared between all items on the scene), calling QGraphicsScene::collidingItems at each animation step. Of course, this is under assumption that 2D collision detection is suitable for your problem, and you can find good 2D representations of the robot shape.
Additional benefit is that you can add a nice visualization module in few lines of code.

[ClintEastwood]

Ok, now that a person with strong Qt knowledge agrees, I feel more confortable with the idea of using qt for real world detection.
Yes, 2D collision fits in well with my problem because my vehicles' shapes are basically rectangles.
I was thinking about your suggestion to use a QGraphicsItemAnimation with a global QTimeLine and I think that will be very usefull to visualize it, but maybe not so well to obtain my main goal: to find the future collisions. I want to find those collisions as soon as possible, and then I think I would have to run the animation as fast as possible, so... would I have to set the animation duration to the lowest possible value? is it 0? And, moreover, once detected the first collision, I do not want to continue the animation to detect further collisions, so I would have to stop it, aulthough I guess that could be done easily.

If I'm wrong or you have any other suggestion I would appreciate you tell me.

[stampede]

Ok, now that a person with strong Qt knowledge agrees

Thank you, I am flattered, but I don't really consider myself a "Qt expert"

main goal: to find the future collisions

Maybe I misunderstood, but you do have all the paths precalculated, and at each point in time, you know where exactly given robot will be located, right ?
So what I meant was to take that precalculated path and convert it into a QGraphicsItemAnimation by setting each item (robot) position at each time step, with QGraphicsItemAnimation::setPosAt() method.
I don't know, maybe it is more complicated, ie. is a robot allowed to change its velocity ? Is a "path" a fixed calculation of a robot position or just a possible movement trajectory ?
Anyway in that case it should be possible to calculate few steps ahead, based on current velocities.

I would have to run the animation as fast as possible

Keep in mind that QTimeLine is not super-precise, it can update as fast as 1 animation step per msec. Accuracy of the timers depends on the OS and under some circumstances, some of the timer "ticks" will be discarded. In other words, if you set QTimeLine animation duration for 1000 ms and 50 frames you cannot assume that you will receive exactly 50 "frameChanged" signals from QTimeLine object. If you set poor granularity (like 10 ms duration for 20 frames) you can even receive just one or two frames.

[d_stranz]

Even if the robot paths aren't precalculated, you should still be able to project where they will be at some point in the very near future. For example, if they report their positions (and maybe directions, although that can be calculated from knowledge of prior moves) in discrete time intervals, then you should be able to predict where they will be at the next time step assuming they don't abruptly change speed or direction without being commanded to. So, in this case instead of using the graphics items to track where the robots are, use them also to determine if they will collide at the next time step by moving all of them there before they actually get there, looking for collisions, and commanding the robots that will collide to take evasive actions.

I don't think the G/V architecture requires a QGraphicsScene to actually be displayed somewhere for this to work. It's just a model of the world so shouldn't care if anything is displaying it or not.

[ClintEastwood]

Maybe I misunderstood, but you do have all the paths precalculated, and at each point in time, you know where exactly given robot will be located, right ?

Yes, the paths are precalculated and I just want to check if they involve future collisions.

Even if the robot paths aren't precalculated, you should still be able to project where they will be at some point in the very near future

Yes, I agree, in fact I'm already considering this possibility to check the robots on real time.

But, my question now is: If I use a QGraphicsItemAnimation to represent each vehicle's movement using a global QTimeLine, what value should be the duration of the QTimeLine? because since I want to detect the collisions as far as possible, I would like to run it very fast so I should put a very small duration, but If I have understood what stampede told me, then I may loose some intermedium interpolations due to the timer precision.

Note that If I worked with non precalculated paths, I would receive the robots' positions each 250ms (my GPS frequency rate), so then I would only have 250 ms to reproduce the new animation to detect the new collisions, so I would have to use very small duration values, and maybe in those cases I would loose again many intermedium positions and I couldn't detect the collisions properly.