Left Wheel

Right, repetitive iterative testing sort of completed on the left wheel, although I do have some questions need answering about it.

Here is the data:

13, 752, 0.20
13, 746, 0.15
13, 753, 0.25
13, 745, 0.2
13, 754, 0.33
13, 744, 0.30
13, 755, 0.45
13, 743, 0.40
13, 756, 0.55
13, 742, 0.55
13, 757, 0.66
13, 741, 0.66
13, 758, 0.75
13, 740, 0.75
13, 759, 0.91
13, 739, 0.91
13, 760, 1.03
13, 738, 1.03
13, 765, 1.6
13, 733, 1.6
13, 770, 2.25
13, 728, 2.25
13, 775, 2.75
13, 723, 2.75
13, 780, 3.25
13, 718, 3.25
13, 785, 3.6
13, 713, 3.6
13, 790, 3.9
13, 790, 3.85
13, 790, 3.9
13, 790, 3.85
13, 708, 3.75
13, 795, 4.1
13, 703, 4.05
13, 800, 4.25
13, 698, 4.2
13, 805, 4.25
13, 693, 4.25
13, 810, 4.3
13, 688, 4.3
13, 820, 4.3
13, 683, 4.3

There is a slight difference in the way this servo reverses direction. It goes further forwards than it does in reverse. In order to get the same distance backwards as well as forwards in the file TestServoSpeed.bs2, it was necessary to change the value of the counter variable from 244 x 2 microseconds to 238 x 2 microseconds, a difference of 12 microseconds.

If you think back to the previous post about the right wheel, the top speed that servo seemed capable of was 47.5 rpm.


As you can see, the top speed the left servo appears capable of is around 43 rpm, which is pretty significant really. Its enough to make a difference in dead reckoning navigation anyway.


Given that I tested the right wheel with absolutely fresh batteries and that I'm testing the left wheel with the same batteries as I used for the right wheel, I initially thought the difference may be down to the batteries not putting out as much power for the left wheel as for the right.


That seems to have some effect, but it isn't the whole answer. I tested the right wheel with a pulse width of both 820 and 679, which in the previous test were widths which managed to achieve the top speed of 4.75 and in this battery of tests, those widths only gave the wheel an rpm of 46. So, while the freshness of the battery may have had some effect, it isn't as pronounced as 4 rpm.


I wonder if there is a way to tune servos?

Right Wheel Calibration

I'm thinking if someone happens to just stumble across this blog and start reading it without any knowledge of the subject, they would look at this post and think I was possibly the most boring person allowed to post content on the internet.

If you have found yourself in that situation, then I apologise, this isn't going to be the most entertaining post in the world. Interesting and useful if you have a bent towards the topic I'm writing about, but otherwise, you might want to back away.

In my previous post, I noted the difference fresh batteries made to the overall speed of the robot, adding 5cm/s after changing them. thatsmore than a 25% improvement on the original score, so I thought it might be best to repeat my iterative wheel speed tests in order to be able to precisely control not just the distance, but the velocity at which the robot covers said distance.

As I said in a previous post, sending the servos a pulse train with an up width of 1.5 milliseconds, the servo takes that as an instruction to do nothing.

Finding out exactly what width of signal the servo will begin turning, can only be a useful thing, and knowing the way the speed of the rotation increases as pulse width changes both above and below that magic figure of 1500 microseconds is equally useful.

So, some boring, but necessary testing followed, with the results as follows. For the sake of my sanity, I wont be converting the PBASIC PULSOUT command syntax to microseconds, since I plan to do that in an excel file at some point. For those interested, the code used to perform this testing follows:

' {$STAMP BS2}
' {$PBASIC 2.5}

counter VAR Word
pulseWidth VAR Word
pulseWidthComp VAR Word

FREQOUT 4, 125, 3000, 4000

DO
  DEBUG "Enter pulse width: "

  DEBUGIN DEC pulseWidth

  pulseWidthComp = 1500 - pulseWidth

  FOR counter = 1 TO 244
    PULSOUT 12, pulseWidth
    'PULSOUT 13, pulseWidthComp
    PAUSE 20
  NEXT

LOOP

Again, I can't take credit for that code, although I have made my own refinements to part of it.

Looking at the interesting part of the code, within the FOR...NEXT loop there is a statement PULSOUT 12, pulseWidth.

that variable, pulseWidth is set by the DEBUGIN command, which simply allows me to enter the width I want each loop of the code. Since each loop takes six seconds, once I have done this testing, the mathematics involved in telling the robot to cover a specific distance at a specific speed are simplicity itself. 

In any case, the command PULSOUT 12, 750 is telling the servos to stay still. To calculate how many microseconds that is, is simply a matter of multiplying it by 2 microseconds. That sounds complicated, but in reality, isnt.

750 x 2μ

= 750 x 0.000002 s

= 0.0015 s

= 1.5 ms

In any case, interesting results did come from the laboriousness.

At a pulse width of 752, the wheel started travelling backwards very slowly indeed. Looked at linearly, it probably moved less than a centimentre and did it in a stop-start jerky fashion. Because of that, the first "real" movement in a rearwards direction starts at a pulse width of 753.

The first forwards movement starts at a width of 747.

In order to get exactly one complete turn of the wheel, no more, no less, going forward, requires a pulse width of 740. To go backwards, 759.

Top speed turned out to be around 4.75 turns every 6 seconds, in both directions. There were occasional flashes of a higher speed, including one occasion when the wheel came within a centimetre of completing 5 turns, but repeated testing at that pulse width showed that must have been a fluke of some sort. The data follows, in a not particularly elegant manner.

pin 12 = right
pin 13 = left

12, 755, 0.40
12, 745, 0.37
12, 760, 1.1
12, 740, 1   <-------one complete turn
12, 759, 1   <-------one complete turn

12, 750 - 0
12, 753 - SLOWEST BACKWARDS
12, 747 - SLOWEST FORWARDS

12, 765, 1.75
12, 735, 1.66
12, 734, 1.75
12, 770, 2.45
12, 730, 2.25
12, 729, 2.4
12, 775, 3.05
12, 774, 2.95
12, 724, 3.0
12, 780, 3.5
12, 719, 3.5
12, 785, 3.9
12, 714, 3.9
12, 790, 4.2
12, 709, 4.2
12, 795, 4.4
12, 704, 4.4
12, 800, 4.5
12, 699, 4.5
12, 810, 4.6
12, 689, 4.6
12, 820, 4.75<----peak backwards speed
12, 679, 4.75<----peak forward speed
12, 830, 4.75
12, 669, 4.75
12, 840, 4.75+
12, 659, 4.75
12, 850, 4.75
12, 649, 4.75
12, 870, 4.9
12, 629, 4.75
12, 885, 4.85
12, 614, 4.75
12, 900, 4.85
12, 950, 4.85
12, 870, 4.85
12, 870, 4.75

Again, I need to repeat this with the other wheel. Oh joy.

Establishing and discovering performance

Ok, so I managed to get the base build of the bot completed a couple of days ago. Since then, I've been doing a fair bit of tinkering with it and repetitive testing of what it can do.

Found a couple of interesting results.

With my cheap, £1.99 for 20 AA batteries, the bot was managing to move at around 21cm/s with brand new fresh batteries.

While I'm reasonably happy with that, I'm a little disappointed that I have to repeat a lot of iterative testing. The reason I have to repeat it is because to do the testing, I used the same batteries I used to build and sub-system test the robot, and when I did a speed test of the robot, it managed to achieve a magnificent 16cm/s. 5cm/s is a lot to lose, so I'll bang on with that iterative testing again and get it resolved.