Plum Geek Forum

Finished putting the rover together. Demo mode works great! But in roving/light seeking mode it goes backwards. How do I fix this? What went wrong?

First thought: check the jumpers under the left wing. If you, by accident, switched the polarity, the motors will work reversed.

If the your Spirit Rover demo performs like it does in the youtube video
https://www.youtube.com/watch?v=JnGBNoFt7Ok

Then I would say the robot it wired correctly.
What I did find out is that it will go into confused mode in light seeking mode continually backing up if the surface you have the Rover on is speckled in any way. I was demoing mine to some friends on my dark brown speckled quartz counter top. It kept thinking the speckles were the edge of the surface and kept backing up.

Agree.

In my case such behaviour already occured in mode 2 at a tiled floor. Seems like the ir-line-followers are rather sensitive.
(The youTube mentions it as well: preferably a solid white surface.)

- Does the Spirit really run backwards (a couple of cm and more) or is it just a sort of shaking to the back?
- Comment out the bottom sensors in the demo script and re-upload the sketch; does it show the same behaviour?

connections were checked and fine : red to +ve / black to -ve (the wires matched the instructions); it didn't shake itself backwards, it drove backwards : "light seeking mode" became "run away from light" mode. It backed up when put on mono-colour foam board. We did get it to go forward by changing the signs in the motor calls in the preloaded demo. Still curious as to why.

Pff ….

line 258ao makes the bot turn towards the highest value revieved, but it should always move forward:
lightSeekMotorSpeed (=90) +/- lightSeekTurnStrength (=50).

Since this is producing a reversed action, I can think of some possible causes:
- Reversed polarity. Most likely, but you ruled that out.
- Software bug
- Hardware bug

The software is based on the Ringo, so I think bugs will most likely not exist anymore.
(I didn.t check the register calls in comms.ino, line 313ao though.)

To close it a bit down to either motors or ambient sensors, you might run 2 little tests with the base sketch:

Checking motor control by something like this:
motors(90,90); delay (300); DriveArc(180, 150, 0, 1000, 250); Delay(300);
(Move forward, turn +/- 180 degrees to the right, move forward, and so on)

If the bot moves backwards and there’s no inverted polarity, in my case I think could live with the fact that the motors need inversed commands.
If the bot turns to the left, I suspect the motors are probably switched while mounting somehow or they suffer from the same phenomena.

Checking the ambient sensors with a loop somewhat like this:
PIC_ReadAllAmbientSensors(); Serial.print (ambLeft); Serial.println(ambRight);delay(500);
While using a flashlight on the sensors, the values produced can be read in the serial monitor of the ide.
Like with the motors, if the values or directions are reversed, I think in my case dealed with coding inversed commands.

This is strange. Normally when we have one of our Wink/Ringo robots drive backward, it's because the polarity is reversed, or the motors are reversed.

Is it possible the connector you think is going to the left motor is actually going to the right motor? It's easy to get those wires mixed up when connecting them. Having left/right swapped would cause this problem.

-Kevin

I think the left & right motor cables must be switched: the polarity matches the pictures, so that seems the logical explanation.
To get the correct behaviour we have to switch left-right and forward back in the motor controls.
Thanks to Bastion for suggestions: they really helped figure out what was wrong.