3

I'm writing a game for sphero, the robotic ball (having issues with their forums, can't seem to ask a question). I'm trying to do ball to ball collision detection for 2 or more players.

first of all the they give a sample here: https://github.com/orbotix/Sphero-iOS-SDK/tree/master/samples/CollisionDetection

The thresholds they supply are WAY too sensitive, on a wooden floor it triggers all the time. Forgetting that for the minute, I have to use the impact timestamp from both devices to see if they have triggered collisions at roughly the same time.

My issue is when subtracting timestamps, in some cases i'm getting very wide variations and i think the difference is quite long to begin with. I'm storing several timestamps so I don't miss the correct one and I tried playing with the dead time to see if lowering it would help.

Most commonly subtracting 2 NSTimeIntervals i get a difference between 0.68 and 0.72 (I would have expected 0.01 level reactions). So Im checking if the difference is under 0.72, 3 times in a row i got between 0.72 and 0.73, several times I got 1.5, 2.6, 1.1 and even 3.8.

It doesn't seem as though its reliable. The documentation says this time comes from the iPhones reference. Both devices are synced to get time automatically, so they are as close to each other as possible.

Has anyone tried this and come up with a reliable solution, that doesn't involve keeping one ball still ?

Simon McLoughlin
  • 8,293
  • 5
  • 32
  • 56

4 Answers4

3

I did a significant amount of research on the subject of ball to ball collisions when I started as a developer for Orbotix, the makers of Sphero.

This is a very complicated problem to solve. The closest I came to making this work (for a infected zombies research game) was about 80% accuracy for detecting which ball hit which ball with a sample size of 3. The more balls you would put into the game, the lower the accuracy would become. Hence, we decided to eliminate the issue by having one ball required to stop moving before it was vulnerable, like in Sphero TAG.

There are a few factors that limit this capability, and it seems you have discovered them. I believe the biggest issue is that collision detection has poor performance while the ball is driving. Especially on a rough surface or when the ball makes quick jerky movements. This alone causes majors problems when coupled with the dead time.

I was able to get collision timestamps to within 50 ms on average. Are you taking into consideration the wifi latency in transmitting the packets between phones?

The solution is something you probably don't want to hear, but you should tweak your game play to work within the capabilities of collision detection. That is, the ball driving really slow when it can be contacted, or even come to a stop like in TAG. Ask yourself, how can I make this fun without ball to ball collisions?

Michael DePhillips
  • 167
  • 7
  • wifi latency ? from reading the documentation I understood that the impact timestamps are created by sphero, using the phones time as the reference, therefore I could ignore latency because it was a record of when the event occurred, not when the packet was received. Yes i've played sphero tag, I really didn't want to do that as i'm really not a fan of it, i guess i'll just have to scrap it. Thanks for the advice, saved me a lot of wasted time – Simon McLoughlin Mar 06 '13 at 22:25
0

I just want to say, first, that we are moving our developer support forum here, to StackOverflow, and that's why you can't post on the forums. So, you did the right thing, Simon, by coming to StackOverflow, and you should be proud.

We just changed the forums to redirect here instead of leaving people confused.

ColdSnickersBar
  • 297
  • 1
  • 5
0

The timestamps are generated by Sphero. But they only make sense is you're using the Poll Packet Times command to generate delay and offset values. Please refer to DID 00h, CID 50h in the API commands document.

That being said, collision detection is an ever evolving technology from our end. We employ a cleverly coded DFT frequency transform on a sliding data window real-time inside the robot. The parameters allow tuning to the surface you're running on; there are no universal settings. If you're obtaining too many false positives then please experiment. If you have ideas to improve the algorithm then contact us directly and maybe we can include it as a new filtering method. We're always open to clever ideas!

nalply
  • 26,770
  • 15
  • 78
  • 101
Dan Danknick
  • 61
  • 2
  • thanks for the help, but I was planning a multi ball game and realistically I don't see that working well unless there was something like NFC inside each ball. That way with 8+ balls roaming around you would have timestamps and a unique id of which ball hit you, but that would probably be out of the question to implement – Simon McLoughlin Mar 19 '13 at 16:01
0

You could sync the internal timers of each Sphero at the beginning of the game. These can be matched against a synced timer within each host phone. Clocks may be different, but a millisecond is a millisecond. You could also lower the threshold of the collision detection, thus making it so that the 'event' (damage, infection, etc.) can only occur if the 'attacking' Sphero is moving at a certain speed. Or a variation thereof.

Si-Malik
  • 49
  • 7