Go Down

Topic: Cheap caterpillar robot platform restrained at custom office (Read 3088 times) previous topic - next topic

HermannSW

Instead of IRF520 Mosfet motor controllers I used the prototype shield with  TB6612FNG motor controller from the right Arduebot in previous posting photo. Although the motor shield v2 is based on the exact same motor controller, the stability issues are completely gone after getting rid of the motorshield v2! And my shield has two goodies that come in handy: a self-made display comnnector (which I use for a 320x240 TFT display) and a SD card reader from that display that becomes usable for Due data reading and writing. Here is today's "self-reflection" photo of my "Arduecat" (Arduino Due Caterpillar robot), click for details (the image gets read from the SD card):


I did choose "Arduecat" as name after Google search for it resulted in a single hit (example for a Caesar cipher).

Currently there is only one hardware problem, the right side motor does not run for PWM<128, while the left runs for much lower values. I tried some more medium speed U-turn runs, but a delay is not reliable for turning by a fixed degree. So I made use of the ultrasonic distance sideways sensors to make a 180° U-Turn when driving parallel to a wall by turning until both sideways sensors show same distance. This did not work as expected, so next step is to add scrolling text output with measured data on TFT display in order to see latest measurements and get an understanding of what measurements resulted in robot stop.

Hermann.

P.S:
Perhaps Arduecat will run in kitchen arena next, like 10 years ago Asuro robots:

The bigger Asuro robot did make 1.8m/s on the straight parts, Arduecat should be able to do much quicker.

P.P.S:
D14-D21 is not inline with D9-D13 on Arduino Uno proto shield used on top of Due, but superglueing front sideways ultrasonic distance sensor onto back sideways sensor worked:


A lot of "#define"s for naming connections:
Code: [Select]
#define TFT_RST 40 // uncomment if you have ILI9340
#define TFT_DC 42 // Command/Data for LCD
#define TFT_CS 44 // Chip Select for LCD
#define SD_CS 3 // Chip Select for SD card

#define VCC0 19
#define trigPin0 18
#define echoPin0 17
#define GND0a 16
#define GND0b 15
#define VCC1 9
#define trigPin1 10
#define echoPin1 11
#define GND1a 12
#define GND1b 13
#define VCC2 38
#define trigPin2 36
#define echoPin2 34
#define GND2a 32
#define GND2b 30

#define PWMB 4
#define BIN2 5
#define BIN1 6
#define STBY 7
#define AIN1 24
#define AIN2 26
#define PWMA 28

HermannSW

Today I received another caterpillar robot platform, this time without problems with custom office:


I do want to place a Raspberry Pi Zero with camera onto Arduecat, later for line following, now for evaluation on how 90fps on robot video looks like, whether vibrations in high speed runs are a problem, ... . But the current Arduecat is quite full already (today I added mini digital voltmeter that runs completely independent of Arduecat's Due):


I knew that motorshield v2 had problems, so I tried with an Arduino Uno and a motorshield v1. Because of high speed and trying to avoid any power spike issues, I decided to control the platform with x/y joystick and long cable (self-made, 4×2m copper cable, taped together):


On the plus side, it really works, and controlling the robot is quite intuitive (at least to me) given the sketch I wrote:
Code: [Select]
#include <AFMotor.h>

AF_DCMotor ml(4); AF_DCMotor mr(3);

int x = 0, y = 0, y0 = 506, x0 = 490, Y, X;

void setup() {
  Serial.begin(57600);

  ml.setSpeed(0);  mr.setSpeed(0);
  ml.run(RELEASE); mr.run(RELEASE);
}

void loop() {
  x = analogRead(A0); y = analogRead(A5);
  
  if (y < y0) {
    Y = map(y0 - y, 0, y0, 0, 255);
    ml.run(BACKWARD); mr.run(BACKWARD);
  } else {
    Y = map(y, y0, 1023, 0, 255);
    ml.run(FORWARD);  mr.run(FORWARD);
  }

  if (x < x0) {
    X = map(x0 - x, 0, x0, Y, 0);
    ml.setSpeed(X); mr.setSpeed(Y);  
  } else {
    X = map(x, x0, 1023, Y, 0);
    ml.setSpeed(Y); mr.setSpeed(X);  
  }

#if 0
  Serial.print("Y = " );   Serial.print(Y);
  Serial.print("\t X = "); Serial.println(X);
#endif

  delay(2);
}


Here is a youtube video of a demo I did with Android camera lying on catwalk in our living room, 2m above ground:
https://www.youtube.com/watch?v=FkLj-K7Rl6Y


On the bad side, after some time the robot did not move nice, and later it stopped to move at all. It turned out that two of the three L239D motor controllers of v1 shield get very hot. Definitely too much current.

But after some phase of no activity (just release joystick into center position, the robot stands still without motor movement) all works fine again (the L293Ds have become cold again then)- So for the camera test drives the current solution seems to be good enough.

Hermann.

P.S:
The patform battery box was too small for new 3S 1000mAh Lipo, but unlike Arduecat I did not want to waste much platform space for the Lipo. Therefore I drilled a "small" hole into battery box top and did cut out some of the yellow platform. That allowed to put the 3S Lipo (vertically) into battery box - well, 70% of it ;-)

HermannSW

The robot platform sometime did funny things, here it took (joystick) control away from me ;-)


Next I found out how to mount tilt system with Raspberry camera, and the Raspberry Pi Zero itself on two long spacers, so that the flexible camera cable has pace below Pi Zero to move fore and back. I learned that the Pi Zero could not be powered by Arduino Uno GND/5V - it works for some time, but whenever Arduino Uno makes camera servo move, the Pi Zero did reset. So I did power Pi Zero wth 5V from LM2596:


Experiments revealed that camera inclination of 35° was good to see ground in front from 8cm up to 1m ahead:


I have always done 90fps slowmo videos with 640x480 resolution, because I could. In between I realized that 320x240 @90fps might be sufficient as well, at least the lower right 320x240 photo looks not worse than total 640x480 photo:


For some reason the video taking only works when USB to ethernet adapter was "onboard"?!?


I bought a Pi Zero W when it was first available, and it worked really nice. I killed it after one week, most likely by 5V cable unplanned contact with Zero W pins. I am waiting for my 2nd Pi Zero W to arrive next week -- that way I will definitely not need an onboard ethernet anymore (and streaming video for 1st person view will become possible).

This is first "fast" driving 90fps slowmo video taken by the onboard Raspberry Pi Zero and camera. It is surprisingly "stable", I was not sure what the high speed caterpillar platform movement would do to the video. Remember that the video gets played slowed down by factor 90/25=3.6:
https://www.youtube.com/watch?v=AskkaUFikT4


I am not sure whether there was a wall crash at the end of first fast forward phase, or whether robot stopped just before the wall. If, then it was the camera tilt system.

Speeds (determined by counting frames bewteen the tape stripes on ground 50 apart):
  • 1.40m/s from 0-50cm (32 frames)
  • 1.87m/s from 50-100cm (24 frames)
  • 2.14m/s from 100-200cm (2×21 frames)

I use the Pi Zero in "slave" mode, and the Uno signals when a video should be taken. Therefore a 5V/3.3V level shifter was necessary. I do use Servo2 pins for controlling the camera servo. But Servo1 pins (D10/5V/GND)were available. I did solder female headers below the level shifter and was able to just put the level shifter onto Servo1 pins:


Finally I added a soldered LED/1kΩ pair to Pi Zero, that is turned on by Pi while raspivid runs:


I changed the previous sketch for robot platform joystick control only slightly. The triggering is done in "setup()", so that the request for taking a video is done by pressing reset key:
Code: [Select]
#include <AFMotor.h>
#include <Servo.h>

Servo myservo;

AF_DCMotor ml(4); AF_DCMotor mr(3);

int x = 0, y = 0, y0 = 506, x0 = 490, Y, X;

void setup() {
  Serial.begin(57600);

  ml.setSpeed(0);  mr.setSpeed(0);
  ml.run(RELEASE); mr.run(RELEASE);
  
  myservo.attach(9);
  myservo.write(60);

  // signal Raspbery Pi zerop to start camera (raspivid ...)
  pinMode(10, OUTPUT);
  digitalWrite(10, HIGH);
  delay(2000);
  digitalWrite(10, LOW);
}

void loop() {
  x = analogRead(A0); y = analogRead(A5);
  
  if (y < y0) {
    Y = map(y0 - y, 0, y0, 0, 255);
    ml.run(BACKWARD); mr.run(BACKWARD);
  } else {
    Y = map(y, y0, 1023, 0, 255);
    ml.run(FORWARD);  mr.run(FORWARD);
  }

  if (x < x0) {
    X = map(x0 - x, 0, x0, Y, 0);
    ml.setSpeed(X); mr.setSpeed(Y);  
  } else {
    X = map(x, x0, 1023, Y, 0);
    ml.setSpeed(Y); mr.setSpeed(X);  
  }

#if 0
  Serial.print("Y = " );   Serial.print(Y);
  Serial.print("\t X = "); Serial.println(X);
#endif

  delay(2);
}


