raspcatbot

[HermannSW]

Raspcatbot's power switch did not work anymore, so I replaced with anoter working switch.

I wanted to capture a braking drive (11 L298N direction signals, with speed 0), with readable measure tape.
First run had some frame corruptions I have not seen before.
After rebooting I captured again (./braking_eol 150 170 80).
What is really cool is that that run had 0 frame skips.
But that run was captured with 102fps only, no idea why not 204fps.
Good news is that all frame deltas are in 9775µs..9784µs range.
Stored frame.pts allows to build "tape measure location/time" pairs for every 1/100th second of video, giving clear speedup and braking speeds for every of the 256 frames!
I created 25fps video from the 256 frames and uploaded to youtube (allows to stop video and single frame step forwards/backwards with "."/"," keys).
https://www.youtube.com/watch?v=QVlSSb4 ... e=youtu.be

braking3.yt.jpg

braking3.yt.jpg (13.42 KiB) Viewed 4227 times

For completeness, this is complete frame.pts:

Code: Select all

# timecode format v2
0.000
9.779
19.558
29.337
39.117
48.896
58.675
68.454
78.234
88.013
97.792
107.571
117.350
127.130
136.909
146.688
156.468
166.247
176.026
185.805
195.584
205.364
215.143
224.922
234.701
244.483
254.260
264.041
273.818
283.598
293.377
303.156
312.935
322.714
332.494
342.273
352.052
361.831
371.610
381.390
391.169
400.948
410.727
420.507
430.286
440.065
449.844
459.623
469.403
479.182
488.961
498.740
508.520
518.299
528.078
537.857
547.637
557.416
567.195
576.974
586.753
596.533
606.312
616.091
625.870
635.651
645.429
655.208
664.987
674.766
684.546
694.325
704.104
713.884
723.663
733.442
743.221
753.000
762.780
772.559
782.338
792.117
801.896
811.676
821.455
831.234
841.013
850.793
860.572
870.351
880.130
889.910
899.689
909.468
919.247
929.026
938.806
948.585
958.364
968.143
977.923
987.702
997.481
1007.261
1017.040
1026.819
1036.598
1046.377
1056.156
1065.936
1075.715
1085.494
1095.273
1105.053
1114.832
1124.611
1134.390
1144.170
1153.949
1163.728
1173.508
1183.287
1193.066
1202.845
1212.624
1222.403
1232.183
1241.962
1251.741
1261.521
1271.299
1281.079
1290.858
1300.637
1310.416
1320.196
1329.975
1339.754
1349.533
1359.312
1369.092
1378.871
1388.650
1398.429
1408.209
1417.988
1427.767
1437.546
1447.326
1457.105
1466.884
1476.663
1486.442
1496.222
1506.001
1515.780
1525.560
1535.339
1545.118
1554.897
1564.677
1574.456
1584.235
1594.014
1603.794
1613.573
1623.352
1633.131
1642.910
1652.689
1662.469
1672.248
1682.027
1691.806
1701.585
1711.365
1721.144
1730.923
1740.702
1750.482
1760.261
1770.041
1779.819
1789.599
1799.378
1809.157
1818.936
1828.716
1838.495
1848.274
1858.053
1867.833
1877.612
1887.391
1897.170
1906.949
1916.729
1926.508
1936.287
1946.066
1955.850
1965.625
1975.405
1985.183
1994.962
2004.742
2014.521
2024.300
2034.080
2043.859
2053.638
2063.417
2073.197
2082.975
2092.755
2102.534
2112.313
2122.093
2131.872
2141.651
2151.430
2161.209
2170.989
2180.768
2190.547
2200.326
2210.105
2219.885
2229.664
2239.443
2249.222
2259.002
2268.781
2278.560
2288.339
2298.118
2307.898
2317.677
2327.456
2337.235
2347.016
2356.794
2366.573
2376.353
2386.131
2395.911
2405.690
2415.469
2425.248
2435.028
2444.807
2454.586
2464.365
2474.145
2483.924
2493.703

And this is analysis:

Code: Select all

$ ~/ptsanalyze frame.pts 0
creating tstamps.csv
256 frames were captured at 102fps
frame delta time[us] distribution
      1 9775
      2 9777
      7 9778
    179 9779
     59 9780
      3 9781
      1 9782
      1 9784
after skip frame indices (middle column)
0 frame skips (0%)
$

[HermannSW]

I spent quite some effort in determining speed for every of the first 169 frames before braking happens.
I did cut out relevant bottom part, did threshold and then scale by factor 4:

Code: Select all

#!/bin/bash
pnmcut -left 120 -top 185 -width 140 -height 55 $1 | pamthreshold -simple -threshold $2 | pamscale 4 | pamtopng > $1.png

Then I applied this script to all frames, this is converted frame 161:

frame.0161.raw.enh.pgm.png

frame.0161.raw.enh.pgm.png (264 Bytes) Viewed 4207 times

For each of these frames I determined cm value for bottom cm marker (161cm), and y coordinates of bottom and next to bottom marks. Then spreadsheet used those coordinates and the cm value to determine the exact non-integer cm value for bottom of frame. Unfortunately the results were really spiky, not what I have hoped for, Perhaps camera small bumps are a factor, or the too simple linear model for determining frame bottom position in centimeters.

I saw same spiky stuff for braking phase, there I only determined 9 time/postion pairs for 0% to 100% of braking in 12.5% position steps. But a linear decrease of speed over time for the motor directions both 1 braking could be seen (breaking is negative acceleration, and v=a*t for normal acceleration).

It took 0.7s to brake, from 2m/s to 0m/s. I wrote a small simulator of what that means if only one motor is braked this way, and the other keeps running at 2m/s. Simplest method to generate simple line graphics is postscript file, this code generated 19cm wide lines representing the robot front, and the moves happening after each dt=0.01s. This code assumes that the left side position is fixed and the right (constantly moving 2m/s) side turns around:

Code: Select all

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

void ini()
{
  printf("%!PS\n\nmatrix currentmatrix /originmat exch def\n/umatrix {originmat matrix concatmatrix setmatrix} def\n[2.83465 0 0 2.83465 0 0] umatrix\n\n0.1 setlinewidth\n\n");
}

void line(double lx, double ly, double rx, double ry)
{
  printf("%.1f %.1f newpath moveto\n%.1f %.1f lineto\nclosepath\n0 setgray\nstroke\n", lx, ly, rx, ry);
}

void exi()
{
  printf("\nshowpage\n");
}

// 215/279

#define S 0.7
#define L 19

int main(int argc, char *argv[])
{
  double lx, ly, rx, ry, t;
  double T=(argc<2)?0.7:atof(argv[1]);
  double dt=(argc<3)?0.01:atof(argv[2]);

  ini();
  lx=150; ly=100; rx=169; ry=100;
  line(lx, ly, rx, ry);
  for(t=dt; t<T; t+=dt)
  {
    double vl=200*(S-t)/S, vr=200;
    double vx=rx-lx, vy=ry-ly;
    double l=sqrt(vx*vx+vy*vy);
    vx/=l; vy/=l;
    lx-=vy*vl*dt; ly+=vx*vl*dt;
    rx-=vy*vr*dt; ry+=vx*vr*dt;
    l=sqrt((rx-lx)*(rx-lx)+(ry-ly)*(ry-ly));
    rx=lx+(rx-lx)/l*L; ry=ly+(ry-ly)/l*L;
    line(lx, ly, rx, ry);
  }

  exi();
}

Second code assumes that right side keeps position, and left side moves:

Code: Select all

$ diff cat.c catr.c
43c43
<     rx=lx+(rx-lx)/l*L; ry=ly+(ry-ly)/l*L;
---
>     lx=rx+(lx-rx)/l*L; ly=ry+(ly-ry)/l*L;
$

Both simulation results look nearly identical.
Each line represents the front width of 19cm of robot, postscript output is 1:10 size of real:

raspcatbot.curve.png

raspcatbot.curve.png (5.07 KiB) Viewed 4207 times

Needs to be verified by real robot drives, maybe full motor reversal on left side will achiece smaller turn area.
Another option for reducing curve area is to increase caterpillar track friction on hardboard.

[HermannSW]

Another option for reducing curve area is to increase caterpillar track friction on hardboard.

Wow, initial experiment with using foam rubber to increase continuous track friction on hardboard is awesome!
Will superglue foam rubber onto track tomorrow:
https://www.youtube.com/watch?v=sC4IizI ... e=youtu.be

continuous_track_friction.png

continuous_track_friction.png (121.22 KiB) Viewed 4180 times

[HermannSW]

I did superglue 38mm long 10mm wide foam rubber stripes over two highs of continuous track:

20200418_135855.15%.jpg

20200418_135855.15%.jpg (166.16 KiB) Viewed 4137 times

But that did not work. two highs of track, when on wheel, are 11mm wide, and foam rubber does not allow for 10% more.
There was huge tension, and the wheels did not drive.

Then I did cut the 1cm stripes roughly in the middle, and continuous track works again.
The tracks showed 1530/1570/1525/1610 rpm, for both track and both directions:

20200418_202857.15%.jpg

20200418_202857.15%.jpg (205.07 KiB) Viewed 4137 times

Now its time to let raspcatbot drive on hardboard course -- given the extreme friction I experienced in yesterday's experiment of last youtube video, I would expect shorter braking distances on hardboard than seen with carpet braking tests previously ...

P.S:
Foam rubber does not only increase friction on hardboard, it increases overall wheel diameter from 58mm to 64mm. With 1570rpm that is 5.26m/s free running speed, compared to 4.77m/s with previous diameter and same rpm.

[HermannSW]

This is just first braking test with foam rubber superglued to continuous tracks.
Braking with both L298N direction pins 11, and pwm=0.

It seems that acceleration does not work as before, this is from run started with higher pwm values than before; lipo has 15V only for the braking test:

Code: Select all

$ sudo ./braking_eol 220 180  80

The first 5 frames move 1cm each, with no frameskips and framerate 204fps. That means speed slightly above 2m/s as before. But this time braking distance is not 75cm, but only 145cm-108cm=37cm(!):



With foam rubber much increased friction on hardboard plates, I expect motor direction reversal for short time to show an even shorter braking distance.

Time between frame where braking started and raspcatbot stop is only 376.5ms.
I did put that number into cat.c simulation program described previously in order to see what the now only 0.3765s from 2m/s to 0m/s would mean to curve braking. Here you can see both together, especially in horizontal direction braking area is much shorter:

raspcatbot.curve.2.png

raspcatbot.curve.2.png (13.48 KiB) Viewed 4110 times

[HermannSW]

Yesterday I did runs with motor reversal braking, now that foam rubber is superglued to continuous tracks.
And this time the results are better than with "normal" braking.
With this commit I added that new braking code, and moved motor stopping out of callback:
https://github.com/Hermann-SW/MIPI_Came ... 9ccafe1a9c


With slightly higher speed the previous braking distance increased from 37cm to 47cm. New motor direction reversal braking for same speed was only 35cm. Therefore I started to test with higher speeds, and by 1.5m extended straight black line (previously from 350cm to 145cm, now from 433cm to 95cm). In the run that I will describe more on the braking side, a new inhouse raspcatbot speed record was achieved:

