S2's motor setting Problems
Hi all,
we all know there are two ways can make S2 move.
1. use the motor title and set motor speed and time. The robot would turn left for 90 degree
2 use the motor title and timer title. the robot would do the same movement but it didn't !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! it turn left for 135 degree. Why???
we all know there are two ways can make S2 move.
1. use the motor title and set motor speed and time. The robot would turn left for 90 degree
2 use the motor title and timer title. the robot would do the same movement but it didn't !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! it turn left for 135 degree. Why???
Comments
Welcome to the forums!
I don't know exactly why (my experience is the same) - my guess is that in moving from one tile to the next creates a slight difference in how the commands are processed. I believe you will find the S2 very consistent if you use one command method or the other. You should also be able - by trial and error - find an equivalent turn using either method and it should consistantly work.
At a particular speed, the amount of turn (in degrees) is just a matter of time - of course. You do know that in your photos - you have different times shown, don't you?
Have fun! Keep asking good questions!
Number on produces:
and the second produces:
(Twenty tenths should equal 2.0 seconds.)
There may be some overhead running the two procedures instead of one, cause some extra delay?
We will need Phil, (the author), to make us wise in the ways of s2.spin.
what you're actually invoking is a measured distance using the encoders. The time entered is multiplied by two and used as a timeout, in case the S2 gets stuck.
When you use the external timer,
the motors will run that long, regardless of how far or fast they've gone, then stop.
Both methods have their places. For accurate, repeatable distance, the internal timer is the one to use. For accurate, repeatable timing, use the external timer.
-Phil
Thanks Phil. The light bulb just went on !
-Phil
Ann - just goes to show - All questions are good questions - because it may get a something you've never thought of!
I found this prolems when I tried to teach students some traffic knowledge by S2. I ask them to turn the S2 left in 90 degree with the left LED light on.
The students have already known that robot finishing the left turn need set the motors (-50,50) for 2 seconds. Now the situation is totally different. Is there anyone could get any idea for that question?
In the first method, the parameters used are time and rate. Rate x time = distance.
In the second method, we're still using time and rate. The result should be the same distance.
The reason the distance is different, though, requires an understanding of how the GUI generates the Spin code and runs on hardware. To me, this is an engineering issue and not one to be explained to elementary school teachers.
Is there any reason we couldn't make the two methods have the same results? It would make my courses a whole lot easier
Ken Gracey
I well understand how the two might be confused. And they never were in the Scribbler I, because it lacked wheel encoders. Theyr'e not he same in the S2, though, given the additional advantages that the encoders provide.
In the first method, you're assigning an encoder-determined distance and a time deadline. IOW, "Go this far and stop. If you run out of time, stop anyway." (But normally you achieve the defined distance well before the liberal time deadline. That's why the S2 stops sooner.) In the second case, you're assigning a nominal throttle (not speed or distance) and a defined time. The S2 runs for the defined time, regardless of whether it goes the anticipated distance, rolls downhill and overshoots it, or stalls.
I can't see a way to reconcile the two without compromising one or the other. The hourglass delay applies to any operation in progress and is not coupled in any way to the motors. The only way remaining to run a calibrated distance is with the timeout provided by the motion tile coupled with the speed.
Had I not been concerned with backwards compatibility to the original Scribbler GUI, I might have replaced the stopwatch in the motion with an odometer. That would have removed any conceptual ambiguities. But at the time backwards compatibility was necessary for a smooth segue between the two robots. Perhaps this compromise can be overcome in whatever form S3 GUI takes.
-Phil
Phil, the S2 GUI is great and that's why we have something to complain about. People ask us for a BASIC Stamp 3 under the same pretense.
Can you have the GUI look for the occurrence of the first method's appearance with no time constant, check to see if there's a pause after it, and if so evaluate the two together as a speed/time motion tile when generating the Spin code?
Ken Gracey