On the Raspberry side this is the "camera_slave" bash script that does what is needed, and it gets started in .bashrc after reboot:
Code: [Select]
pi@raspberrypi02:~ $ tail -3 .bashrc
# ~/clkl

./camera_slave
pi@raspberrypi02:~ $ cat camera_slave
#!/bin/bash

while (true)
do
  if ((`gpio read 0`))
  then
    while ((`gpio read 0`))
    do
      sleep 1
    done

    f=`date +%Y-%m-%d_%X`.h264
    gpio write 11 1
    raspivid -w 640 -h 480 -fps 90 -t 5000 -o "$f"
    gpio write 11 0
  else
    sleep 1
  fi
done
pi@raspberrypi02:~ $


Hermann.

HermannSW

Today I let the robot run on living room floor tiles.
2.36m/s (8.5km/h) onboard video is surprisingly stable on floor tiles.
90fps slowmo video played slowed down by factor of 90/25=3.6:
https://www.youtube.com/watch?v=ZxDrcYhhkQU&feature=youtu.be


Speed on the first 10 floor tiles (determined by youtube video single frame counting):
Code: [Select]
0.315/(20/90)   = 1.42 m/s
0.315/(16/90)   = 1.77 m/s
0.315/(14/90)   = 2.03 m/s
0.315*2/(26/90) = 2.18 m/s
0.315*2/(25/90) = 2.27 m/s
0.315/(12/90)   = 2.36 m/s
0.315/(12/90)   = 2.36 m/s
0.315/(15/90)   = 1.89 m/s


By a previous wall crash the camera tilt system got changed, now camera inclination is 45° (just realized that), and camare cannot see farther than 50cm ahead (instead of 1m ahead before). This is a reason why tilt servo might remain permanently on robot platform: on startup Arduino and Pi Zero can determine the inclination to be used by some sample photos instead of a fixed servo value. That way crashes would not change the camera inclination on startup. Another option would be to move camera back onto robot so far, that a wall crash would hit the front wheels instead of the camera. SInce 35° inclination did not show the 8cm before front wheels this may even positively affect the video.

Hermann.

HermannSW

Outdoor was never an option for my wheel type robots.
Just gave caterpillar robot some outdoor activity.
Worked fine until robot drove too fast for me and I tramped on joystick cable, soldering needed.

This is the first outdoor run 90fps slowmo video, uphill with incline of 5°:
https://www.youtube.com/watch?v=doTbNWsmP_8


This is downhill, remember that youtube video as well as animated .gif show video slowed down by factor 90/25=3.6:
https://www.youtube.com/watch?v=-LzP9nANSOU


Maybe (in far future) caterpillar robot will drive autonomously my 900m "around house" track. A 5:19min video of that track can be found here (German language page).

Hermann.

HermannSW

I know I said ... that I will not do high speed robot runs without making use of sensors.

But after tramping on joystick cable yesterday the test platform was "free of cords".
So I programmed full speed 180° turn(s) again and made two videos of the same run.

The 1st with Android camera, it shows what happened, including sound (in youtube video).
This shows what happened in correct speed:
https://www.youtube.com/watch?v=O2TfISReN8k


This is 2nd video (90fps)  from robot onboard Raspberry camera (slowed down by factor of 90/25=3.6):
https://www.youtube.com/watch?v=Slade8HQ7LI


The room was lit from 3 lights, and Android video shows bright frames.
But that was not enough for 90fps video, looks quite dark.

So what should have happened in videos:
  • robot accelerates from stand still to full speed and keeps it
  • short before dog chew bone do full speed U-turn
  • keeping full speed drive back
  • do a second full speed U-turn
  • keep full speed drive back
  • full stop


As you can see the 1st U-turn was overshooted.
Then the robot drove into room crossing ethernet cable.
That cable reduced robot turn speed and this time U-turn did not reach 180°.
Slowed down the robot then drove over some cables until stop.

Hermann.

For taking the video on Raspberry Pi Zero I used new "camera_slave.c" posted here:
https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=181504

This is the sketch used for the videos:
Code: [Select]
#include <AFMotor.h>
#include <Servo.h>

Servo myservo;

