Arduino Robot - Putting it together

The time of putting (almost) all together finally came.
My young student Marco came over to my place with his family for a week, I showed them around a bit and sure enough we spared quite some time to assemble the robot.

We did not complete the task, as it was never the plan, but we reached a point where Marco can take over and finish almost autonomously (with my remote support) as a "deeper" learning experience.

(In the picture Marco installing the stepper motor 

that moves the scanning ultrasound sensor)

At this point the rover can move a specific amount of centimeters in each direction (using feedback from the encoders), we tested the ultrasound sensors and plenty of functionality is already included in the software (3 different turn types are  implemented : on the spot, sharp, shallow, plus motor speed balancing is implemented, coordinate management etc..).
Separately the NRF24L01+ radio system is connected to another arduino pro and an I2C based communication protocol is drafted (and tested) to communicate with the arduino driving the motors+sensors and with other I2C devices.
Also a UART protocol is used to communicate between the PC and the "base" radio station, the PC software is in Java.

Over time I will help Marco discovering the different parts he likes and activate them.

Meanwhile I would like to share with you a few lessons learnt from this exercise :

1) Cables!
Okay, we decided to pack a lot of features in this project, so we had to support them with software... but that was not the hard part.
All the devices must be somehow connected with data and power lines and this quickly generates a mess with the cables.
I wanted this specific project done in a way that things could easily be attached and detached, so I had to use a lot of improvised connectors and "flying"  cables.
As a general rule, maybe for a more "permanent" project, you may want to secure down your cables to the chassis as much as possible.

We used a female connector to provide 5V+ground connections to the devices connected on the bottom of the rover : 3 Ultrasound Sensors, Stepper Motor, Hall effect sensor, 2 Encoders.
Only for these power connections 14 wires are floating around!
We use velcro to keep them from getting in the way of wheels etc.
We took the +5V rail out of the motor driver as it contains a 5V LDO regulator (motors are powered @6V, the logic on the H-Bridge driver runs at 5V, hence the internal regulator).

2) Encoders
Encoders are simple right? what could possibly go wrong with them?
Well... turns out you should consider a few things when using them.
I got ourselves a few optocouplers, I carefully checked they were "slotted" (those that are U shaped, emitter on one side, photo-transistor on the other side) and the spacing of the U was ok with the thickness of my encoder wheels.
At least I got that part right :)
Then I started to test those couplers and with my surprise they did not work as expected.
There are several issues, the main one being that when light hits the phototransistor, it's  base is activated, but the internal resistance does not go down to zero.
Big deal you may think, something you might also expect, no?
Sure, makes sense, but the issue is that that forms a voltage divider with the pull down resistor you have to add and as a result of that the "high"  level is way lower than 5V.
In my case it was around 2V, while the low level was sitting roughly at 1.3-1.7V.

Direct result of this is that you are not likely going to feed this output directly to an Arduino digital input and in fact I have seen in the web people using an analog input instead and configuring via software the analog threshold to properly detect the logic level.
While that can be a solution, it prevents the usage of interrupts (which are available on digital inputs).
For this reason, some small circuits are sold, containing the coupler, a comparator, the needed resistors and even two fancy tiny leds (pwr-on and logic level).
These circuits make things way easier : simply provide +5V, GND and read a 5V clean logic signal back.

(encoder board with comparator, installed on top of the encoder wheel) 

You might avoid them if you are using an MCU that has embedded comparators, else I strongly suggest you buy these little boards as they save you a lot of trouble.

A final issue with photocouplers is that they are sensitive to ambient light.
That turned out to be a no-problem once installed on the rover as in that position they receive a limited amount of external light, however it polluted my tests when I was trying them on the bench.
No big deal, but something you should account for,

Also I found not particularly smart that the boards I received had male connectors soldered on the same side of the coupler, that forced me to cut slots in the rover chassis and hook the device from behind it.
And yes, I checked if it was worth de-soldering them and re-soldering them on the opposite side, unfortunately the copper layer on the printed board is so thin that if you get anywhere near with a solder iron, you better know very well what you are doing.

3) Arduino interrupts
Normal arduino boards (uno, pro etc) allow you to use two hardware interrupts on digital pins 2 and 3.
That seemed good enough for me as we only had two encoders.
I am not sure yet about this and I am planning to run some specific tests, but I had the impression that servicing the two interrupts with two different dedicated ISR and having them possibly triggering at the same time might result in missed interrupts.
At this point I cannot claim that arduino misses interrupts and since I did not check how the ATMega MCU itself manages interrupts I am not aware if this is actually possible... however I noticed some strange behavior, particularly when debugging via serial port at the same time (it might be due to timing).
This is one of the times when I wish I had a NVIC available like in the Stellaris/Tiva series.

4) Cheap motors
There are available in kits and on ebay cheap DC motors, they run at 6V, do not require a lot of current, contain a reduction gear and they are normally provided with wheel and encoder wheel.
To be honest, they are really cool, but their connections are extremely fragile.
It is ok when they are locked in place and you are not shuffling them around, but if occasionally the connection wires you soldered to them get tight... this may easily rip apart the connections.
That happened to us and we had to dismount one of the motors and solder a new wire almost directly on the brush.
Unless you practice Zen frequently, I strongly suggest you try to avoid that.