As you can see in animation, robot moves from 126cm to 116cm at bottom of frame in 8 frames. Framerate was 204fps, and there were no frameskips in that range. Speed was 0.10/((1701.586-1662.469)/1000)=2.56m/s or 9.21km/h. As can be seen in the animation, some frames show not completely clear. I assume that CSI-2 flat ribbon cable between Pi3A+ and ov7251 monochrome global shutter camera came too near to either the cables powering the Pi3A+ via microUSB, or more likely the cables from motor controller to right caterpillar motor, with >15V and >1A. I added Lego pieces to ensure that the cables will not be able to come close again.

This is frame 32, just after starting to move, at window wall end of the room:

frame.0032.raw.enh.pgm.png

frame.0032.raw.enh.pgm.png (22.38 KiB) Viewed 4044 times

This is frame 339 where braking started at 109.5cm, because black line moved too wide to the left, that it was not detected as straight line anymore:

frame.0339.raw.enh.pgm.png

frame.0339.raw.enh.pgm.png (19.49 KiB) Viewed 4044 times

This is frame 409 where motor stopped at 59.5cm. So total braking distance is 50cm, but for 25% more speed that 2m/s before:

frame.0409.raw.enh.pgm.png

frame.0409.raw.enh.pgm.png (18.6 KiB) Viewed 4044 times

Here is complete video generated from the 410 frames recorded, playing at 20fps, 10× slower than real:
https://www.youtube.com/watch?v=M9OphuG ... e=youtu.be

I did use 2.56m/s speed and 0396s braking time in simulation, and the new curve right is not that much bigger for full turn (length of one line is 19cm, robot front):


Now time has come to turn raspcatbot around and use camera in driving direction. End of line can be detected 20(30?)cm upfront and braking can start then. This will result in much less overshoot over end of line.

[HermannSW]

For more lookahead I experimented with increasing tilt of the 9V powered robot front led.

This was slight increase compared to before, a bit wider view:

1599.enh.pgm.png

1599.enh.pgm.png (19.53 KiB) Viewed 4021 times

Even more increase, wider view:

0099.enh.pgm.png

0099.enh.pgm.png (18.48 KiB) Viewed 4021 times

Finally front led is vertically, best view for distance:

0089.enh.pgm.png

0089.enh.pgm.png (15.51 KiB) Viewed 4021 times

I took that last (normalized) frame, and did apply threshold 80.
For being better able to see the details, I doubled to 640x480 frame.
Looks like a good basis, bottom of frame is 122cm, end of straight black lines is 95cm.
So lookahead of 30cm is possible when mounting robot front led vertically:

[HermannSW]

2007 Vienna RobotChallenge rules stated:

• black line 1.5cm wide
• different parts of course at least 15cm part
• minimal radius 15cm

I just enhanced last model for 2.56m/s speed, and that would allow already to do a 180° 15cm diameter curve:

raspcatbot.curve.3a.jpg

raspcatbot.curve.3a.jpg (41.46 KiB) Viewed 3973 times

http://www.physics.emory.edu/faculty/we ... tops1.html
http://www.physics.emory.edu/faculty/we ... tops2.html

Code: Select all

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

void ini()
{
  printf("%!PS\n\nmatrix currentmatrix /originmat exch def\n/umatrix {originmat matrix concatmatrix setmatrix} def\n[2.83465 0 0 2.83465 0 0] umatrix\n\n0.1 setlinewidth\n\n");

  printf("/m {newpath moveto} bind def\n/l {lineto} bind def\n/cp {closepath} bind def\n/s {stroke} bind def\n/sg {setgray} bind def\n/f {fill} bind def\n/a {arc} bind def\n/an {arcn} bind def\n");
}

void line(double lx, double ly, double rx, double ry)
{
  printf("%lf %lf newpath moveto\n%lf %lf lineto\nclosepath\n0.5 setgray\nstroke\n", lx, ly, rx, ry);
}

void exi()
{
  printf("\nshowpage\n");
}

void m(double x, double y)  { printf("%lf %lf m\n", x, y); }
void l(double x, double y)  { printf("%lf %lf l\n", x, y); }
void cp()                   { printf("cp\n"); }
void s()                    { printf("s\n"); }
void sg(double g)           { printf("%lf sg\n", g); }
void f()                    { printf("f\n"); }
void a(double x, double y, double r, double a, double o)
                            { printf("%lf %lf %lf %lf %lf a\n", x,y,r,a,o); }
void an(double x, double y, double r, double a, double o)
                            { printf("%lf %lf %lf %lf %lf an\n",x,y,r,a,o); }

// 215/279

#define S 0.396
#define L 19

int main(int argc, char *argv[])
{
  double lx, ly, rx, ry, t;
  double T=(argc<2)?0.7:atof(argv[1]);
  double dt=(argc<3)?0.01:atof(argv[2]);

  ini();

  m(154.75, 100);
  l(154.75, 135);
  l(156.25, 135);
  l(156.25, 100);
  cp();
  sg(0);
  f();
  m(124.75, 100);
  l(124.75, 135);
  l(126.25, 135);
  l(126.25, 100);
  cp();
  sg(0);
  f();
  a(140.5, 135, 15.75, 0, 180);
  an(140.5, 135, 14.25, 180, 0);
  cp();
  f();

  lx=150; ly=100; rx=169; ry=100;
  line(lx, ly, rx, ry);
  for(t=dt; t<T; t+=dt)
  {
    double vl=255*(S-t)/S, vr=255;
    double vx=rx-lx, vy=ry-ly;
    double l=sqrt(vx*vx+vy*vy);
    vx/=l; vy/=l;
    lx-=vy*vl*dt; ly+=vx*vl*dt;
    rx-=vy*vr*dt; ry+=vx*vr*dt;
    l=sqrt((rx-lx)*(rx-lx)+(ry-ly)*(ry-ly));
    rx=lx+(rx-lx)/l*L; ry=ly+(ry-ly)/l*L;
    line(lx, ly, rx, ry);
  }

  exi();
}

[HermannSW]

2007 Vienna RobotChallenge rules stated:

• black line 1.5cm wide
• different parts of course at least 15cm part
• minimal radius 15cm

In later years they tightened the radius rule, minimal diameter was 15cm then.
And there was a guarantee that any angle will not be less than 90°.
When reading that years ago, I created this hardboard plate:



I modified the simulation for a diameter 15cm U-turn. And it turned out, that when the robot drives in a specific initial direction, then the current model can do 15cm diameter U-turn while keeping 2.56m/s speed on the outer caterpillar track (of course turning needs to be stopped at the right point in time, in order to follow the straight line after U-turn -- but this is a simple model, and needs to be verified by real raspcatbot runs (without canle) anyway):

raspcatbot.curve.3b.jpg

raspcatbot.curve.3b.jpg (17.55 KiB) Viewed 3951 times

Here is the small diff in simulation code:

Code: Select all

$ diff cat3a.c cat3b.c
32a33,34
> #define deg M_PI/180.0
> 
53,56c55,58
<   m(124.75, 100);
<   l(124.75, 135);
<   l(126.25, 135);
<   l(126.25, 100);
---
>   m(139.75, 100);
>   l(139.75, 135);
>   l(141.25, 135);
>   l(141.25, 100);
60,61c62,63
<   a(140.5, 135, 15.75, 0, 180);
<   an(140.5, 135, 14.25, 180, 0);
---
>   a(148, 135, 8.25, 0, 180);
>   an(148, 135, 6.75, 180, 0);
65c67
<   lx=150; ly=100; rx=169; ry=100;
---
>   lx=143; ly=90; rx=lx+19*cos(25*deg); ry=ly-19*sin(25*deg);
$

[HermannSW]

Three postings ago I did experiment with lighting and different tilt angles.
Best result was achieved with 9V powered led bulb mounted vertically.

Today I did experiments with the 10W 1.5Ω resistors that arrived.
Instruction for the led bulb said, if powering with 12V, use 1.5Ω resistor in series.
First I did verify that the resistor is indeed 1.5Ω (my multimeter measearued around 20Ω) using constant voltage power supply:
https://twitter.com/HermannSW/status/12 ... 5231281152

Then I did setup as last night, replacing robot 9V led bulb with same model led bulb and 1.5Ω resistor in series. Soldering 3rd hand placed the new led bulb exactly where the led bulb was last night, and raspcatbot position was same as well. There is a difference in the normalized grey frames.

Yesterday:

Today:

0094.enh.pgm.png

0094.enh.pgm.png (25.47 KiB) Viewed 3929 times

That difference required a different threshold value to take (33 instead of 80), but the resulting b&w frame looked nearly identical to the one shown 3 postings ago. No increase in distance that can be "seen" upfront.

Next I will add reflector to increase lookahead over 30cm, done earlier in this thread, achieved 1m there:
viewtopic.php?f=37&t=267999&start=25#p1637044



In case there will be no big advantage of powering with 12V plus series 1.5Ω resistor, I will keep the "only" 9V poweing if the led bulb.

[HermannSW]

I did many experiments with 12V vs. 9V last night, and while 12V looks different, it added no more forward view. Since running at 9V is safer, I will keep that, and not switch to 12V plus 1.5Ω resistor, which produces much more heat (heat is no issue with 9V, because there the bulb runs at only 1W).

Then I tried three different reflector types I had, with 12V and 9V (just in case that would have made a difference). All frames captured that way have far more forward view, but as drawback one spot of high brightness (this is already the normalized frame). So I will not use reflectors for the next phase of runs:

0096.enh.pgm.png (20.78 KiB) Viewed 3905 times

Next I realized that I received 4 led bulbs after I killed the previous 4. And I only used one. So I tried with two, and then with 3 led bulbs. That increased forward view with each led bulb added:

x.anim.gif (29.5 KiB) Viewed 3905 times

Here are the three led bulbs, all connected to heat sink, which is superglued to a 2x2 normal Lego piece for easy relocation.
They are powered by the same LM2596 that delivers exactly 9V.
I have verified (by looking through welding helmet safety glass) that all 3x3 led dots in the three bulbs do shine when powered with 9V:

20200421_232317.10%.jpg

20200421_232317.10%.jpg (80.06 KiB) Viewed 3905 times

This is backward view, I had to turn on desk light because otherwise the robot was just too dark because of the bright front bulbs:



P.S:
You can see the Lego pieces as well, that I added to ensure that CSI-2 flat ribbon cable will not come near motor powering cables (left) and additional female USB connector (middle, for powering the Pi3A+ without lipo) -- right click for zoom.

[HermannSW]

Last night I had to debug/fix mechanical continuous track issues:
https://twitter.com/HermannSW/status/12 ... 6356732929

raspcatbot.mechanical.small.jpg

raspcatbot.mechanical.small.jpg (62.4 KiB) Viewed 3849 times

The last wheel, on the other side of the motor wheel, has some freedom for the screw to be fastened.
If tension is too big, nothing rotates at all, if tension is too low, at least the free running track does bad things.

The tests took long time, left forward, measure speed with laser tachometer, left back, ....
Over time the lipo voltage dropped and dropped, from 16.7V to 14.8V.
Today I wanted to have always the same voltage for the jacked up raspcatbot tests.
So I made a new connector allowing my constant power supply to power raspcatbot instead of the 4S lipo:



Supply delivered constant 16.8V with 3A max.
After booting the Pi, in idle phase current draw was 0.264A.
Then I did light the three led bulbs, powered with 9V from 2nd LM2596 step-down converter, current draw was 0.452A then.
Then I turned lights off for motor tests.

Two times it happened, that when running one motor at PWM=255, and then setting PWM=0, some voltage spike resetted the Pi3A+. I have never seen that in real runs -- on the other hand I did full motor direction reversal braking not when running with full speed sofar.

Running right motor forward with PWM=128 draws 0.633A, laser tachometer says 1250rpm.
Running right motor backward with PWM=128 draws 0.706A (max), laser tachometer says 1080rpm.

A lot of testing needs to be done, to learn about the continuous track mechanics and find a good setup for next real test drives on hardboard course.

[HermannSW]

I helped somebody to get two 320x240 SPI displays working with his Pi:
viewtopic.php?f=44&p=1649091#p1648336
This is end of my Pi0 bootup:



Today I realized that 320x240 is exactly the mode5 ov7251 monochrome global shutter camera format.
I knew that I had a third such 2.2" display and found it.
I superglued the SDcard metal of display underside onto a 2x8 normal Lego piece.
And I added some more pieces for the display to find its home.
After enabling SPI1 in /boot/config.txt and rebooting, display worked immediately!

20200425_004401.15%.jpg

20200425_004401.15%.jpg (207.29 KiB) Viewed 3798 times

I already mentioned that I sometimes use Android app JuiceSSH to login to raspcatbot's Pi3A+.
With this display it is possible to inspect all images that got recorded during a test drive on the 320x240 display (conversion from raw to pgm, then spreadpgm, probably thresholdpgm).
It might be used for displaying what robot sees during a test drive, probably in converted form -- that could be inspected in a smartphone video capturing a robot drive.

[HermannSW]

With idling Pi3A+, no lights on and no motor movement, raspcatbot did draw 0.264A.
With added display raspcatbot draws 0.277A/0.279A/0.280A for PWM=0/128/255.
Only 16mA for the giraffe /dev/fb1 indicator image surprised me positively.

Today I brought the display up on boot, with finally a console on it.
I knew that the first "sleep 1" was needed from the dual SPI display work.
I was surprised to find out that the second is needed as well (the third only to see /dev/fb1 giraffe indicator image):

Code: Select all

$ tail -8 /etc/rc.local 
sleep 1
sudo modprobe fbtft_device name=rpi-display gpios=reset:13,dc:26,led:6 rotate=90 cs=2 busnum=1
sleep 1
tail --bytes 153600 /home/pi/fb1.565.bmp > /dev/fb1
sleep 1
con2fbmap 1 1

exit 0
$

I did open a SSH session in order to get snapshot of display after boot:

init.ppm.png

init.ppm.png (2.33 KiB) Viewed 3742 times

The undervoltage message alerted me, and I found a todo that was not done until now.
There are thin cables that go to the LM2596 stepdown converter that powers the PI.
Replacing them will eliminate the undervoltage warnings, I did that exercise once already:
viewtopic.php?f=45&t=222525&p=1642901#p1642901

20200427_213948.15%.jpg

20200427_213948.15%.jpg (193.19 KiB) Viewed 3742 times

I did create new script that takes a raw 320x240 frame (from /dev/shm), converts to pgm, normalizes grey levels and then uses ffmpeg to convert to rgb565 format, and that gets copied into /dev/fb1 (display):

Code: Select all

$ cat disp_spread 
#!/bin/bash
raw=rawvideo
./rawtopgm $1 | ./spreadpgm | \
ffmpeg -vcodec pgm -i - -vcodec $raw -f $raw -pix_fmt rgb565 - 2>/dev/null | \
cat > /dev/fb1
$

