Motor Test Station (MTS)

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.

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:

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

Hermann.
](Loading...)

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.

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.

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.

Hermann.

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


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

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:

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

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

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,

Hermann.

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

Hermann.

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 :wink:
[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,

Hermann.

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:
https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=190407&p=1319617#p1319617

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

I created a 2nd version of caterpillar robot platform last year, "raspcatbot" because there is a Raspberry Pi 3A+ onboard controlling the motors and analyzing the 320x240@204fps Arducam monochrome global shutter video stream for automatic high speed line following. I paused that project last June after having achieved acceleration from stand still to 2.55m/s followed by full speed reverse powering braking on 4.5m long hardboard inside room. Because I had not written the line following code, I superglued two M3 nuts below robot front and back and made it a cable car. The visual real time end of black line detection and then full brake algorithm did work though:

Jacked up robot free running speed is quite high (1774rpm), with 65mm wheel diameter that was 6.04m/s free running (I did superglue small stripes of red foam rubber to endless track in order to increase friction for very short area full braking):

I did restart raspcatbot work in June and had to ask to unlock the aged thread on Raspberry forum, as well as today this thread on Arduino forum.

I did place a big screw in my garage floor center and added 2mm ⌀ steel wire cord to raspcatbot in order to see maximal speed achievable. After seeing only 66% of theoretical speed I identified the cause, I used Pi3A+ 3.3V pin to control 5V logic level L298N motor drivers. I increased makeagif.com playback speed of 2.8m/s run with 1.150g raspcatbot by factor 1.5 in order to see how 4.2m/s speed will look like after adding logic level shifters between Pi3A+ and L298N -- looking at this makes me feel giddy:

Target is to run 1kg raspcatbot (with only one 4S 1.3Ah 95C lipo instead of two) with 5m/s in garage. on 1.25m radius. The steel wire chord seems to be able to deal with computed 20 kg*m/s² centripetal force. I computed kinetic energy for that scenario as well as 12.5 Joule(!).

Then I remembered the outrunner motor high speed record run in this thread, where "outrunner motor+Lego wheel+bullet" (72g in total) did cut loose at 18.77m/s speed and destroyed MTS front safety glass. I was totally surprised that this small pack had even bigger kinetic enery (12.68J) than raspcatbot at 5m/s will have:
https://www.raspberrypi.org/forums/viewtopic.php?f=37&t=267999&p=1887701#p1887701
Just wanted to add this kinetic energy computation for the incident from 4 years ago, becuase it belongs here:

P.S:
Wow, I did not add the computation of centripetal force for 72g pack in the other thread. But just saw that the big wooden bar was a must in order to deal with 122.25 kgm/s² centripetal force (mv²/r -- in comment 40 diameter was 41.5cm):

$ bc -ql
0.072*18.77^2/0.2075
122.24833156626506024096

Likely the big wooden bar between 72g pack and rotation center will add centripetal force to total centripetal force one arm of circular robot has to handle.

Hi, @HermannSW :+1: :+1: :+1:

Thanks for the update.
I am surprised at the speed you can get from the tracks.
Still using L298N, it would be interesting what you could attain using a more efficient motor driver.

Tom.. :smiley: :+1: :coffee: :australia:

1 Like

Still using L298N, it would be interesting what you could attain using a more efficient motor driver.

Even after more than 4 years I am still more the experimental guy trying things out before really understanding them.

I learned that the (150g weight) 4S 1.3Ah 95C (monster) lipo I use to power the robot can continuously deliver 1.3*95=123.5 amps. When buying 3 of those I bought a lipo safety bag for charging those lipos for the very first time.

Regarding the motors, I think you will not like what I will do after adding voltage level shifters. Fully loaded the lipo has 16.8V, and because of my 3.3V vs 5V logic mistake the L298N motor drivers maximally did put 16.8*2/3=11.2V onto the 12V 1500rpm gear motors I have replaced the original robot platforms 330rpm 12V motors with (surprising that the 12V 1500rpm motors shows 1774rpm free running when only powered with 11.2V). I will have to see how the gear motors will react when powered with more than 12V ...

The L298N module(s) I use seem to be an additional bottleneck, while able to deliver more than 30V and up to 2A per channel, they only provide 25W (per channel?). That is no problem when powering with 11.2V erronously as I did, but 25W/16.8V is only 1.5625A.

What motor driver alternatives do exist (I have no data how much amps the 12V 1500rpm gear motors draw)?

P.S:
The maximal speed for 1kg raspcatbot in garage I captured real on video was 3.2m/s or 11.52km/h sofar. I hope to be able to add 50% using level shifters for getting 4.8m/s (17.3km/h).

Hi, mate.
Pololu have a good selection and data table.

Tom... :smiley: :+1: :coffee: :australia:
PS, Keep up the experimenting. :+1: :+1: :+1: :+1: :+1: