Go Down

Topic: Motor Test Station (MTS) (Read 14244 times) previous topic - next topic


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.
Everything runs on smoke, let the smoke out, it stops running....


Sep 26, 2015, 04:53 pm Last Edit: Sep 26, 2015, 05:07 pm by HermannSW
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:

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



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):

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)

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?
Code: [Select]
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



Sep 26, 2015, 11:48 pm Last Edit: Sep 26, 2015, 11:53 pm by HermannSW
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:
Code: [Select]
  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);



May 19, 2016, 12:30 am Last Edit: May 19, 2016, 12:32 am by HermannSW
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.

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:

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:

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:



May 20, 2016, 07:26 pm Last Edit: May 20, 2016, 07:46 pm by HermannSW
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.:
Code: [Select]
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:
Code: [Select]
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:
Code: [Select]
$ diff userfunctions2.ino ../userfunctions2due/userfunctions2due.ino
< unsigned short A[300];
> unsigned long A[20000];

The miilliseconds get recorded correctly [with overflow after 49 days ;-) ]. 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.


Code: [Select]
#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) {


May 21, 2016, 01:55 am Last Edit: May 21, 2016, 01:56 am by TomGeorge
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... :)
Everything runs on smoke, let the smoke out, it stops running....


Mar 05, 2017, 10:42 pm Last Edit: Mar 05, 2017, 10:46 pm by HermannSW
> ... , 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:

To my surprise there were bigger measurement ranges than I would have expected (1174 measurements for one of the two HC-SR04):
Code: [Select]
$ 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.
Do not PM me for help. I will delete immediately.

After Tuesday, even the calendar goes W T F


Jul 09, 2017, 10:55 pm Last Edit: Jul 10, 2017, 01:59 pm by HermannSW
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 ;-)

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:
Code: [Select]
#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


Jul 10, 2017, 11:03 pm Last Edit: Jul 10, 2017, 11:07 pm by HermannSW
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):

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:

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

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:

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



Jul 13, 2017, 08:34 pm Last Edit: Jul 13, 2017, 08:42 pm by HermannSW
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!

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

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

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:

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 ...

... and then superglued beaverboard to robot wooden beam:

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:

This is the final robot motor wheel connection:

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:

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)



Jul 15, 2017, 10:32 pm Last Edit: Jul 15, 2017, 10:52 pm by HermannSW
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:

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

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,


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.


Jun 05, 2018, 06:59 pm Last Edit: Jun 05, 2018, 07:02 pm by HermannSW
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:

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

Go Up