ROS adventures

 At first when I tried to install ROS I was very confused, because I was under the impression that the Raspberry pi was a very unique platform that needs it's own approach. So far I used Raspian Buster on it.

This led to a lot of confusion with me trying to install old ROS distributions such as Kinetic and Melodic. Because those are the only ones that Raspberry pi tutorials are made for. On the ROS wiki the distributions are said to support a limited number of architectures and operating systems. When I looked up what architecture the Raspberry pi has I got this result:

aarch

Which didn't seem to be listed. However it turns out that it is the same as arm64 architecture! This was a huge break through, because it meant that I could use any operating system as long as it had an arm64 port. I picked ubuntu, because it would allow me to run the latest ROS distro as of Febuary 2021 which is Noetic Ninjemys. 

As a side note noetic means relating to intellect or mental activity, and ninjemys is an ancient turtle species that is  literally translated to ninja turtle. Pretty neat!

I chose to install ubuntu 20.04 LTS server, because I'm mostly going to work with the command line. Hopefully I don't regret this decision, but if I do I can always install some more GUI stuff on it. This install was pretty challenging, because I wanted to do it headless. Meaning I didn't have a monitor setup, so I couldn't verify what was going on at first. I wanted to edit the network-config file on the SD card of the raspberry pi and enable ssh on it, so when I turned it on it would be ready to do and I could ssh into it. This proved difficult however as the wifi adapter refused to turn on. After a lot of failed attempts I gave up and plugged in my monitor. 

It turns out I forgot a quotation mark, which was messing up the network-config file. This surprisingly didn't let me log in to the pi at all. After I fixed it, it still wouldn't log into the Wi-Fi however. To solve that I edited the netplan YAML file on the ubuntu server after logging into it with a monitor and keyboard. 

This YAML file was terrible as it was super finicky with indentation. What I discovered is that each indentation had to be 3 spaces per seniority level. So something like this.

human:

   engineer:

      peter:

After I fixed this the netplan finally was able to be generated and applied. After that I ran

sudo apt update

sudo apt full-upgrade

sudo reboot

And finally for the first time it booted up with Wi-Fi! I was very happy, now I was able to ssh into the robot from anywhere in the house.

Then I was able to easily install ROS following this tutorial:

http://wiki.ros.org/noetic/Installation/Ubuntu

This is a huge breakthrough as I'm finally getting to the part that I want to do, the robot programming. ROS is  a very valuable skill to have in the robotics industry and my hope is that I can make myself more employable through this practice. The next step is to figure out serial communication via ROS and try to set up some nodes.

Improving the wire mess

 Today I also started the task of improving the wiring situation. Currently there are way too many wires and the thing looks ugly as sin. I managed to find an old yogurt container that fit the dimensions of the robot nicely. I decided to move the arduino and the raspberry pi to the top, because those are the components that I interact the most, and hide the ugly motor controller mess under the contrainer. I also made a small plow that can be used for moving objects and a little front face to mount the ultra sound sensor and the camera.

 

 One problem that I have yet to solve is the battery placement. I want it to be removable, but I also want it to be secure. It is by far the heaviest part of the circuit and I don't want it to fall off when the robot accelerates quickly. 

So far I have it taped onto the back of the robot. But one new improvement is that I have added a power switch! This make the whole thing a lot safer now.

Encoders

 If I hope to be able to locate my robot, I need some sort of sensor, for it to know where it is. When I bought the chassis I decided to get something with encoders. 

Magnetic encoders work by sensing a change in magnetic field as a disk attached to the motor rotates. The type that I have is called a 2 phase encoder. 

 

 

 One ring represents signal A and the other represents signal B. Based on the positions of the rings the logic of the signals will tell me if my robot's wheels are going backward or forward.

The problem is that I have 4 motors, and each of them has an encoder. I am already using 3 wires per motor, just to drive them. And with the encoders I will need another 2 wires per motor. 

I can use the analog pins as digital inputs, but I am still a bit short. My hope was to use pins 0 and 1, but they are ties to the serial communications. So basically I can either talk to my raspberry pi or I can have these two pins. Great... 

Since I don't want to buy another bigger arduino, I found another solution. I can use a shift register! This device would allow me to power 8 pins as digital output, while only using 3 on my arduino. Luckily I have a 74HC595 chip laying around.

The pins that are driven by the shift register will technically react slower, but the delay is so small that it shouldn't be noticeable.

So next time I will need to figure out how to use that, put some of the motor pins on there, and plug the encoder into the digital pins that are now available.

Other than this minor hickup, I have gotten all of the encoders to report data. This is amazing news. With this done, I can start getting into ROS more and using the data from the encoders to control the robot.

Speaking of which, I have managed to get basic serial communication to happen between the raspberry pi and the arduino, I wrote a simple script, where the arduino spits out the position of the wheel and the raspberry pi can read it. Currently I am controlling the raspberry by via ssh, so I can read the output on my nice computer screen.

Motor control success

 Hooray! I got the motors to work!

So previously I was having a lot of trouble with the raspberry pi to achieve consistent motor control. I decided to try an arduino, the hope was that I could get away with an arduino nano, however it's votage of 3.3 was not enough to drive the 5V motor controller. Since then I switched to an arduino Uno.

At first I was having a lot of trouble with the motors turning on and spinning in the right direction. Then I moved the line that activates pwm outside of the loop that controls individual wheels. This helped the timing a lot and I will use this method going forward. Presumably I won't need to have the wheels at different speeds.

Here is a video of the robot performing a test routine:

The robot performs considerably better on linoleum than on carpet. This is actually a bit of a problem, since if I want it to drive around the entire house, it will either need to be able to :

1. Detect carpet

or

2. Be able to know which parts of the house have carpet, and be able to accurate find its own position from encoder feedback. I think this will be very unreliable.

The next steps will be to implement communication between the arduino and  the raspberry pi. In another project I found done by masters students at EPLF, they used I2C to setup a master-slave system, with the Arduino being in control. The idea here is that the arduino is bullet proof and will execute commands even if the pi fails. Since I've already spent a considerable amount of money on this thing I won't implement this as I would need to buy and I2C bus. Instead I plan to use serial communication by connecting the two platforms with a usb cable. I'm running out of space on the chassis and might need to start elevating components for this to work.

One of my problems during the motor control tests is that one motor kept turning. Later I figured out that this is because the digital pin 1 (which is also the tx pin) kept out putting signals. If the arduino is going to be my main platform that takes in sensor input, then I'm going to use so many pins that I will inevitable need digital pin 1. So I will need to figure out how to configure it. 

That being said I can still start on connecting the encoders. Each encoder has a 5V and ground pin and an A and B output. the A and B are signals that will help determine the amount of rotations the wheel makes. More on this in a future post.

Also I finally recieved my rechargeable batteries. So now I can switched to a more sustainable power source. This will drop the votage of my system considerable but I think it should still function. The demo above used half speed and was still decently fast.