AF_DCMotor ml(4); AF_DCMotor mr(3);

#define m 255

void setup() {
  int i;
  
  Serial.begin(57600);

  pinMode(10, OUTPUT);
  digitalWrite(10, LOW);

  ml.setSpeed(0);  mr.setSpeed(0);
  ml.run(RELEASE); mr.run(RELEASE);

  ml.run(FORWARD);  mr.run(FORWARD);

  myservo.attach(9);
  myservo.write(90);
  delay(500);
  myservo.write(50);

  delay(1500);
  
  digitalWrite(10, HIGH);
  delay(500);

  for(i=128; i<m; ++i) {
    ml.setSpeed(i); mr.setSpeed(i);  
    delay(6);
  }
  delay(400);
  ml.run(BACKWARD);
  delay(320);
  ml.run(FORWARD);
  delay(1000);
  ml.run(BACKWARD);
  delay(320);
  ml.run(FORWARD);
  delay(1000);
  ml.setSpeed(0); mr.setSpeed(0);  

  digitalWrite(10, LOW);
}

void loop() {
}

HermannSW

Yesterday's 90fps video had some dark phases, so I wanted to know how line following scenario I build the robot(s) for looks like with 90fps video. 10 years ago I prepared for Robotchallenge 2007 in Vienna and did some prep work. I analyzed youtube video material from the years before and run results to get test courses and an idea of other robot speeds. I created a toolbox to easily setup a test course from tiles, and I can reuse that now here (German language page):
https://stamm-wilbrandt.de/RobotChallenge/

This is the 2006 Qualifying test course of RobitChallenge:



Today I did setup that course again, this time with 50cm×50cm hard fiber tiles and not with styrofoam tiles as 10 years ago (click for details):


I have to say that controlling caterpillar robot with joystick as I did the last days was not that difficult. But trying to follow the line definitely was really difficult for me (the first 27s of 90fps slowmo video without much activity are 7.5s in reality only), as you can see in the video. Good that the robot will do the line following alone, and much faster ;-) So this is the 1:39min youtube slowmo video (of real 27.5s):
https://www.youtube.com/watch?v=yE5liAQEJdk&feature=youtu.be


Below sketch contains advanced camera control. Since the joystick switch does not work, recording here gets started when moving joystick completely to the left, or stopped when completely moved to the right. But only with no Y axis (speed).

Hermann.

Code: [Select]
#include <AFMotor.h>
#include <Servo.h>

Servo myservo;

AF_DCMotor ml(4); AF_DCMotor mr(3);

int x = 0, y = 0, y0 = 506, x0 = 490, Y, X;

void setup() {
  pinMode(10, OUTPUT);
  digitalWrite(10, LOW);

  Serial.begin(57600);

  ml.setSpeed(0);  mr.setSpeed(0);
  ml.run(RELEASE); mr.run(RELEASE);
  
  myservo.attach(9);
  myservo.write(90);
  delay(500);
  myservo.write(50);
}

void loop() {
  x = analogRead(A2); y = analogRead(A4);
  
  if (y < y0) {
    Y = map(y0 - y, 0, y0, 0, 255);
    ml.run(BACKWARD); mr.run(BACKWARD);
  } else {
    Y = map(y, y0, 1023, 0, 255);
    ml.run(FORWARD);  mr.run(FORWARD);
  }

  if (x < x0) {
    X = map(x0 - x, 0, x0, Y, 0);
    ml.setSpeed(X); mr.setSpeed(Y);  
  } else {
    X = map(x, x0, 1023, Y, 0);
    ml.setSpeed(Y); mr.setSpeed(X);  
  }

  if (abs(y - y0) < 15) {
    if (x < 25) {
      digitalWrite(10, HIGH);  // start recording
    } else if (x > 999) {
      digitalWrite(10, LOW);   // stop recording
    }
  }
  
#if 0
  Serial.print("Y = " );   Serial.print(Y);
  Serial.print("\t X = "); Serial.println(X);
#endif

  delay(2);
}

HermannSW

Did other outdoor runs.

This is full HD (1920x1080) 30fps video:
https://www.youtube.com/watch?v=slxG7Y09XXE

The advantage of 30fps is that youtube player as well as makeagif show the video nearly at real speed (factor 25/30 = 0.83 slower).
Slightly downhill the robot did more than 8km/h and I had to run and do joystick control:



Here is a 90fps slowed down run, 91m downill (5°) in 2:15min/3.6 is 8.7km/h:
https://www.youtube.com/watch?v=S-MtuM0nQCU

