Motor Test Station (MTS)

Using Arduino Motors, Mechanics, Power and CNC
21

A mean looking line follower, do they have a 1/4mile dragstip event at RobotChallenge?

Nice idea!

My older son was on field robot event two weeks ago with his university team and (30kg) robot Beteigeuze:
http://fre2015.um.si/index.php/2-fre2015/14-beteigeuze

After the official contest they did a fun contest of "tractorpulling" with their robots :wink:

Probably I would need to go with gearing as proposed (and calculated) by Mark.
I did fix the wheel with superglue, this is complete run (without accident/problems):

"Only" 11 rounds with 1.33m per round gives 5.63m/s or 20.26km/h, far less than with 48mm diameter wheel, perhaps because the 64mm wheel adds 2g of weight.

Perhaps less diameter wheels can give better results for the 12v motor -- with 6.9m/s maximal speed seen sofar the motor did show 2064rpm at the wheel although it could do 17500rpm.

Hermann.

22

Today I tried wheel with smaller diameter (20mm), a "Lego" wheel with the well known cross for Lego "cross axis":

In order to use that wheel with 12V motor axis I had to completely fill the cross with superglue. After more than a day I did drill a small hole with small screwdriver and press motor axis in then. To my surprise there was nearly no imbalance.

This is youtbube video with 12V motor and the new wheel:

Video shows the exact same maximum speed as previously achieved with 15V motor and 64mm diameter wheel.
Looking at formula 1 wide base wheels I will probably go with the current wide base 20mm wheel for my Arduino controlled 2 wheel + ½ table tennis ball based (line following) robot (see here with previously planned parts)

Here text from youtoube video for completeness:
This time with smaller diameter wheel (20mm) and 12V motor.

3 LiPos, not fully loaded (11.60V instead of 12.6V).

Same speed as maximal speed with 15V motor and 64mm wheels.

15 round in 2.80 seconds is 5.35rps or 321rpm.
Wheel moves 1.33m per round, gives 7.125m/s or 25.65km/h.

Hermann.

23

The 12V motor has 17500 rpm at maximal degree of efficiency as mentioned earlier in this thread.

Until this last run all tests did show less than 3000 rpm at motor axis.

Now I did the math for the last run.
1.33m per round of the wooden stick is 21.1 rotations of 20mm diameter wheel.
With 5.35 rounds per second this gives 113.2 rps or 6794 rpm at motor axis.
Still not 17500, but much higher than for all previous MTS runs.

Hermann.

24

You do know that torque depends on motor volume if you eschew gearing? Little motors
without gears will never have enough torque for a robot with all but the tiniest wheels.

25

Thanks, the tiny wheels did it.

I did build real "robot" now with two motors and two wheels, and it showed 9.89m/s or 35.6km/h !!

2048×1536 366 KB

The whole "robot" two wheels carry the complete weight of 73g, the nail just forces circular movement.

Copying in youtube video text with the details:

It turned out that in previous run only one motor did run. The 2nd was dead due to too hot soldering.

Here both motors (bought a new one) did run, and achieved nearly 10m/s or 36km/h !

With new motor, cabling was a problem. This is first run where centrifugal force did not cut any cables.

Two motors are much louder than one :wink:

The whole "robot" two wheels carry the complete weight of 73g, the nail just forces circular movement.

Now the rowvid.com analysis (20.27s - 21.63s):

9.75 rounds in 1.36s gives 7.17rps or 430rpm of wooden stick.

Radius of 22cm of wheels wrt nail gives 1.38m per round, ppeed now is 9.89m/s or 35.61km/h (!).

Wheel has diameter of 2cm, so with 7.17 rounds of 1.38m this is 157.4rps or 9447rpm at motor shaft (pretty close to data sheet max of 17500 under load).

Last comment on Arduino microcontroller, program did increase PMW from 20 to 255 in 12 seconds, keeps at 255 for 10 seconds and then goes back to 20 in 10 seconds before stopping and LED blinking. In order to use this simple program that has been used in so many testruns now, I did duplicate the PWM signal and both motors are controlled by the same L293D motor output. The second L293D motor driver output is not cabled/used yet.

Hermann.

26

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

2048×1536 321 KB

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.

Rowvid.com 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:

Hermann.

27

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.

28

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.

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

"robot" weight is 100g:

Hermann.

29

Hi,

Rowvid.com 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.... :slight_smile:
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.

30

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 rowvid.com 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:
http://forum.arduino.cc/index.php?topic=347579

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

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:

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:

756×384 24.4 KB

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:

1200×900 136 KB

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:

787×601 88.9 KB

Here you can the the new and the old board I used:

1200×900 155 KB

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:

882×466 35.4 KB

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:

1200×900 146 KB

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

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:

886×420 30.4 KB

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]

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]

Hermann.

31

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.... :slight_smile:
Sorry but they don't mean anything to me.

32

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:
http://forum.arduino.cc/index.php?topic=347579.msg2412336#msg2412336

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:

784×416 29 KB

Without slow motion camera I don't have even different perspective and quarter speed does not show details:
[http://rowvid.com/?v=iV0nu0_wUvc&t=41&s=0.25

Hermann.
](http://rowvid.com/?v=iV0nu0_wUvc&t=41&s=0.25)

33

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?

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

Hermann.

34

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);
    delay(50);
  }
  
  delay(10000);

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

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

Hermann.

35

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.

2048×1536 359 KB

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:

846×581 58.7 KB

846×581 58.7 KB

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:

1536×2048 429 KB

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.

Hermann.

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

909×1920 373 KB

909×1920 373 KB

36

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:

804×456 34.9 KB

804×456 34.9 KB

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

Hermann.

#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) ) {
        A[cnt++]=millis();
    }
        
    tl = t;
}

void incVarA(void) {
    A[cnt++]=millis();
}

void resetVarA(void) {
    cnt=0;
}

numvar readVarA(void) {
    return cnt;
}

void siz(void) {
    int i;
    for(i=0; i<cnt; ++i) {
        Serial.print(A[i]);
        Serial.print(" ");
        Serial.println(i);
    }
}

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) {
    runBitlash();
}
37

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

38

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

$ 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
(1842-1790)/5.82
8.93470790378006872852

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)

Hermann.

39

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

40

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:
http://forum.arduino.cc/index.php?topic=486004.0

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

Hermann.

P.S:
This is the sketch I used as is:

#include <Servo.h>

Servo ESC1;

void setup() {
  int i;
  
  ESC1.attach(9);

  ESC1.writeMicroseconds(900);
  for(i=901; i<=910; ++i) {
    ESC1.writeMicroseconds(i);
    delay(100);
  }
  delay(500);

  for(i=1100; i<=1200; i+=10) {
    ESC1.writeMicroseconds(i);
    delay(100);
  }
  delay(5000);

  ESC1.detach();
}

void loop() {
}

P.P.S:
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:

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