Motor Test Station (MTS)

Mark was right, torque of 0.00071Nm was good enough for (to me) impressive 9.89m/s or 35.6km/h in motor test station, but may not be enough for autonomous robot (I just ordered 2 motors with 0.0055Nm, a factor of 7.7).

Yesterday I did quite some work on real autonomous robot, these are the tops of two linked tweet sequences:

This is new robot jacked for initial wiring testing with bitlash (allows interactive as well as scripted programming w/o Arduino IDE):

I did first full speed test run last night:

Compared to Asuro robot 8 years ago (0.43m/s, 1.2m/s, 1.8m/s) it was quick (3.1m/s or 11.16km/h).
But previous runs (same motors and wheels) in Motor Test Station showed 9.89m/s.

Copying in youtube description with the details:

This is first autonomous full speed run of new Arduino robot (3.1m/s or 11.16km/h).

Weight of robot is 96g, and the three LiPos were not fully loaded, but showed 11.41V, the motor is 12V motor.

Although pin 13 LED starts to blink when reaching leg of grand piano (indicating that motor has stopped) the kitchen door did a hard stop on the robot. analysis (7.95s-8.55s) shows that robot did pass 6 floor tiles with edge length 31cm. The speed in that time frame was therefore 1.86/0.6=3.1m/s or 11.16km/h.

This is far less than the 9.89m/s seen in motor test station (robot there had 73g weight with same motors and wheels, but no ground friction of half table tennis ball). For details see:


If I was making that contraption, I'd have the motor stationary and the disk turning.

I'd mount the disk ( or use an old LP records ) above the wheel, so the wheel turns it from underneath. And then measure how fast the disk is spinning.

If I was making that contraption, I'd have the motor stationary and the disk turning.

I cannot agree here, it is always better to measure "the real thing" if possible.

Measuring the real thing sometimes gives surprises (like the 9.89m/s to 3.10m/s drop from MTS to autonomous robot with same motors/wheels).

I was quite active this evening, after exploding a L293D by accidently reverse powering, then an MTS Arduino robot accident at >30km/h where the safety glass proved to be a good idea, and finally a new record run with new 14.8V motor (data sheet in this posting, translation of German data sheet terms in this posting) -- 12.3m/s or 44.28km/h(!).

Record run youtube video details:

15.26V at start, no accident this time, new speed record. frame-by-frame analysis: 4 rounds in 0.4s (24.48-24.88) gives 10.0rps or 600.0rpm. A round with this new wooden stick is 1.23m. Speed is therefore 12.30m/s or 44.28km/h. Diameter of wheel is 2cm,. With 12.30m/s this is 195.7rps or 11745.6rpm at motor shaft. |500x345

"robot" weight is 100g: |500x375


Hi, analysis (7.95s-8.55s) shows that robot did pass 6 floor tiles with edge length 31cm. The speed in that time frame was therefore 1.86/0.6=3.1m/s or 11.16km/h.

This is far less than the 9.89m/s seen in motor test station

When you are using the test jig, the mass that the motor is driving "forward" is less than the mass of the controller and battery because of its position near the pivot point. In your robot the motor is now accelerating the full mass. You are trying to get load /speed figures from circular motion and use them in linear motion. You can use your setup to compare motor characteristics.

Tom.... :) PS If I had realized way back in this thread what you wanted to do, I'd have advised putting the controller and batteries as close to the motor as possible, so the motor sees the full load of the mass, but figures you obtain would be inaccurate due to circular and linear motion.

Thank you Tom for your explanations. They totally make sense and explain what I experienced.

The next steps will be to do test runs with arduino and L293D board as well as LiPos sitting directly on top of the motors far off the pivot point.

But before doing those tests I did quite some stuff with followup questions.

The first thing was to get rid of "store youtube video, single step through it via and count rounds and hundreths of seconds that takes" for speed determination. I did that with this Infrared Speed Sensor Module:

First I had some problems with too many interrupts generated, but I found (a) solution to that myself in "Accuracy of MOCH22A based Infrared Speed Sensor Module" thread:

I used an Arduino Uno screwed on MTS and connected to my Laptop for doing the measurements: |500x375