At the end of the video the robot overturned and ended upside down ;-)


Hermann.

HermannSW

The last video already demonstrated that outdoor can be dangerous.

Small stone or small gully cover are really dangerous.
Passing this the robot crashed, turned 90° and by that caterpillar moved out of wheel check rail:


Living obstacles have to be passed as well, here a snail (90fps slowmo video):


And here robot luckily passed pile of poo first (30fps video, shown factor 0.83 slower than real):


But then it did hit a puddle resulting in waterdrops in the air.
Luckily none of those did hit Raspberry camera lense or electronic components.

Hermann.

P.S:
"tiny" caterpillar robot crosses "big" road (30fps video palayed at 25fps, factor 0.83 slower than real):

HermannSW

The U-turn video above demonstrates that even in a bight lit room a 90fps video looks a bit dark. The same is true for the line following video, the 90fps video looks darker than the Android phone camera photo of the scene. This is most likely because 1/90th of a second is not much time to sum up brightness with camera.

Ten years ago I found a solution to be independent of light conditions with brightness sensors for linefollowing, I used infrared LEDs instead red LEDs (they even matched the photoresistors spec much better). Yesterday I received my first Raspberry Pi NoIR camera and did some first experiments with two matching 3W infrared LEDs. Later I tested out the line following scenario, click for more details:


So basically the photo is the same, in complete darkness and with bright light in the room (the LEDs have photo sensors adjusting the LED brightness to surrounding). The U-turn in nearly 1m distance of camera can be seen easily at top of both photos. Slogan: "bring your own (infrared) light".

Next steps:
  • learn how to write gstreamer plugin
  • do image preprocessing in plugin
  • feed back results somehow (as image or otherwise) to Arduino for line following


Hermann.

HermannSW

You can click on below photos for more details.

Yesterday I did mount the new Raspberry NoIR camera on my prototyping caterpillar platform:


I had to cut away some plastic parts of the tilt camera holder, and finally found a solid mounting position, where I needed to drill one whole only for 3rd screw. Here are the details:


With the normal Raspberry camera the flat cable had a nice S-shape below Pi Zero W:


Unfortunately the Raspberry NoIR camera has connector on other side as normal camera, so that the flat cable need a 180° turn below Pi Zero W -- not nice, but seems OK for now, perhaps later the Pi Zero will be mounted turned 180° on the caterpillar platform to get back the nice S-shape:


This was a first test photo (2592x1944) taken with shutter open, there are colors:


After closing shutter this was taken in darkness, just lit by the 3W infrared LED mounted with NoIR camera:



Hermann.

P.S:
I got Pi Zero W streaming NoIR video to laptop working, see this posting for details:
https://www.raspberrypi.org/forums/viewtopic.php?p=1162266#p1162266

HermannSW

I added an adxl345 accelerometer to the caterpillar robot.
Because I wanted to store many measurements I connected that sensor to the Pi Zero W, and not to the Arduino Uno:


Find the modified Raspberry "camera_slave_adxl345.c" program in this posting.

The capture program does video recording as done before, and during video recording it stores the 16bit x-direction only values read into a ".data" file. This is a short 90fps infrared slowmo video I took for the data analyzed below. I did pull the joystick full for maximal backward acceleration, kept it some time and finally moved it to center position which sets both motor speeds to 0.
https://youtu.be/JR2UcFlaQkU

