Arduebot

This thread will be about "Arduebot" (not "Ardubot"), the robot which basically is mostly the Arduino Due board itself.

The peg-board is only used to connect half table tennis ball and two motors with superglue and still be able to quickly change the screwed Arduino board:

This is the upside view, the little box with 3 Lipos giving >12V when fully loaded will be superglued to bottom of peg-board:

Ok, if you look carefully you might say that it is not a Due but a Mega on top of the peg-board.
Reason is that I lost a TB6612FNG motor driver by an explosion today, and sadly the connected Arduino Due as well:

Before loosing the next Due [I still have 2 ;-)] I will give the Mega with L293D motor driver a try.

The main reason I will use a Due is its incredible power (84MHz, with overclocking even 114MHz) and the huge ram size (96KB) compared to all other Arduino models.(see my point of view on Arduino Due versus Arduino Zero). It is even powerful enough to drive a 800x600 monochrome VGA monitor by itself with just 3 resisitors (DueVGA).

Next on the basic form of Arduebot -- that is basically the one of the "Asuro" robot I played with 9 years ago:
https://stamm-wilbrandt.de/#robotics

Asuro was able to run with 0.43m/s maximally by default, tuned it was able to run 1.8m/s with 70mm wheels(!).

I did select the motors and the directly connected wheels (no gears at all) after more than 50 test runs in Motor Test Station (MTS), see this thread:
https://forum.arduino.cc/index.php?topic=331722.0

The best run reported in that thread was 13.59m/s(48.9km/h), but the record was 14.37m/s(51.7km/h):
https://stamm-wilbrandt.de/en/#roboticsArduino

This nice run did show 13.16 m/s(47.37 km/h) maximal, but during the whole run you can see the speed displayed on a live 320x240 LCD speedometer:

In MTS thread it was discussed that gears are normally needed. I liked the idea or leaving away gears and just directly drive the wheels. The 14,8V motor was definitely powerful enough. I did many experiments with many kinds and diameters and types of wheels:

It turned out that the best were the Lego wheels, and among them 20, 24 and 30mm diameter were best. Record was achieved with 24mm, and that is the reason I go with that wheel for now.

Btw, the most important act determining success or failure of a wheel is balancing out the wheel when connecting with superglue to motor axis:

Another aspect discussed in MTS thread was that circular speed is proportionally, but not directly comparable with the potention linear moving speed. I did a small Uno bot based on 12V motors that achieved 9.89m/s(35.6km/h) in MTS. Linearly they achieved only 3.1m/s, good below my target speed of 5m/s(18km/h):
https://forum.arduino.cc/index.php?topic=331722.msg2386890#msg2386890

What the youtube video of the 3.1m/s run in that posting shows is that the robot does run totally straight, without any help with both motors powered fully. I recently tested other bot platforms with a 3rd (or even 4th) small wheel instead of half table tennis ball. These robots cannot go straight, I needed 15 runs with the circular robot to get a slowmo video allowing me to measure linear speed by inspecting slowmo frame by frame.

So the two just mentioned robot platforms were good for two things:

  • don't use a 3rd all-direction wheel, use half of a table tennis ball
  • I was surprised that maximal circular speed of 1.57m/s(5.6km/h) of circular robot was not much better than the linear speed of 1.26m/s(4.5km/h)

I did run both platforms with a V1 Arduino Motor Shield, and tried a nodemcu (ESP8266) motor shield as well allowing for Wifi remote control:

But I am interested in autonomous robot, and would need the ESP8266 not for remote control in Arduebot, bot for streaming video back to laptop. One thing I am interested in is line following (yes, really), but speedy line following. In 2013 "Thunderstorm" robot won a line following contest with 3.1m/s(!) speed on average(!!):

This number is the basis for my maximum linear speed of 5m/s target :wink:

I mentioned the plan of having a camera on Arduebot, and the plan is to use it for linefollowing as well. Taking a picture just before the front of Arduebot would be equivalent to using infrared LED and photo resistors I did back in 2007. But taking more of the picture ahead into account should give Arduebot a view of the line follwing course "in the near future" as well, which should hopefully make control of speedy linefollowing better.

The camera is a cheap ov7660 VGA camera, but for line follwing 320x240 or even 160x120 or 80x60 black&white pictures should be good enough, and thanks to the MHz of the Due processing the pictures in real time should be doable -- next part project will be to learn how to connect and use the ov7670 camera:

Ok, this should be a first posting on Arduebot, will update when new things happen (hopefully no explosions anymore),

Hermann.

I have to admit that I did damage the Mega partially, it needs 5 or 6 flash attempts after powering on before the first flashing succeeds (following flashing is fine then). The Mega showed unexplainable behavior when Vin was powered with 12V. So I replaced the Mega with a working Arduino Due.