I did capture the frames as always with 200µs shutter time and mode5 (320x240@204fps). The display looks quite nice (the led bulbs had been turned off again after capturing the frames, so don't shine in this smartphone photo):

20200427_213721.15%.jpg

20200427_213721.15%.jpg (158.09 KiB) Viewed 3742 times

P.S:
ili9341 SPI display typically allows for 10fps, but there is a project allowing for up to 60fps:
https://github.com/juj/fbcp-ili9341

During robot drive there is no time for converting frame and displaying on /dev/fb1.
But the pigpio based C programs (like braking_eol.c) do store all frames captured under /dev/shm.
Another program can run on another Pi3A+ core and just wait for new frames to appear (better for every 3rd new frame because of 204fps camera framerate) and display the frames on display during robot drive. For slow runs that would allow for easy live visual debugging by me, and even for fast runs the display may reveal important information when capturing the robot while driving with smartphone camera.

[HermannSW]

Today I did video from side lighted from 5000lm of jacked raspcatbot.
I replaced v2 camera capturing at 100fps by my other ov7251 0.3MP monochrome global shutter camera, details here:
viewtopic.php?f=43&t=267563&p=1651918#p1651918

Right endless track running forward (PWM=255, reflective marker on right front wheel shows clockwise(!) turning direction).
In mentioned posting it was determined that front wheel turns with 1630rpm or >27 rotations per second:


Now I did capture video of right track running backwards at full speed.
There was no frame skip of mode4 capturing 640x120@353fps in animation.
Each 640x120 frame is converted to 640x480 frame by duplicating each row 4 times.
Frame 2 and frame 63 show reflective marker in same position, animation consists of frames 2-62.
Those frames captured 5 full rotations of front wheel, rotations per second is therefore 1000000/((175519-2831)/5)=28.95, or 1737rpm(!):


No laser tachometer needed here, but that was not reason for the videos. The 12V 1500rpm gear motor does so well, because of overvoltage (temporarily jacked up raspcatbot is powered by 16.8V constant voltage power supply, for repeatable measurements), and because of no mechanical issues. The other side track and/or motor has issues I need to debug&fix. Next step is to put other side track on this side and see whether the same forward/backward speeds can be achieved.


P.S:
There is only one reason for mechanical track problems. The back wheel is not forced into a postion like the middle and front wheel, allowing to change tension of the track. If too tight, track does not move at all, if too loose then other bad things happen. So what is needed is to find the right position. Just to document the setting used for todays runs, below photo shows the position. Difficult to shoot a photo there, smartphone flashlight made it possible.
I know the XT60 connector I did is not perfect, but I had no female XT60 connector needed for the task. So I used a male connector in wrong direction, not perfect, but works for jacked up robot tests.
Seeing continuous track over back wheel from so near also shows why I was forced to cut the rubber foam superglued over two neighboring track heighs in the middle, distance is just much longer than on non-wheel part of track.

20200429_210353.15%.jpg

20200429_210353.15%.jpg (170.17 KiB) Viewed 3678 times

[HermannSW]

I added a small reflective marker to the endless track as well. That way it is easy to see the correct turning direction of the track. It turned out that the whole track (not a wheel) does 10.9 rotations per second:
viewtopic.php?f=43&t=267563&p=1652712#p1652712


Today I started with two measurements with laser tachometer for the right side track that I had shown animations for. I did measurements against left middle of front wheel, because then the reflective marker turning on endless track does not get counted. Full forward/backward speed measured: 1650/1770 rpm.

Next I did remove right side track (1), and left side track (2) and compared them. I did not find a difference when letting them rotate around my fingers. Then I did put the former left side track 2 onto the right side. And here a difference was immediately clear, with the unchanged postion of screw and nut of right side back wheel there was much more tension on the track. Forward as well as backward movement with PWM=128 did not happen at all. Full forward/backward speed measured: 1430/1410 rpm (only).

Then I unscrewed right back wheel screw and moved it so that track tension was not that tight anymore. And that was all that was needed. Full forward/backward speed measured: 1685/1775 rpm!

20200501_214950.15%.jpg

20200501_214950.15%.jpg (186.63 KiB) Viewed 3611 times

These two speeds roughly match the 1650/1770 rpm measured with track 1 before. So both tracks are "equivalent" to use. Next testing or left caterpillar is needed. If motor is good enough, maybe just a better (not that tight) track tension on that side is all that is needed ...


Smartphone camera exposure time was 1/17th (from original image), and wheel rotates with 1774/60=29.6rps. The reason why reflective marker on wheel does not fully cover a ring is rolling shutter effect of smartphobe camera:

jpeg.metadata.png

jpeg.metadata.png (33.12 KiB) Viewed 3600 times

P.S:
I don't know yet how free running speed and 900g robot real drive speed correclate yet.
Just measure diameter of wheel+track_with_foam_rubber as 61mm.
So slowest maximal free running speed for now is: π*0.061*1650/60 = 5.27m/s or 18.97km/h

20200502_093659.10%.jpg

20200502_093659.10%.jpg (84.04 KiB) Viewed 3574 times

[HermannSW]

It is too late here and too loud to do testing left caterpillar robot side, will do that tomorrow morning.

As discussed earlier, the 12V 1500rpm gear motors have a sweet turning direction. Because of both gear motors mounted on different sides of raspcatbot, driving straight forward will be sweet for one motor and not sweet for the other. Currently I dont know whether the free running speeds will be real robot drive speeds after long enough acceleration (basement living room plus kitchen allows for 9m straight hardboard, and I have matching 18 hardboard plates). So I wanted to know what two motors running at the measured maximal speeds 1650/1770 rpm for endless track 1 will have for consequences of running along straight line with 5.27m/s and 5.65m/s speeds. I modified last simulation for one 1m long straight line (1.5cm thick). Simulation code needs speed in cm/s:

Code: Select all

    double vl=M_PI*6.1*1650/60, vr=M_PI*6.1*1770/60;

It takes nearly 1m for robot to get off the straight black line with only 120rpm difference at those high speeds. The whole time of robot motion displayed is 0.2s:

cat4.ps.png

cat4.ps.png (5.17 KiB) Viewed 3546 times

Code: Select all

$ cat cat4.c
#include <stdio.h>
#include <stdlib.h>
#include <math.h>

void ini()
{
  printf("%!PS\n\nmatrix currentmatrix /originmat exch def\n/umatrix {originmat matrix concatmatrix setmatrix} def\n[2.83465 0 0 2.83465 0 0] umatrix\n\n0.1 setlinewidth\n\n");

  printf("/m {newpath moveto} bind def\n/l {lineto} bind def\n/cp {closepath} bind def\n/s {stroke} bind def\n/sg {setgray} bind def\n/f {fill} bind def\n/a {arc} bind def\n/an {arcn} bind def\n");
}

void line(double lx, double ly, double rx, double ry)
{
  printf("%lf %lf newpath moveto\n%lf %lf lineto\nclosepath\n0.5 setgray\nstroke\n", lx, ly, rx, ry);
}

void exi()
{
  printf("\nshowpage\n");
}

void m(double x, double y)  { printf("%lf %lf m\n", x, y); }
void l(double x, double y)  { printf("%lf %lf l\n", x, y); }
void cp()                   { printf("cp\n"); }
void s()                    { printf("s\n"); }
void sg(double g)           { printf("%lf sg\n", g); }
void f()                    { printf("f\n"); }
void a(double x, double y, double r, double a, double o)
                            { printf("%lf %lf %lf %lf %lf a\n", x,y,r,a,o); }
void an(double x, double y, double r, double a, double o)
                            { printf("%lf %lf %lf %lf %lf an\n",x,y,r,a,o); }

#define deg M_PI/180.0

// 215/279

#define L 19

int main(int argc, char *argv[])
{
  double lx, ly, rx, ry, t;
  double T=(argc<2)?0.2:atof(argv[1]);
  double dt=(argc<3)?0.002:atof(argv[2]);

  ini();

  m(158.75, 100);
  l(158.75, 200);
  l(160.25, 200);
  l(160.25, 100);
  cp();
  sg(0);
  f();

  lx=150; ly=100; rx=169; ry=100;
  line(lx, ly, rx, ry);
  for(t=dt; t<T; t+=dt)
  {
    double vl=M_PI*6.1*1650/60, vr=M_PI*6.1*1770/60;
    double vx=rx-lx, vy=ry-ly;
    double l=sqrt(vx*vx+vy*vy);
    vx/=l; vy/=l;
    lx-=vy*vl*dt; ly+=vx*vl*dt;
    rx-=vy*vr*dt; ry+=vx*vr*dt;
    l=sqrt((rx-lx)*(rx-lx)+(ry-ly)*(ry-ly));
    rx=lx+(rx-lx)/l*L; ry=ly+(ry-ly)/l*L;
    line(lx, ly, rx, ry);
  }

  exi();
}
$

[HermannSW]

It turned out to be simple to get left caterpillar side run without issues.
I tested left side full forward/backward speeds and completed table:

Code: Select all

speed[rpm] | left right
-----------+-----------
   forward | 1685 1690
  backward | 1780 1590

The right side motor is less capable than left side, but luckily right side sweet speed matches nearly exactly left side not sweet speed. A final test with both motors running full speed (PWM=255) forward showed 1690/1670 for left/right wheels with reflective marker.

I did monitor left motor current draw while testing separately with my constant voltage power supply (loud!):
https://www.youtube.com/watch?v=DcnsMPbaBWA
While showing 1690rpm measured with laser tachometer, constant voltage power supply shows intial short raise from 282mA to more than 1A, then mostly in 750-800mA range, maximal 858mA, minimal 721mA. So motor maximally draws 858-282=570mA while running -- no problem for 4S 1300mA 95C lipo that can deliver 123.5A later.

I did the experiments with remote shell from another Pi connected to HDMI monitor. Several times the ssh session got stuck, always when running a motor full speed. I learned to login to Pi3A+ console with the help of onboard LCD and switch to directory where I could execute "./minit" script that does bring all (gone wild) motors to stand stiil -- before doing the experiments from the other Pi. At last such event I realized again undervoltage message:

20200503_105112.15%.jpg

20200503_105112.15%.jpg (212.71 KiB) Viewed 3517 times

Then I replaced the last thin cables that have to carry amps, those connected to LM2596 and switch for powering the Pi3A+. Perhaps too thick, but undervoltage warning should never happen again. The Wireless keyboard adapter you can see plugged into USB port on left side of Pi3A+ allows to login to console running on oboard LCD if needed (wireless connection dropped, ...):

20200503_114840.15%.jpg

20200503_114840.15%.jpg (165.99 KiB) Viewed 3517 times

P.S:
I just updated left/right speeds in simulation from last night, with only 20rpm difference robot keeps on line for more than 1m -- time to add simple straight line following code in order to get rid of "cable car" mode cable:

Code: Select all

$ diff cat4.c cat4b.c
59c59
<     double vl=M_PI*6.1*1650/60, vr=M_PI*6.1*1770/60;
---
>     double vl=M_PI*6.1*1690/60, vr=M_PI*6.1*1670/60;
$

cat4b.ps.png

cat4b.ps.png (2.36 KiB) Viewed 3498 times

P.P.S:
I recently labeled my three 4S 1300mAh 95C lipos with 1/2/3. Since the one for my second raspcatbot was not used for a while, I will cycle the lipo use (1->2->3->1->...) for upcoming raspcatbot test drives in order to have evenly distributed numbers for use and charging.

[HermannSW]

So now overall setup, braking as well as caterpillar mechanics are fine.

For later real line following an exact understanding of the correlation of ov7251 frame position and real position is needed. Today I just started and placed robot just before a hardboard plate. And I placed a long lath on left and right of robot:



Then I captured frames with "./raw_callback 400 200 5", that is 4ms shutter time, 200 frames, mode5 320x240@204fps. Because of the much longer exposure no spread is needed to make the frame details visible (bottom of frame is exactly at 3cm mark of 30cm long ruler):

0199.pgm.png

0199.pgm.png (49.88 KiB) Viewed 3477 times

The camera does not sit perfect, otherwise the middle of black line would be at x-coordinate 160 at bottom as well at top. Bottom middle of (160,188) is 174, top middle of (165,172) is 168.5. Before investing time in changing camera position/direction I will go with what I have, at least for next task of following straight black line until it ends (first safe with cable car mode, later without cable through both M3 nuts below the robots two gear motors.

[HermannSW]

The 320x240 frames do not look that distorted.
I learned that I will have to do camera calibration for being able to project 3D world coordinates to 2D frame coordinates and vice versa.
I did that yesterday with HQ camera as warmup, undistored frame created looks impressive for the much distorted camera frame:
viewtopic.php?f=43&t=272658&p=1663011#p1662752
I do not plan to undistort frames for raspcatbot because I only have less than 5ms processing time per frame.
The mapping between world and frame coordinates is what I am after.

[HermannSW]

Maximal speed measured for raspcatbot was 2.56m/s or 9.21km/h sofar.

I found article "3D Printed Train Set Aims For Speed":
https://hackaday.com/2020/05/12/3d-prin ... for-speed/

Maximal model train speed was 22.5km/h, slightly above 18km/h raspcatbot target speed.
I extracted animated .gif from youtube video.
Train front view at that speed gives an idea how later raspcatbot will "see" the world:


View will be different though, because of raspcatbot ov7251 camera slope, with frame center 12cm ahead robot on ground:

raspcatbot.ov7251.slope.jpg

raspcatbot.ov7251.slope.jpg (63.94 KiB) Viewed 3363 times

[HermannSW]

After playing a lot with new HQ camera, now its time to make progress with raspcatbot.

New tool raw_callback_fb1 displays camera view on onboard 320x240 display, with this commit:
https://github.com/Hermann-SW/MIPI_Came ... 9a48cb926d
The tool has three modes:

• as is
• normalized
• thresholded

The new tool is demoed in this youtube video:
https://www.youtube.com/watch?v=MvRFTTl ... e=youtu.be

raw_callback_fb1.yt.jpg

raw_callback_fb1.yt.jpg (57.17 KiB) Viewed 3301 times

P.S:
Comparison of the three modes mentioned (3rd with threshold=80):

[HermannSW]

raspcatbot work is temporarily stopped.

First by work with new Raspberry HQ camera (raspiraw, 239s long exposure, ...):
viewtopic.php?f=43&t=277397&p=1680052#p1680052

And later by Raspberry Pi microscope; reversed mounted M12 180° lens in CStoM12 adapter ring allows for 0.21µm/px resolution 12MP frames, just above best resolution optical microscopes can do at all:
viewtopic.php?f=43&t=210605&p=1681800#p1678792

After superglueing stepper motor to microscope stand wheel and using microscope two-axis sliding-table, I am working on getting 5µm per step in xy directions and 8.8µm per step in z direction down to 1µm precision by using micro-stepping for the three stepper motors:
https://forum.arduino.cc/index.php?topic=691123.0

Anyway, raspcatbot work will continue (later), for now this is "you see me, I see you" in home office

20200622_173449.20%.jpg

20200622_173449.20%.jpg (23.56 KiB) Viewed 2976 times

[HermannSW]

It was a long break, so much to play with, with HQ camera, microscope, cheap telescope with HQ camera, Picos, ...

This thread was locked by lock bot, but I followed mahjongg's instruction and tried to get it unlocked. Thanks for unlocking.

I cleaned up and added stuff to my personal website, and especially the raspcatbot section made me want to continue with raspcatbot work.


Recently I posted in another thread on KISS algorithms I used for robotics (Keep It Simple, Stupid). Then I realized that I made use of KISS principle in hardware for robotics as well in the past:

1) Back in 2015 I tested how fast I can get little DC motors going. I ended up with more than 18m/s -- inhouse. The trick was to use a nail in center of my motor test station, and a hole in center of wood with motors on opposite sides of wood. Small (Arduino) microcontroller did the speedup and braking. I used Raspberry camera (v1 at that time) to get 90fps videos of the >50 test runs documented:
https://forum.arduino.cc/t/motor-test-s ... /319852/25


2) Here in raspcatbot thread I used KISS hardware principle as well, in getting test runs for testing some aspects while still not having developed robot control software to keep robot on the black line. The two M3 screws I superglued below the two caterpillar robot motors allowed for cable car mode easily:



Now I want to see higher speeds than the 2.5m/s I was able to see with acceleration and full stop on 4.5m test area in room. During update of personal website I realized that the 12V 1500rpm motors gear motors (I replaced the original 330rpm caterpillar robot motors with), overpowered with 16.8V from a 4S lipo did show 6.04m/s free running already (1774rpm with 65mm wheel ⌀), although target speed I had in mind was 5m/s (18km/h). The 6m/s match nearly the train front camera view shown in raspcatbot section on personal website:
https://stamm-wilbrandt.de/en/#raspcatbot

So I remembered the cycle principle mentioned above for motor test station. I just weighed the current version of raspcatbot shown in previous posting, and measured 1097g(!). With 1kg running with >3m/s around a fxed center point, quite some centrifugal force happens at rotation center, so that has to be very stable.

We recently made a new terrace with slippery floor tiles (a slowworm on terrace wanted to escape me catching it, but all movements were sideways only, no forward move). But the foam rubber I glued on raspcatbot's wheels should be a good countermeasure for that. Plan is to go with 1m radius first. I found a long and thin screw and screwed it just at joint of 3 floor tiles, and it feels remarkably stable:

20210626_203613.15%.jpg

20210626_203613.15%.jpg (40.66 KiB) Viewed 1264 times

A part of a photo shown in this thread earlier, of raspcatbot jacked up full speed running, shows that only the wheel connected with motor really moves. Both other wheels don't move:

raspcatbot_jacked_up_running.png

raspcatbot_jacked_up_running.png (229.11 KiB) Viewed 1264 times

And I realized that there are low, unused small holes in aluminum construction of robot accessible from the side!

raspcatbot_side_holes.png

raspcatbot_side_holes.png (196.83 KiB) Viewed 1264 times

Plan is to buy thin steel wire rope on Monday and use that to connect two holes in robot aluminum with screw in terrace and have some slow and then faster test runs to see if the screw idea works ...

[HermannSW]

I bought 10m of smallest ⌀ steel wire rope I could find in our building center -- 2mm.
The packaging has a picture of balancing weight and "40 kg" on that.
I hope that will suffice to not tear with fast moving 1kg robot radially around screw fixated in terrace.

20210628_180215.15%.jpg

20210628_180215.15%.jpg (96.63 KiB) Viewed 1206 times

Before doing tests on terrace, robot needs to be freed from dust of 1 year on bookshelf, broken cables need to be fixed (front light is not working), Pi3A+ needs to be inspected, and I need to look into code to find out details about controlling the two motors. When all that is done, raspcatbot will go to terrace.