And this is the data captured during that robot run, displayed 16bit wise:
Code: [Select]
$ od -tx2 2017-05-16_20:58:51.data
0000000 0008 0008 0008 0008 0006 0007 0008 0007
0000020 0007 0007 0008 0007 0008 0008 0007 0008
0000040 0007 0006 0007 0007 0007 0009 0007 0008
0000060 0007 0007 0008 0007 0007 0007 0007 0007
0000100 0008 0007 0007 0006 0008 0007 0007 0008
0000120 0008 0008 0006 0008 0008 0008 0008 0008
0000140 0007 0007 0007 0008 0008 0006 0007 0007
0000160 0007 0008 0007 0008 0006 0007 0007 0006
0000200 0007 0006 0008 0007 0008 0007 0008 0008
0000220 0008 0006 0008 0008 0008 0007 0007 0007
0000240 0007 0006 0007 0008 0008 0007 0007 0007
0000260 0007 0007 0006 0008 0007 0007 0007 0007
0000300 0007 0008 0007 001e 00cb 0072 0059 00a2
0000320 006a 0031 0049 ffe1 007b 0062 0041 006e
0000340 004f 005b 0057 004c 0064 ffeb 0017 004a
0000360 001f 0049 0082 0056 0015 0075 0082 007b
0000400 005c ffa6 00e7 ffdb 0060 0037 000d 0068
0000420 0011 0027 fff2 0058 0008 0039 00b3 ffc1
0000440 0070 0087 fff1 fff1 0030 ffd8 ff0c ffc9
0000460 ff64 00ba 00b5 ff37 00e3 ffc0 00d6 0045
0000500 ffb3 ff82 0030 002a ff6d 0054 0083 ffb4
0000520 ff81 0118 ff7c 00d0 003c fffc 0045 fef3
0000540 ff8c ff40 ff43 ff3e ffc6 0059 ffca ff8e
0000560 ffe1 ffe3 ffea ffe7 ffad ff2f ff8f ffbf
0000600 ff7c ffbd ff0c ffcc fff4 ffe2 003b ff78
0000620 ff92 ff52 ffcb ffe0 ffd5 ffbb ffa9 ffe6
0000640 ffd4 ffc6 ffcf ffb6 ffac ffba ffbb ffd7
0000660 ffd4 ffb2 ff82 ffd3 ffda ffcc ffaf ffd0
0000700 ffe4 ffdc ffd3 ffc0 ffda ffff 0004 fffe
0000720 0003 0003 000b 000f 000f 0010 000e 000c
0000740 0005 0000 ffff 0001 0005 0008 0007 0004
0000760 0000 0001 0003 0005 0004 0002 0001 0001
0001000 0003 0004 0003 0002 0002 0002 0002 0004
0001020 0003 0002 0001 0002 0002 0004 0004 0001
0001040 0002 0001 0004 0004 0004 0003 0003 0003
0001060 0005 0004 0004 0002 0003 0002 0003 0003
0001100 0002 0002 0003 0004 0003 0001 0002 0003
0001120 0003 0002 0004 0003 0004 0004 0004 0004
0001140 0005 0004 0003 0003 0003 0004 0004 0004
0001160 0002 0003 0003 0004 0004 0002 0003 0003
0001200 0003 0003 0003 0002 0002 0004 0003 0003
0001220 0002 0003 0003 0003 0003 0002 0002 0003
0001240 0003 0003 0003 0002 0002 0003 0003 0003
0001260 0002 0004 0005 0002 0002 0003 0002 0003
0001300 0003 0003 0003 0001 0002 0002 0003 0003
0001320 0002 0003 0003 0003 0004 0003 0003 0002
0001340 0003 0003 0002 0002 0003 0003 0004 0001
0001360 0002 0004 0004 0002 0002 0003 0003 0003
0001400 0004 0002 0001 0002 0003 0004 0002 0002
0001420 0003 0003 0003 0003 0003 0002 0002 0002
0001440 0004 0003 0003 0003 0003 0003 0004 0003
0001460 0002 0003 0004 0002 0004 0003 0002 0003
0001500 0002 0002 0002 0004 0002 0003 0002 0002
0001520 0002 0002 0003 0004 0001 0003 0002 0002
0001540 0003 0002 0004 0003 0003 0002 0002 0002
0001560 0003 0002 0003 0003
0001570
$  


The values are a bit shaky in between, and I was really surprised on the maximal values.

In robot backward direction the x-direction gives positive values, maximum is 0x0118:
Code: [Select]
$ od -tx2 2017-05-16_20:58:51.data | grep " 01"
0000520 ff81 0118 ff7c 00d0 003c fffc 0045 fef3
$ od -tx2 2017-05-16_20:58:51.data | grep " 0[2-9a-f]"
$


On braking robot the acceleration is in the other direction, with negative values, maximum is 0xfef3:
Code: [Select]
$ od -tx2 2017-05-16_20:58:51.data | grep " fe"
0000520 ff81 0118 ff7c 00d0 003c fffc 0045 fef3
$ od -tx2 2017-05-16_20:58:51.data | grep " f[0-9a-d]"
$


On bottom right of adxl345 spec page 17 this is stated on resolution:
Quote
When this bit is set to a value of 1, the device is in full resolution
mode, where the output resolution increases with the g range
set by the range bits to maintain a 4 mg/LSB scale factor.
The test program I used showed values 256-258 for z-direction which corresponds to 1g vertical acceleration.