The first Arduino USB powered test was good, that is where I was already yesterday (motor voltage VM=5V, VCC=3.3V):

The weight of not completely assembled Arduebot is 150g in total:

Next I did power Vin with 12.12V, leaving VM=5V, no explosion:

I was fearful because of the 12V motor driver explosion yesterday, so next step was to drive VM from a 9.7V block battery, still everything was fine:

Finally I did it, VM=Vin=12.12V -- just in case of an explosion I made a video of that:

It is really loud noise both motors made(!), and I had to press very hard to fixate Arduebot.
The video ends when one wheel got lost :wink:

OK, next I fixated the wheel again with a drop of superglue on the motor axis -- but I was not careful enough, a bit of superglue went down the axis into the motor. I noticed that and immediately powered the motor with the 9.7V block battery. It did not start, but after I rotated the wheel with my fingers it began to start and then turned quickly, but over time it got slower and slower, and I lost that motor. Superglue is a cool material, but also a dangerous!

I will repair tomorrow by cannibalizing one of the same type motors from Motor Test Station, but will stop for now before doing more bad things like killing motors :wink:

Hermann.

It was quite some work to cut off the motor lost to a drop of superglue from Arduebot with a sharp cutting tool:

And it took quite some more time to completely remove the remainder of the connector mini peg-boards between motor and main peg-board from what photo shows (in order to get a flat glueing surface again).

This is first picture from below on completely assembled Arduebot with new motor:

As can be seen the black box with 3 LiPos giving >12V is superglued below main peg-board as well as half the table tennis ball (unfortunately the 4th screw connecting Due and peg-board is inside the half table tennis ball, so whenever Due needs to be changed, the ball has to be removed.

And this is the top view on Arduebot:

I added two blue LEDs on the mini-breadboard in order to have graphical markers that I can turn on/off in [slowmo] videos taken from Arduebot.

I did first runs with Arduebot, but given by the length of the room speed cannot be high.
This is slowmo video I created with 120fps single frame viewer:

The Gist comment describes the exact test setup, summary:

  • with only PWM=99 powered motors linear speed is 1.3m/s
  • same PWM on left and right motor does not result in exact same speed, therefore curve seen

Wait -- just saw that Arduebot was still accelerating during the 1 second PWM=99 phase:

This picture is overlay of movie frame parts at 8.216666s and at 8.499999s, and Arduebot did more than 50cm in that time frame (the two blue LEDs are on border of 50cmx50cm floor tiles). That is 0.5/(8.499999-8.216666)=1.76m/s (6.35km/h) -- again, this is with only PWM=99 (and 12.06V).

The long black straight line might help to get better numbers for higher speeds, just a minimal line follower program with two infrared photo sensors that is optimized to follow straight lines with minimal jiggle -- just measured that living room together with kitchen would give me 9m line in total, for longer lengths I can use the very long straight basement corridors under Böblingen IBM lab in the evening :wink:

Hermann.

It was quite some work to cut off the motor lost to a drop of superglue from Arduebot with a sharp cutting tool:

Use a little hot glue, strong but easy to remove.

zoomkat:
Use a little hot glue, strong but easy to remove.

I will give that a try next time I have to change a motor -- did buy hot glue and hot glue pistol some time ago, but never used it sofar.

Yesterday, after carefully increasing speed and runtime more and more, I did let Arduebot do a run at PWM=255 ... of course that could not be a linear run because of the high speed. I did do same PWM on both motors, the right motor forward, the left motor backward. I did a 120fps slowmo video of that run, and uploaded it to youtube:

The details of the sketch are described in the youtube video description, in the end the run got stopped unplanned by GND cable disconnected from LiPos, but at that time Arduebot was on an unplanned move already, so that power loss was the only reason nothing bad happened and Arduebot stopped a meter away before the bed. The video sequence with blue LED turned on after PWM=255 was reached reminded me on a pyro ground spinner :wink:

Just before loosing power, still in acceleration, Arduebot did (more than) 4.05m/s circular speed.

What I thought was that Arduebot would rotate on center point of line connecting both motor a axis. I was proven wrong by reality, the animate .gif shows 5 frames of the 120fps slowmo, displayed forward/backward at original speed and three times slower. It can be seen that the rotation center is some centimeters away orthogonally from the point I thought would be center of rotation:

Here top and bottom view of Arduebot for reference to the animation:

Btw, I am impressed that even the 120fps cool camera from my son displays the blue LED as a line instead of a small circle because of the high speed (top part of last frame before power loss):

Hermann.

I have to correct on the slowdown of the animations:
"displayed forward/backward at original speed and three times slower."

Should be (you can easily verify with "gifsicle --info ..."):
"displayed forward/backward at speed 3.6 times slower and 12 times slower than original 120fps."

I did some calculations and the best explanation I found for the rotation center is this:
It is the centroid of triangle built from inner points of wheels and center of half table tennis ball (where it touches ground).

Below is the animation again, only 12 times slower than original this time.
And picture of one frame with the three points mentioned (blue) and the computed centroid (white).
Seems to match what can be seen in animation:

Hermann.

Last weekend I did run Arduebot in Motor Test Station forcing it to run stationary. I did drill a hole into middle of peg-board just above the motor axis. This is the video of that run:

Analyzing frame by frame on rowvid.com shows that 2.08m/s circular speed was achieved, only half of the free circular run of Arduebot on the floor tiles (see slowmo in single frame viewer).

In postings after weekend (above) it turns out that center of free rotation was somewhere else. Therefore I tried today to enforce that center of rotation statically in Motor Test Station (MTS) as well. I added a new nail to MTS and did cut it for the correct height of Arduebot's LiPo box:

Of course there needed to be a new hole in LiPo box:

The whole is 2-3mm ahead of the real center of free rotation, but at that location the nail would have collided with one LiPo in the box. This is the video of the run today:

You can hear it easily that Arduebot was not able to hold road contact all the time. rowvid.com frame-by-frame analysis shows 2.41m/s circular speed, still far away from the 4.05m/s seen in free Arduebot circular run.

This will be it with my circular Arduebot runs, those in MTS are too slow, and free circular run as last weekend has potential to destroy Arduebot if not lucky as on last weekend where Arduebot got powered off avoiding damage.

Next step is linear running Arduebot as discussed above. On Monday I went to basement of IBM Böblingen lab and found a 25m and a 40m straight wall without any dent. The 25m basement corridor has a slight altitude differnce allowing to compare "uphill" and "downhill" runs, the 40m dentless wall corridor is flat.

Yesterday I ordered Sharp 4-30cm IR distance sensors:

One at front and one at back of Arduebot, both directed to the side/wall, hopefully allows Arduebot to run parallel to a dent-free wall at high speed in constant distance without too much jiggle ...

The sensor gives measurements every 39ms, which would give a measurement every 19.5cm only if running with 5m/s.

Hermann.

Oh, Oh, ...

This was the plan, have two IR sensors looking to the same side and let them keep Arduebot run parallel to a long, dentless wall:

The vertical installation of IR sensor was dictated by Sharp IR distance sensor data sheet and my application:

I never used PID before, and searched yesterday for 2 input (IR sensors), 2 output (motors) PID and found stuff:

Since that's all new I did want to take an abbreviation on the way to determine maximal linear Arduebot speed.

Today I built "esp12ebot == Arduebot - (Arduino Due + TB6612FNG) + (ESP8266-12E + L293D)"

First runs just pressing "forward" key turning esp12ebot to full speed had to be followed "║" in far less than a second to avoid damage. And esp12ebot drove crazy curves.

Then I pressed ᐅ (start maximal speed stationary rotation, like here), and then the Android lost Wifi connection to the ESP8266-12E!! I had to wait some mintues of rotation (luckily esp12ebot not leaving the white floor tiles) until the LiPos were discharged and esp12ebot stopped with less than 6V left from >12V at start.

I stopped my esp8266 controls motor in the past because voltage spikes made esp8266 restart terminating the much needed Wifi connection for control. I will go back to Arduebot immediately -- the nodemcu motor shield is really fine to play with slow gear motor robots at 6V, but definitely not for 12V motors as I do.

Hermann.

I realized that new tires may be needed due to the many high speed runs:

Just ordered 10 new tires for 0.25€ in total.

I worked on connecting the IR distance sensors vertically. I had to add a new fastening system to Arduebot:

This is the result:

Next step is to use Arduino playground PID library with 2 IR distance sensor inputs and two motor outputs. This should allow to determine maximal linear speed by Arduebot driving in eg. 20cm distance to long (25/40m) dentless walls in IBM Böblingen lab basement.

In previous posting I described that I had to wait some minutes of Arduebot full speed rotation ending due to out of power after Wifi connection loss. I did a new experiment in Motor Test Station (MTS) this time to determine how long exactly Arduebot can drive based on 3 fully loaded LiPos:

Arduebot started with 3 fully loaded 25C(40C max) 160mAh LiPos (12.45V). It did move 0:08-3:48min = 3:40min until stopped out of power with <6V. TB6612FNG motor controller was not even warm. Although not driving anymore the power was just enough to see that both distance sensors sender LEDs are still lit a bit:

zoomkat:
Use a little hot glue, strong but easy to remove.

Both motors got very, very hot at the end, I would expect to have lost motor(s) if having used hot glue instead of superglue for connecting the motors to peg board.

Hermann.

I measured some strange values with Sharp IR distance sensor and Arduino Due.

A colleague told me to measure with voltmeter, and that is what I did today:

I did two measurements with only getting power supply from Arduino Due's 5V and 3.3V while Due was USB powered. I compared this with the distance/voltage data from Sharp datasheet:
http://cdn-reichelt.de/documents/datenblatt/B400/DS_GP2D120XJ00F_SS.pdf#page=9

These are the resulting curves:

Good that I measured the voltage arriving at sensor as well, was only 4.03V/3.01V when connected to 5V/3.3V from Due.

Sensor VCC will definitely be connected to 5V pin, and hopefully that will provide more voltage when Due Vin is powered by 3 LiPos with >12V. Datasheet shows that there is no risk for Due pin since Sharp sensor returns 3.1V maximally.

My plan was to let Arduebot run full speed along a dentless wall with 15cm distance. Looking at 4.03V measurements 4cm/15cm/30cm gives 1.9V/0.72V/0.42V. The voltage difference wall side 1.18V is much bigger than the other side 0.3V. Perhaps Arduebot needs to run closer to the wall ... it all depends on how smoth the PID controller will make Arduebot run at constant distance to the wall.

I will start learning PID with a simpler setup, just connecting A11 to DAC1:
http://forum.arduino.cc/index.php?topic=178453.msg2646129#msg2646129

Here measured input with be "analogRead(A11)", and output will be "digitalWrite(DAC1, _)". Will be interesting how PID will adapt to the different resolutions (10bit/12bit).

Btw, 10 new black tires have arrived (for 0.25€, 1.15€ in total with shipping):

Hermann.

I followed the plan and played with DAC1➫A11 connection on Arduino Due as basis for a PID controller.

DAC1 can only produce voltages between (1/6)*3.3V and (5/6)*3.3V:
http://forum.arduino.cc/index.php?topic=129765.msg992632#msg992632

I did measure the complete range for "analogWriteResolution(12)" in steps of 100, and I did measure just a cable as well as 1KΩ and 10kΩ resistors between DAC1 and A11. These are the resulting curves:

I wanted to start simple in determining the PID constants with "Manual Tuning":

To my surprise I found no use for the proportional component in DAC1➫A11 scenario, a simple "I" controller (Ki=50, Kp=Kd=0) achieved good results already (PID Sampletime was 40ms). I passed a "void (*)(void)" callback function to PID constriuctor that got called at each real compute step of PID controller (every 40ms). That callback function updated the display with Setpoint (yellow) and Input (blue) curves (1 measurement every 3 pixels):

So I did my first steps with Arduino PID Library and if you want to play with PID yourself, you should really read the detailed article series explaning the many design decisions for Arduino PID Library.

Next step will be to do PID controller for Arduebot driving quickly with constant distance to a long, dentless wall. I will use the Sharp 4-30cm distance sensor with curves mentioned above. PID relies on some kind of symmetry which that raw measurements in above diagram don't have. I found a nice solution to get more symmetric measurements (around the planned Arduebot to wall distance), just take the natural logarithm instead of the raw measurements(!);

Now adding a constant resulting in value 0 for the planned distance should be a good basis for PID controller.

I read that controlling two motors of Arduebot with a single PID Output value can be done by driving both motor controllers at a specified speed value and just subtract the absolute vale of Output from the left/right in case of positive/negative Output value. The PID magic will also deal with slight speed differences between both motors.

For the distance sensors perhaps just adding both distances as PID Input is possible. But it is also important whether the front or back sensor shows the minimal distance value, at least for the action needed (turn right/turn left). So the plan is to use PID library "SetTunings()" function to switch between two (or maybe three) sets of PID controller constants on whether Arduebot is direction front to wall or front away from wall (or inside a small band around Setpoint distance where no corrections are needed).

I have not found articles dealing with "two distance sensors, drive parallel to wall" specifically. I will appreciate any pointer.

Hermann.

For doing the PID controlled constant wall distance speed runs the PID parameters need to be determined. This is much easier with the display as shown in last posting. Therefore I did add a display connector to Arduebot as described in this thread:
https://forum.arduino.cc/index.php?topic=384670.0

In tweet I'm Arduebot I posted this nice self referring photo:

Yesterday I posted on Arduino Uno proto shield is firm on Mega acrylic box around Due and works and at the end I said that I do not have direct plans for using that acrylic box for Arduino Due. Later I thought on that the box could replace the peg-board used with my first Arduebot completely.

There are many Arduino bots, and there are even bots with Arduino Due like Ardubot. But this thread is about Arduebot, and I want to define what that is here now.

An Arduebot is:

  • Arduino Due
  • mounted on peg-board or in box
  • with some proto shield for holding motor controller at least
  • two motors with wheels directly attached to motor axis at left and right of back side of peg-board/box
  • half table tennis ball or some kind of wheel on center front side of peg-board/box

Of course there can be much more, but above should be the minimal set making an Arduebot,

Hermann.