First I did let interrupt service routine (ISR) directly write millis() and count to Serial because I tested such an operation taking roughly a hundreth second and my measurements are expected to be in low 2-digit number range of interrupts per second. Later, in order to avoid timing problems, I just did "A[cnt++]=millis()" in ISR and called a service function printing out the whole array after test completed (I did all using bitlash command shell).

The first run I did was successful but did not reach >40km/h speed I expected: |500x286

Checking everything I found the easy explanation, I did only use 3 LiPos giving >12V for the 15V motor:

The second run was successful as well and did show 42.17km/h, with a minimum of 105ms per 1.23m round for the wheels: |500x253

The 0 measurements are just some double interrupts at same millisecond, and the one delta measurement of 212ms at 107th interrupt was just a missing interrupt while brazen piece moved through the sensor.

All measurements I did were done with the 20mm 1-piece Lego wheels I used until now and the 15V motor. I did find some bigger wheels in the big Lego box from my kids (they are too old to play with it anymore). I was interested in 24mm and 30 mm.

The first run with 24mm diameter wheel+rubber was stopped hard by infrared speed sensor after few seconds:

I tried to fix the mechanical problem of getting brassed piece into middle of sensor: |500x375

For me the next video is a "must see" and it proves that my attempts to fix the physical issue were not good enough -- complete destruction, speed sensor, lost wheel, cables, ..., not stopping before the end of the video:

For the runs with 24mm diameter I had to use new motor controller board because the previous one could not deal well with the vibrations in new setup. This time I did connect both motor output to the two motors. The layout allows to use Arduino Nano as well as Arduino Pro Mini interchangably on the (not drawn) IC socket: |500x381

Here you can the the new and the old board I used: |500x375

In the next runs I saw speeds of much less than 40km/h and charts with different form, especially the missing long minimum at the middle: |500x264

Finally I found the issue, it was the unbalance of the rubber(!) which I found while diagnosing with bitlash and connected with laptop. This photo was taken with PWM=180 and clearly shows that the "flying" rubber is the issue: |500x375

I did fix that as I fix most things (like connecting infrared speed sensor at the needed height of 9V block battery) -- with superglue ;-)

The next run did loose a wheel again, fixed that with some superglue on motor shaft as I did previously with the other wheel:

I did several runs then, all showing same behavior, this is the last one: |500x237

So here are my questions: 1) I have no explanation on the few peaks >800ms delta. What could be a reason that sensor does not trigger for several rounds? [In this posting I have shown that the sensor can easily generate 93.4 interrupts per second, and here we are talking on rougly 10 interrupts per second]

2) What can be an explanation on the 24mm diameter charts not showing the long minimum the first two 20mm diameter charts above do show? [Its the same motor and LiPos, just bigger wheels]


Hi, Hermann, mate. If I produced graphs like that at uni I would have been shot. Please name your axes and units, what are you graphs of?

Tom.... :) Sorry but they don't mean anything to me.

Ok, ok, vertical axis is milliseconds between two successive interrupt triggers, horizontal axis is just interrupt count. As said "A[cnt++]=millis()" executed by Interrupt Service Routine just stores milliseconds after Asuro Uno boot into an array, one entry for each.

The brassed piece going through infrared speed sensor forks is 1cm wide. Given a speed of 12m/s and ignoring the minimal difference of straight line and arc on brasssed piece that goes radially through center of sensor in forks gives 1/1200s = 0.83ms time the sensor can trigger. Not sure if that can be a reason.

In Sensor forum posting I did describe a technique to eliminate jitter if using digital infrared speed sensor pin instead of analog one:

I did now do some runs with that technique (setting dt to 50 [micro seconds]) and immediately all double interrupt triggers at same millisecond went away, no y=0 entries anymore. For final run I did fully load all 4 LiPos giving 16.41V, still seeing the strange figures (the highest peak was even >4000). The curve (now zoomed into range 100ms-200ms per round) perhaps indicates that wheels loose contact between 43rd and 97th interrupt, at least a bit: |500x265

Without slow motion camera I don't have even different perspective and quarter speed does not show details: [