The maximal (backward) acceleration 0x0118 correspnds to (256+16+8)*0.004 = 1.12g.
I have no idea currently whether that is high or not (robot drives fast up to 2.36m/s, and motors are really loud).

Hermann.

HermannSW

I corrected and improved the code to read x-direction acceleration values in this new posting:
https://www.raspberrypi.org/forums/viewtopic.php?p=1164036#p1164036

With that I did a new robot measurement run, longer, more speed, higher acceleration.
This is the 90fps slowmo video caterpillar robot did this time (slowed down by factor 90/25=3.6 on youtube player):
https://www.youtube.com/watch?v=St_FC4opp4s&feature=youtu.be

It must be the joltings in that run that raised maximal acceleration in both directions above 3g.

Maximal backward direction value was 0x3aa, corresponding 3.66g:
Code: [Select]
$ od -tx2 2017-05-17_19\:01\:15.data | grep " 03"
0000660 0096 ffa7 03aa 0049 0080 fc88 0097 00d1
$ od -tx2 2017-05-17_19\:01\:15.data | grep " 0[4-9a-f]"
$ od -tx2 2017-05-17_19\:01\:15.data | grep " [1-7]"
$


Maximal forward direction value was 0xfc88, corresponding 3.47g:
Code: [Select]
$ od -tx2 2017-05-17_19\:01\:15.data | grep " fc"
0000660 0096 ffa7 03aa 0049 0080 fc88 0097 00d1
$ od -tx2 2017-05-17_19\:01\:15.data | grep " f[ab0-9]"
$ od -tx2 2017-05-17_19\:01\:15.data | grep " [89a-e]"
$


The "real" (not jolting based) maximal backward direction acceleration was 1.33g (0x0155):
Code: [Select]
$ od -tx2 2017-05-17_19\:01\:15.data | grep " 01"
0000540 00a9 0043 003a 0043 00a9 010b ff71 0127
0000600 0155 00e4 0082 0051 ff97 0098 00de 0047
0000700 014e 0182 fff6 0090 ffad ffa4 0030 00b4
$  


This is the data recorded for the run:
Code: [Select]
$ od -tx2 2017-05-17_19\:01\:15.data
0000000 0000 0001 0001 0001 0001 0000 0001 0001
0000020 0000 0001 0001 0000 0001 0001 0000 0001
0000040 0001 0000 0001 0001 0002 0001 0001 0000
0000060 0000 0000 0000 0001 0001 0001 0000 0001
*
0000120 0000 0000 0000 0001 0001 0001 0000 0000
0000140 0000 0000 0001 0000 0001 0001 0001 0001
0000160 0001 0001 0001 0001 0001 0000 0000 0000
0000200 0001 0001 0000 0000 0001 0000 0001 0000
0000220 0000 0001 0001 0001 0000 0000 0001 0000
0000240 0001 0000 0001 0000 0000 0001 0001 0000
0000260 0000 0000 0001 0000 0001 0000 0001 ffff
0000300 0001 0000 0001 0000 0000 0001 0000 0001
0000320 ffff 0001 0000 0001 0001 0000 0000 ffff
0000340 0001 0002 0001 0000 0000 0000 0000 ffff
0000360 0000 0000 0001 0000 0000 0001 0001 0002
0000400 0000 0002 0000 0001 0000 0001 0000 0006
0000420 003a 0095 00a6 0064 0083 0055 0058 0078
0000440 0079 0038 fff4 004c 007b 001d 005d 0048
0000460 0048 008e 0054 00e2 ff5c 005b 004a 0011
0000500 0065 fff9 0048 ffee 0023 0079 0053 0092
0000520 00d6 009d 0091 009d 0059 005c 0097 005e
0000540 00a9 0043 003a 0043 00a9 010b ff71 0127
0000560 0077 ff7d 00e6 fff6 ff06 ff31 ffc4 ff5b
0000600 0155 00e4 0082 0051 ff97 0098 00de 0047
0000620 ffca fff8 004c ff97 00d4 ffe6 006d ff68
0000640 0034 005e fe94 0069 0098 0084 0215 fffc
0000660 0096 ffa7 03aa 0049 0080 fc88 0097 00d1
0000700 014e 0182 fff6 0090 ffad ffa4 0030 00b4
0000720 fff2 ff98 ff2d ff1a 005e ff7c ff55 ffc3
0000740 ff0f ffb5 ff18 0065 ff84 ffd7 fec8 ff97
0000760 000a ff8f ffc6 ffef ff33 ffc8 0067 ffd2
0001000 ffc7 006f ffb5 ff69 001e ffd4 ff15 fee5
0001020 ff6b ffb4 ff98 ffb7 ff8e ffa8 ffb5 ff9d
0001040 0017 ff88 ffa5 ffcb ff91 ffe4 ff7d ffa8
0001060 fffc ffa7 0010 000b ff9d ffce ffb8 fff8
0001100 ffd5 ffcc ffc8 ffdf ffd9
0001112
$


