I’m currently working on the Sphero maze and confused, I’m mazed and confused ;-). When I use the command line and publish to the /cms_vel topic, Sphero will move, but every time it hits a wall it stops and is stuck. In the this video on the The Constructs Youtube channel, https://www.youtube.com/watch?v=koN9ZqPRG_g, the Sphero bounces all over the place. I don’t understand the difference. Why does it get stuck for me? Are the simulation environments different somehow? I’ve tried different values for linear and angular speed, it still sticks to the wall.
The goal of the excercise is to detect collisions and then to move accordingly. Just moving straight will get you stuck. As a first step try adding angular velocity to see how that affects the movement.
1 Like
Thanks for the reply. I’ve added angular velocity and the result is the same. Every time Sphero hits a wall, at any speed and from any angle, it sticks to the wall. I’m just wondering if this is expected behavior or if something is wrong, because in the video I linked to above the robot behaves completely different.
1 Like
Once stuck, can you reverse the robot or move it in any way? Perhaps you can give us more information.
1 Like
Yes, by reversing it or changing the angular.z and letting it turn in place for a few seconds, then adding linear.x. But then as soon as it touches another wall it sticks.
The only other information I can think to give is that when it hits a wall and gets stuck, I can still see it spinning in place if I zoom in.
1 Like
A common source for problems is using too much velocity. Try to stick to values below 0.5. But this behavior seems normal. The challenge is to detect the collisions through IMU data, and then changing the velocities, in order to get out. Another reason for this behavior could be, that you only publish the velocity command once. Try looping it
1 Like
So I cloned the Sphero repos from BitBucket and ran them locally and it’s doing the same thing in the simulation. Guess that’s just the way it’s supposed to behave. I’ll continue banging my head on the keyboard until I figure it out. @simon.steinmann91, thanks for the replies.
1 Like
@zukethenuke @simon.steinmann91,
The “stuck to the wall” effect happens because the last message is continuously being published to the robot until another message is received.
If you publish a message with linear.x = 5 and zoom in on the robot, you would notice that it crashes then bounces back and forth, because the robot tries to keep moving according to the “last order” it got. Poor thing 
So @zukethenuke, please just go ahead with checking for collision and deciding the direction to go next. As @simon.steinmann91, you should try velocity values as small as possible so that the “bounce back” will be minimal and you can detect the crash direction more accurately.