(Installing the tail wheel)

Overall it was a real fun experience, as it always is when playing with Arduino.
It is amazing how easy is to explain technology to an enthusiastic and smart 10 year old using Arduino, I really believe it is a perfect platform for this task.
I personally prefer to have a bit more control over the hardware, but that comes with some more complexity, which definitely adds to the fun once you can grasp the basics, until then : Arduino all the way :)

Aside from the main robot activity I was able to help Marco learn how to solder, about serial protocols (I2C, SPI...), how to use a drill press, how to use a multimeter and read an oscilloscope.

There is a new geek in town! :)

Arduino Robot - Moving around and steering

It is true the Rover we are planning will have to do many things, but the most basic thing it has to do is to stroll around, to put it simpler : move.

It is a Two Wheel Drive rover, meaning it will have a small electric motor on each of its two traction wheels and it will have a third traction-less wheel on the back, just to balance it out.

It will be able to steer like tanks do, by changing the speed of each motor accordingly.
The simple way to look at this is by considering some basic combination of speeds :
1) The two wheels are turning in the same direction (forward) and with the same speed -> the  rover will drive on a straight line, moving forward
2) The wheels are turning with opposite directions, but the same speed -> the rover will turn on itself, around the middle point between the two wheels

3) One wheel is turning, the other one is still -> The rover will rotate and the center of rotation will be the still wheel.

We can generalize the concept and find the center of rotation for any combination of wheel rotation velocity.
It is easier to do that using vector match which is quite intuitive, I am saying this because the target audience of this article includes very young makers that eventually did not study it yet... don't  get scared :)

If we represent the velocity as an arrow starting from the center of the wheel and pointing to the direction in which the rover is moving, we can use some basic geometry to figure stuff out.

As you can see in the example above the right wheel is rotating roughly twice as fast as the left one, this is why the V2 arrow is about twice as long as the V1 one.

This means that in the same amount of time the right wheel will travel twice as the distance traveled by the left one.
Now, if we connect the base of the arrows and extend the line, then we connect the top of the arrows and we also extend that line, we discover they eventually touch themselves in a point.
That point (the red triangle) is the center of rotation, in fact if V1 = V2 those lines will never touch which means that the center of rotation does not exist... and that is  because there is no rotation at all.
If V1 = V2 the rover would drive in a straight line.

The same concept works for about any combination of velocities.

In this second example V1 and V2 have different direction and modulus (modulus just means how "long" a vector is), can we compute the position of the center of rotation?
Indeed we can, as previously said, basic geometry comes in help.

We want to find X, it is the distance between the left wheel and the center of rotation, you can easily see that we can then relate it to any point we consider the center of the rover, like the middle point between the two wheels.

The green and red triangles are similar, so we can state that :

X : V1 = (D + X) : V2

Note that we use (D + X) or (D - X) depending on which way the X arrow is pointing.

Resolving : 

X = V1/V2 * (D + X)

X = V1/V2 * D + V1/V2 * X

X (1-V1/V2)) = V1/V2 * D

  V1/V2 * D

X =   ------------------    

 1-V1/V2

Now say we want to relate everything to the middle point of the axis connecting the two wheels :

  V1/V2 * D

X =       ----------------    + D/2

 1-V1/V2

Let's assume D = 10 cm,  V1 = -50 rpm ,  V2 = 100 rpm.

X = -50/100 * 10 / (1 +50/100) + 10/2 = -5 / 1.5 + 5 = 2.66 cm  

The coordinate system we are using has the center in the middle point of the axis connecting the wheels and positive X facing left.

Knowing the center of rotation is key to be able to plot maneuvers, i.e. if we need to drive around an obstacle, but it is also important to calculate the position of the robot at any time.

In fact we might try to drive the two motors with a predictable velocity, eventually equal, but for various reasons one might turn a bit faster than the other forcing our rover into a undesired shallow turn and by consequence missing the predicted trajectory.
That's  not really a huge issue provided we can timely apply corrective actions, and this becomes possible if we also measure the real velocity of the wheels.

A typical way to measure the rotation speed of something is to attach an encoder, a small and simple device that sends an impulse every known number of degrees of rotation.
This is typically achieved using a small plastic wheel with a number of holes in it

The U shaped thingy visible in the bottom right is an opto-coupler, on one side of the U there is an LED and on the other side a photo-transistor.
When light generated by the LED hits the transistor, current is allowed to flow through it and that can be detected as a logic 1 on the pins of a MCU.
If the plastic wheel is placed in the U, when it turns it will generate a 0 level each time there is no hole between the LED and the transistor and a 1 each time a hole is between the two.

Finally, if we know how many holes (N) are in the wheel , we can easily compute how many degrees there are between each hole.

deg = 360 / N

And if we count how many times a 0-1 pulse happens on the selected pin of the MCU , we can also compute how many revolution the traction wheel performed:

rev = pulses * 360 / N

The schematics to connect the encoder to the Arduino are pretty simple :
the green triangle represents the LED, the red / white crossed circle represents the transistor.
There is a specific reason why we selected pin 2 on the Arduino, but we will dig into that detail later.

At this point we ASSUME we can activate the two electric motors and we know how we can use a "feedback loop" to measure how much they really moved.
Next step will be to see the details on how to activate the motors.