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.