Hermann.

P.S: This run was done with fully loaded 3S LiPo (12.5V)


HermannSW

I wanted to see more measurements than 100/sec (because of delay(10)).

Just for this I removed the delay, and wrote timestamps at microsecond resolution into a 2nd file.
Find the diff below, and the converted .csv file from both files attached.

I did another run, this time on a more flat underground to reduce joltings:
https://www.youtube.com/watch?v=HGxlL1D-k8g&feature=youtu.be


The time deltas between successive measurements were in range [0.00529..0.015123] seconds, with mean of 0.000601 seconds. This corresponds to 1664Hz on average. The datasheet says that ADXL345 measurement rate is in range [6.25..3200] Hz. Definitely 3200 is not done in the measurements attached. As can be seen here on raw measurements several measurements show the same value:
Code: [Select]
...
0021140 00cd 00cd 00cd 00f4 00f4 00f4 00f4 00f4
0021160 00f4 00f4 00f4 00f4 00f4 00f4 00f4 00f4
0021200 00f4 00f4 00f4 00f4 fed7 fed7 fed7 fed7
0021220 fed7 fed7 fed7 fed7 fed7 fed7 fed7 fed7
0021240 fed7 fed7 fed7 fed7 fed7 0110 0110 0110
0021260 0110 0110 0110 0110 0110 0110 0110 0110
...


Minimal measured acceleration was -2.068g, maximal acceleration was 1.92g.
OK, a picture says more than 1000 words, click diagram for details:


Hermann.

Diff of previous and current Raspberry camera slave program:

Code: [Select]
$ diff camera_slave_adxl345.c camera_slave_adxl345_time.c
48c48
<   FILE *tgt=NULL;
---
>   FILE *tgt=NULL, *tgt2=NULL;
74a75,76
>       struct timeval t0, t1;
>       gettimeofday(&t0, NULL);
87c89
<  
---
>
89a92,97
>       strftime(buf, 100,
>                "%Y-%m-%d_%X.time",
>                localtime(&now));
>  
>       tgt2 = fopen(buf, "wb");
>
91a100,101
>         int d;
>         gettimeofday(&t1, NULL);
94c104,106
<         delay(DELAY);
---
>         d = (t1.tv_sec - t0.tv_sec) * 1000000 + (t1.tv_usec - t0.tv_usec);
>         fwrite(&d, sizeof(int), 1, tgt2);
>         // delay(DELAY);
99a112
>       fclose(tgt2);
$

HermannSW

Today I was out again with caterpillar robot.
Until now caterpillar robot did outside driving on stony ground.
Today I did change that, wanted to drive downhill a grassy hiking path.

In order to protect the camera I built a cage of Lego pieces and screwed that onto the robot platform:


Here you can see the camera lense, cage is big enough to allow for tilting:


OK, this is the hiking path the robot should turn right into:


This is hiking path from my eye height:


Near ground the scene looks a lot more challenging:


Find 90fps NoIR camera slowmo video on youtube, the initial camera view is even more challenging:
https://www.youtube.com/watch?v=vcdQmnmaQ00&feature=youtu.be


In initial picture you can see houses on the other side of creek Wimmersbach at same height (asl), hiking path direction down. Slowmo video is played factor 90/25=3.6 slowed down. In first phase until 12s robot enters downhill part, all is fine. In second phase until 20s robot moves even steeper down until it ends in a steep of grass. Next it moves out of that until it ends at 27s in next steep of grass. From there until the end of the video (1:54min) robot tried to escape forward or backward several times, without success.

I had to wait in between several times because the L293D motor controller is undersized for the motors and gets so hot, that motors did not move anymore. That motor controller was used as a temporary solution, but nothing lasts longer than temporary solutions ;-)

In a next run one cable from joystick wrenched off, I had to solder it again back at home.

I will revisit this downhill hiking path with caterpillar robot, but only after changing motor controller to TB6612FNG proven good on the other caterpillar robot with ultrasonic distance sensors.

Hermann.

Go Up