Hermann. ](

The "use digital pin with jitter suppression" of infrared speed sensor did remove the "0" delta entries in previous charts.

My previous comment suspect that 0.83msec of brassed piece might be too short time for triggering infrared speed sensor interrupt was correct ! I did increase the time by a factor of 2.5 in attaching a 2.5cm brassed piece tangential on to of the existing piece (again with superglue): |500x375

Here you can see that chart curve looks good now, no spikes anymore! And this is first time measured new speed record of 13.6m/s or 48.9km/h: (with axis labels as requested by Tom) |500x392

The last open question is why high speed only happens from 69th til 76th interrupt (less than a second in total), then goes up to 116 (117th interrupt) and then down to 108 again -- maybe that is a sign that wheel cannot keep road contact the whole time?

63  97
64  96
65  95
66  95
67  93
68  95
69  92
70  93
71  93
72  92
73  94
74  92
75  93
76  92
77  93
78  94
79  95
80  94
81  94
82  95
83  97
84  96
85  97
86  98
87  98
88  99
89  99
90  101
91  100
92  102
93  103
94  103
95  104
96  104
97  105
98  106
99  107
100 106
101 108
102 107
103 108
104 109
105 110
106 110
107 111
108 112
109 111
110 113
111 112
112 114
113 114
114 113
115 116
116 115
117 116
118 113
119 113
120 111
121 110
122 110
123 108
124 110
125 108
126 109


Speed in m/s seems more intuitive for y-axis, curve based on same measurment as before:

This is relevant part of program controlling the robot motors:

  for(i=20; i<=255; ++i) {
    analogWrite(3, i);
    analogWrite(9, i);

  for(--i; i>20; --i) {
    analogWrite(3, i);
    analogWrite(9, i);

  analogWrite(3, 0);
  analogWrite(9, 0);


Last posting was done some time ago, and Motor Test Station (MTS) was not functional.

But I bought two new motors with 3.7 times the torque of the motor that did 14.37m/s or 51.7km/h. And I wanted to know what those motors can show in MTS (motor specs at bottom).

I have killed all my Nanos and Pro Minis, but did not want to wait for delivery. So this time I used an Arduino Uno on the robot. Instead of the L293D motor controller I did use two IRF520 MOSFET modules. |500x375

After several runs the robot showed 15.95m/s or 57.43km/h with 30mm diameter wheels. Because rpm at motor shaft was only 10155 I knew that smaller diameter would beat that.

Then I did run with 24mm diameter wheels and got 16.96m/s or 61.06km/h or 37.95mph ! Here is the youtube video and here are the evaluation details and time/speed graph: |500x343

I could not use the old part of the robot that goes though infrared speed sensor, with those high speed vibrations produced hits of the infrared speed sensor reducing speed. This new construction helped to eliminate the problems: |375x500

This is the 38mph phase of above youtube video:

The program turns ON pin13 LED for 5 seconds, and it remains ON during that time. Why does pin13 LED not show as a full circle (caused by slow Android camera) like the two (outer) MOSFET module LEDs and the (inner) Uno power LED? I have no explanation for that.


P.S: These are the motors I have tested sofar in MTS (reported in this thread) and maximal speeds: |236x500

The new run in MTS I want to talk about today was not for achieving new records (although record improved slightly).

It was to find out how long 4 fully loaded 160mAh 25C Lipos (4.13+4.14+4.19+4.20=16.66V) can make 147g Arduino robot run on its radial course.

The main part of the video besides start and end is not that interesting (robot runs and runs and runs), but is proof that this is no fake.

In total the robot did 3450 rounds of 1.34m which is 4623m in total(!), and that in 5:26min wich is 14.17m/s (more than 51km/h or 31mph) on average.:

30723   0
31268   1       545     2.46
357018  3450    644     2.08

3450*1.34 = 4623.00 m
3450*1.34/(357.018-30.723) = 14.17 m/s
(357.018-30.723) = 326.295 s

The high speed part from reaching 17.18m/s the first time to just before going below 14m/s the first time lasted 4 minutes with 15.82m/s on average:

40927	94	78	17.18
279354	2909	95	14.11

(2909-94)*1.34 = 3772.10 m
(2909-94)*1.34/(279.354-40.927) = 15.82 m/s
(279.354-40.927) = 238.427 s

Evaluation details and time/speed graph can be found here:

The robot stopped with still 1.35+2.94+3.55+2.97 = 10.81V left. As you can hear in the video Uno gets reset (an initial pause of 1 second from sketch and then you can hear the motors) again and again. While 10.81V is definitely enough to power the Uno on the robot, the two motors take too much away for the Uno to work.

At the bottom you can find the sketch (based on this posting) I used on the 2nd Uno (outside of MTS) connected with the infrared speed sensor and doing the interrupt measurements. The recording was restricted to 300 unsigned short values for interrupt timestamps (because of 2KB ram size of Uno). Using unsigned short gives an overflow each 65 seconds. What is worse for the current run is that interrupts occur every 80 milliseconds. The 300 values would be filled after 24 seconds already, not good for a long run.

So for this run I replaced the 2nd Uno with an Arduino Due and this little code change:

$ diff userfunctions2.ino ../userfunctions2due/userfunctions2due.ino 
< unsigned short A[300];
> unsigned long A[20000];

The miilliseconds get recorded correctly [with overflow after 49 days :wink: ]. And 20000 values allow for more than 26 minutes recording with 80ms between interrupts.

The sketch is based on bitlash which is cool for all Arduinos besides Due, because it has some bugs for Due only and they have not been fixed in the last years. Luckily below sketch is not affected by any of the existing bugs.

The 80KB of memory for the recording array is no problem for Due’s 96KB ram. Why an array for recording and not directly writing out over serial? I don’t want to miss interrupts. The interactive bitlash commands added to bitlash are “re” for resetting the measurements, “ra” for reading how many measurements were done, and “sz” for printing out the whole array with value and index per line.


#include "bitlash.h"

unsigned short A[300];
int cnt=0;
unsigned long tl=0, t; // board start
unsigned long dt=50;  // minimal dt for rising->falling

void change(void) { 
    t = micros();
    if ( !digitalRead(3) && (t-tl > dt) ) {
    tl = t;

void incVarA(void) {

void resetVarA(void) {

numvar readVarA(void) {
    return cnt;

void siz(void) {
    int i;
    for(i=0; i<cnt; ++i) {
        Serial.print(" ");

void setup(void) {
    initBitlash(57600);		// must be first to initialize serial port

    addBitlashFunction("ra", (bitlash_function) readVarA);
    addBitlashFunction("re", (bitlash_function) resetVarA);

    addBitlashFunction("sz", (bitlash_function) siz);

    attachInterrupt(digitalPinToInterrupt(3), change, CHANGE);

void loop(void) {

Hi, I would now be thinking of making a dyno (rolling road) for your experiments, as you are now talking not just motor but driveline characteristics if you are trying to get battery life.

You need to imitate load on the motor and I'd say my robot would not be going at that blinding speed in a circle.

I love the implementation, I think you need to graduate to a linear device, probably not as elaborate as the youtube.

Tom... :)

... , I think you need to graduate to a linear device, ...

Yeah, that is right.

I got distracted a "bit" in the last 8 months and looked for other stuff needed for a fast driving autonomous robot.

Played with measuring speed of light with Arduino, and played with logic analyzers up to 400Msps.

Played with all kinds of microcontrollers more powerful than Arduino Due (Raspberry Pi Zero, Nanopi Neo [Air], Orange Pi Zero, ...) and different kinds of cameras (USB and Raspberry camera). While I initially thought that camera will be processed by Arduino Due I am pretty sure right now that one of the other controllers will do. The gstreamer framework is too powerful for not being used. The preprocessing of the video images will be done on the other microcontroller as well. With a simple 2$ USB webcam good 240x320 pictures can be taken, this allows to see "the present" at bottom of image, and "the near future" at the top:

The Raspberry camera allows for 90fps video at resolutions 640x480 or 320x240 which would give an image every 6cm even when running with 5m/s (18km/h).

Anyway, I am back on making Arduebot run fast straight and measure that. The method I will use is to run quickly parallel to a very long wall [there are straight walls of 40m without interruption in basement of Böblingen IBM lab ;-)]. That way I don't have to follow a line just now, only for speed measurement.

In this posting I added two HC-SR04 ultrasonic range sensors to the left side of the Arduino Due with v2.0 motor shield. Now I tested if and how running motors would effect the distance measurement precision, with a jacked Arduebot for the moment: |500x375

To my surprise there were bigger measurement ranges than I would have expected (1174 measurements for one of the two HC-SR04):

$ wc --lines vals 
1174 vals
$ sort vals | uniq -c
      7 1790
     17 1791
     75 1815
    750 1816
    254 1817
     38 1818
     26 1819
      6 1820
      1 1842
$ bc -ql

The majority is pretty stable at 1816/1817μs (1816/5.82=312mm distance to wall). Difference betwen max and min of measurements corresponds to 9mm. Overall the measurement distribution looks good under vibrations since the Arduebot control algorithm will deal with them (eg. PID controller).

Next step is letting robot move slowly and try to keep it parallel to wall. (running motors with only 1 Lipo instead of 4 for now)


You could make a track for the bot. Maybe a pin in a slot? That would reduce friction a lot.

First of all, I really made progress with linear robot speed experiments, my caterpillar robot platform is able to run with 2.4m/s or 8.64km/h, which is half of my linear target speed. Her you can see that even U-turns can be done with high speed – the back roll in the air at the end was not planned :wink:

Nevertheless I tested a new motor back in April and achieved a new speed record, only slightly better than reported here (with 5 LiPos and 20.8V):

Recently I stumbled over outrunner motors, and the pure sound made me think they would be able to achieve much more speed. After I broke many aluminum motor mounts due to vibrations I used self made wooden mounts:

I had to learn how to drive brushless motors with ESCs (Electronic Speed Control), how to deal with high currents (breadboard cables are not good for several amp and turn into smoke):

I use SimonK 30A ESCs, and have seen 4A with 10V running a single outrunner motor. Next I had to learn how to drive an ESC with Arduino. After many issues I did my last run 2 hours ago. This is 90fps slowmo video of that run:

At maximum speed it took 25 frames for 4 rounds of robot which means 0.415π4/(25/90)=18.77m/s or 67.59km/h or 42mph, new speed record.

Here is the same run from Android phone camera so that you can hear what happened as well. At the end one motor plus wheel plus mounting bullet cut loose from the robot, and destroyed the surrounding safety glass:

Here you can see the broken safety glass, you can find the bullet (and motor) that broke it right outside of MTS:

The USB connector or Arduino Uno got damaged as well. And the cable connected to Uno GND broke:

The wheel of the motor still connected to robot got loose and went further outside, so much that it should have hit the safety glass:

The wooden mount of the lost motor shows one of the problems, the holes for screws connecting to robot thick wooden beam did break:

So this run had good and bad, new speed record, and first time ever a wheel/motor that broke MTS safety glass surrounding.

Btw, the whole robot is of 495g weight!

The most interesting fact is that my ESC control range is [902μs,2127μs], and this run was done with “only” 1200μs … I have no idea how much faster the robot might run with higher control values, this was just 25% of the possible range!

But any further experiments need a complete redesign of motor test station, safety glass does not help with the bullets used to mount wheel to motor. Motor mounts need to be much better (aluminum is no option, those just break). Need to find better wood. Need to reduce vibrations because of wheels not running perfectly balanced as well, And …


This is the sketch I used as is:

#include <Servo.h>

Servo ESC1;

void setup() {
  int i;

  for(i=901; i<=910; ++i) {

  for(i=1100; i<=1200; i+=10) {


void loop() {

Above run showed 18.77/(0.043*π)=139rps or 8340rpm at motor shaft.

A2212 2700KV outrunner motor with SimonK 30A ESC can do up to 30.000rpm:

Motor+wheel+bullet (that flew away destroying safety glass) weight is 72g

OK, I rebuilt the Motor Test Station.

First I turned the base board, there were too many holes. And to avoid the base board from moving as in the end of last video, I used nails in the corners to fixate the base board on the desk (click on the photos to see more details): |500x375

Here you can see the replacement for the safety glas surrounding. I hope that the4 fixing brackets will avoid bullet plus motor to go throug the wall from now on: |500x375

This is top view from Raspberry camera, which normally takes the 90fps videos: |500x375

Finally I replaced the wooden motor mountings with plastic. I hope that it has same behavior as wood wrt vibrations, but is more stable than wood: |500x375

Test runs would be too loud now at night here, will do tomorrow,


I did a further modification to MTS, added a peephole for third Raspberry NoIR camera to take horizontal video for bump analysis. More details in forum posting 1ms shutter speed 90fps slowmo dark – not with NoIR camera! |500x375

I started like most others with aluminum outrunner motor mounts, but with what I do I always break these: |500x375

Next step was to use self made mounts of wood, but they splittered: |375x500

Next was to use self made motor mounts from plastic, a really bad idea. At least the plastic I used was too brittle and quickly just broke: |500x375

Next I tried to go back to my roots. Normally I do (nearly) everything with superglue, and so I did here as well, I superglued A2212 outrunner motor to beaverboard ... |500x375

... and then superglued beaverboard to robot wooden beam: |500x375

I had to cut a center hole into beaverboard because of the outrunner motor moving parts. In order to do minimal stress to beaverboard, I created the hole with soldering iron: |500x375

This is the final robot motor wheel connection: |500x375

I have already done many runs with the new superglued outrunner motors in motor test station, now its really reliably, and the robot ends a run as he did start, with all wheels and motors attached ;-) My explanation for this is that the (metal) base area of A2212, even without the round center moving part is so big, that supergluing that whole area to beaverboard is much better than 4 screws:

Last, but not least, some 90fps slowmo video action ;-) Click the animated .gifs to see in 640x480 size.

From peephole 90fps slowmo video: Robot starts with spinning wheels, bumpy, but goes smooth later. Animation is slowed down by factor of 10: |500x375

And a reminder to myself: "Don't forget safety glas cover on Motor Test Station!" Wheel lost at 52km/h hits wall, then goes up out of MTS, near miss of top camera!! (1 frame of 90fps slowmo video per second, slowdown factor 90) |500x375


Two days ago I did a further run, but that run was different, robot did go wild. The Arduino sketch should run the robot for 10 seconds and then stop, letting robot roll out to stand still. For yet unknown reason the robot repowered again and again, starting the 10s cycle without stop. Speed was far to high to stop robot by hand. Had to wait for 5 minutes until robot stood still so that I could cut power. In the end the digital voltmeter on robot showed less than 9V under motor load. It shows 12.1V without load, so the 3S 11.1V LiPo was not empty. During the whole run the robot smelled like some cables roasted, after the end I was able to locate the smell on mini breadboard where all the cables are connected:

Yesterday I unscrambled mini breadboard cables and uncovered a reason for last run bad smell, the blue, 2nd ESC GND cable got burned, too many amps: |500x375

Further unscranbling of mini breadboard cables revealed, that mini breadboard does not like too many amps either ;-) [left and right column, bottom 3 connections] |500x375

Time for recabling and not using breadboard nor breadboard cables for links that get several amps, and to use a real power on/off switch,


P.S: At fastest run the robot did 18.77/1.28=14.66rps or 880rpm. Vertically mounted Arduino Uno had no problems to operate at 14.66rps, and I suspect the not perfectly plugged in AWG power cable to be the reason for robot going wild and not the Uno.

I did all the MTS rps/rpm determination with 90fps videos because I did not know that Raspberry cameras can be talked into doing much higher framerate videos (up to 750fps with 6$ v1 China clone 5MP camera, up to 1007fps with 30$ v2 8MP camera)!

With Motor Test Station rpm always was in 3-digit range and 90fps was more than enough. Recently I successfully determined the rpm of RC airplane with 1007fps video as 20140rpm. Just wanted to post here in case others need/want to visually determine fast rotational speed. This is 640x75 video recorded at 1007fps, played at 1fps: |500x58

Very high framerate means low shutter time, so very bright light is needed, I used 5000lm led here: |500x375