Arduino Part 7: The Test

A few weeks ago, I picked up the Arduino Uno that I've had for a while, and started thinking about what I should build with it. I decided on modifying an old toy rover that I had, and making it wirelessly drivable... but with 2 way audio and a camera feed. single-frame camera-broadcast.


Links:
Part 1: Initial Plan and Reverse-Engineering
Part 2: Preparing the Rover Chassis
Part 3: Motor Control
Part 4: Bluetooth!
Part 5: Mounting
Part 6: Batteries
Part 7: The Test

- Chassis: Check
- Motor Circuitry: Check
- Bluetooth Functionality: Check
- Android App: Check
- Arduino Mount: Check
- Power: Check
- Double Check: Check

Now what happens when I put it together and turn it on?

On May 18th, I put batteries into the compartments. I put the Arduino on the rover. I plugged all of the motors into the breadboard, with their uncomfortably long wires. I plugged in the positive power. I checked the circuitry twice for errors, and tried to think of any solder joints that might need to be changed.

My mom helped me record the first test.
Here are 4,249 pictures of it:

Success

Since then, I've stopped working on it... I still might set up an audio system. In theory, it won't be nearly as complicated as a camera system, requiring less bandwidth to work.

Speaking of cameras and bandwidth, an image-broadcasting system, unfortunately, isn't practical. Even at 480x360p, black and white (One byte per pixel), each image would be 1.4 Mb, or 172.8 kB. The Arduino Uno has only 2kB of SRAM... Way too little to store an image. Plus, even at a baud rate of 115,200, it would take 12 seconds to broadcast. In my calculations in part 4, I mistook 115,200 to be the number of bytes, rather than bits, per second, so I thought it would only take 2.66 seconds per frame (with 78% more pixels).

Here are the project's credits:

Myself:     Designer, builder, programmer
My mom:  Inspired me to do this project, and lets me explain problems to her
My dad:    Sponsor and design help

The Science is Settled!

Math doesn't lie!

In the beginning of January, the temperatures here in Texas were hovering around 28 degrees Fahrenheit. Nothing surprising here. Today, I went to weather.com, and checked the 5-day forecast: The high this week is going to be ninety degrees.
Wait, NINETY? That seems oddly steep...
Today is the 90th day of the year, so the equation:

28 + (90 - 28) / (90/365)

will give us the temperature at the end of the year:

= 28 + 62 * 365/90

= 28 + 62 * 4.06

= 28 + 251.72

= 279.72 degrees...

We won't last 6 months! The oceans will evaporate, and Earth will become a second Venus!
If you don't believe these FACTS and don't completely agree with ME, you're a Climate DENIER, and should be thrown in jail!!!

Arduino Part 6: Batteries

A few weeks ago, I picked up the Arduino Uno that I've had for a while, and started thinking about what I should build with it. I decided on modifying an old toy rover that I had, and making it wirelessly drivable... but with 2 way audio and a camera feed. single-frame camera-broadcast.


This is the sixth part of several posts. I will be explaining about how I set up the power supply of my rover.

Links:
Part 1: Initial Plan and Reverse-Engineering
Part 2: Preparing the Rover Chassis
Part 3: Motor Control
Part 4: Bluetooth!
Part 5: Mounting
Part 6: Batteries
Part 7: The Test

To start with, here are some facts about the situation:
  The rover is only designed to hold three AA batteries (4.5 volts).
  According to my multimeter when monitoring the long-disconnected-and-very-bored rover brain, the motors are designed to get the full 4.5 volts from the batteries.
  Arduino requires, at the very minimum, a stable supply of more than 5 volts.

This makes it more difficult than I originally thought, which was: "Let's just hook up a 9-volt!" Browsing Google search told me otherwise...

I wasn't about to go looking for how to use a switching regulator, so plan B was to use AAs. Three for the motors and four for Arduino means seven batteries total. That's even more than I remember RC helicopter controllers and the Lego Mindstorms NXT using.

Here's Plan B-and-a-half:

1. Test to see how few batteries can successfully power the motors (Two)
2. Add a single battery to the rover (For a total of four)
3. Have a third wire coming from the middle of the battery chain, thus using all of the batteries to power the board while two of those are also powering the motors when necessary.
4. Do extensive tests with my multimeter to ensure that the voltage never drops below 5 volts. If it does, fiddle with the circuitry until it's stable.

After the test was set up, I found that voltage dropped drastically at the moment I started the motors. Voltage would then very slowly increase as the motors weren't requiring as much power to continue spinning. I added the biggest capacitor I had (1000 μF, also referred to as 1mF). This made good progress, but the capacitor was discharging too quickly. This delayed, but hardly reduced, the voltage drop.

To combat this, I added a 1KΩ resistor between the power / capacitor leads and the Arduino Vin wire. This was a mistake because then, while tests showed satisfactory results, trying to power the Arduino didn't work. The resistor was choking Arduino, and my multimeter couldn't tell because it has a very high internal resistance.

My next attempt was to add the resistor in series with the capacitor, leaving the power wire directly connected to Arduino's Vin pin (Or, at first, the multimeter's lead). This was successful. Charging the capacitor wasn't noticeably affecting results, and voltage would slowly drop, but not to the fatal 5V level, when spinning the motors.

The final test went very well. Arduino turned on. Power was stable. (Manually) activating the motors didn't break anything, and Arduino didn't die when I kept the motors going for several solid seconds. Success!

To get the extra battery into the rover chassis, I had to take a AA holder from another kit, solder it up, and tuck it into the Rover. This would, unfortunately, require me to dismantle the rover in order to change all of the batteries, but it's a personal project. It doesn't need to be super simple, especially since I've already got the Arduino sitting directly on top of the other batteries.

More tips... They just keep coming...

1. Do the math! Connecting random batteries would only have gotten me an overpriced blue paperweight.

2. Know your electrical engineering! The long-standing Kerbal convention of "More Power!" would have lead me to use more batteries rather than a capacitor. This would be less efficient and more likely to overheat the Arduino.

Edit: 7/6/17: Updated list of links

War Thunder: Investigating Russian Bias

I've been playing War Thunder for a long time, and while I haven't played nearly as much of it as I have of Space Engineers, I want to do some research on the topic of Russian Bias. For those who haven't heard, Gaijin, the developer of War Thunder, is a Russian company. Thus, some players claim that the game is biased to favor Russian planes and tanks.

I think this will be split into three parts.

Part 1: Motivations for bias (This one)
Part 2: Checking the numbers (I won't look at all of the planes... Just a few.)
Part 3: Other less obvious opportunities for bias (Stalinium? Nerfed .50 cals?)

I will be going country by country with what Russia's general feelings towards them could be. All of this comes from my observations, and being an American, my views of potential Russian grudges will definitely be inaccurate in one way or another. Let's begin:

The United States of America:
  Overall Feelings: Kapitalist Scum!
  World War I: Stayed out of the war for a while. Finally joined on the side of the Allies (Which included among others Britain, France, and Russia)
  World War II: Allied only because of a common enemy: Nazi Germany.
  Other interesting facts: America was Russia's main enemy during the Cold War, in which the Korean and Vietnam Wars occurred between America and it's allies, and Russia and it's allies. The United States also won the Space Race, "putting a man on the moon and returning him safely before the decade is out."
  Predictions: Negative bias will probably be low through the early to mid tiers, worsening through mid to late tiers.

Bias graph

Britain:
  Overall Feelings: Most likely mixed
  World War I: Allies with Russia
  World War II: Allied only because of a common enemy: Nazi Germany.
  Other interesting facts: While Britain was allied with America during the Cold War, they didn't play as big a role. Thus, most of the Cold War dislike will be aimed at the U.S.A.
  Predictions: Low negative bias overall. Perhaps a little more in the late tiers.

Bias graph

Germany:
  Overall Feelings: Likely resentment.
  World War I: Enemy of Russia. War declared on Russia August 1st, 1914.
  World War II: Briefly allied with Russia, agreeing to split Poland between them. The Nazis then attacked Russia during the Battle of Britain. This two-front war is one of the things that caused Germany to lose.
  Other interesting facts: After WWII and during the Cold War, Germany was split between the Capitalist West and the Communist East (Russia). The Berlin Wall was built by the Russians to keep their citizens from fleeing West and telling about Communism's true nature. After the Soviet Union collapsed in 1991, Germany was united again, and a Capitalist government was put into place (By America).
  Predictions: High levels of negative bias early on, only reducing a little in mid to late tiers.

Graph of who knows what

Japan:
  Overall Feelings: Neutral to moderate dislike.
  World War I: Allies with Russia.
  World War II: Border conflicts with Russia prior to and early in the war.
  Other interesting facts: After WWII, America set up a Capitalist government in Japan, and Japan was used as a base of operations during the Korean War. The ideological differences (Capitalism vs. Communism), along with Japans support of America during the Korean War doesn't suggest that they are on the best of terms with Gaijin.
  Predictions: Less negative bias in the beginning, slowly growing through the mid to late tiers, but not as much as the U.S.A.

Bias graph

Arduino Part 5: Mounting

A few weeks ago, I picked up the Arduino Uno that I've had for a while, and started thinking about what I should build with it. I decided on modifying an old toy rover that I had, and making it wirelessly drivable... but with 2 way audio and a camera feed. single-frame camera-broadcast.


This is the fifth part of several posts. I will be explaining about how I mounted my Arduino and the breadboard to the rover.

Links:
Part 1: Initial Plan and Reverse-Engineering
Part 2: Preparing the Rover Chassis
Part 3: Motor Control
Part 4: Bluetooth!
Part 5: Mounting
Part 6: Batteries
Part 7: The Test

Almost all of the rover's circuitry and coding were done. I had to start thinking about how I would keep the delicate brains from falling out.

One thing was certain: I wouldn't be able to directly put the Arduino onto the rover: Not enough flat space, and I would be taking a chance of damaging it.

To minimize the damage risk, it would be a good idea to have something to mount the Arduino on, like a cushion in-between the rover pieces and the Arduino.

First, I looked at acrylic mounting boards. These were either expensive, or wouldn't get here very timely. I finally chose the totally-professional-looking recycled-cardboard and string approach.

Steps I took were:
Marked locations for holes with Ultra Fine sharpie through Arduino's.
Punched holes with some sharp screws I had lying around.
Found that the ink was conductive and had to repeat steps 1 and 2 on another piece.
Tied Arduino on with super thin threads.

Just under the top piece of plastic (supposedly designed to give the impression that it was a tinted windshield) was the battery cover. It was long enough that, with some modifications, the Arduino could fit on it sideways. There were two supporting triangles in the way, and I had to find a way to chop off the excess.

Sorry. This image was taken after I chopped it up.

Remember how I said that my soldering iron cut through the plastic way back in Part 2? (In between the first two images) That gave me an idea: I could melt through the plastic and remove just enough. Searching on the internet to see if anyone has found disadvantages, I found this Instructable. No need to get out the hammer, though. I have a small container with a variety of soldering tips... One of them is a fearsome looking knife blade.

Need I remind you not to break into my house?

Cutting through the plastic was very easy. I just held the blade on it, and pressed.

Disclaimer: I am not responsible for fingers lost while waving hot knives around. Call a doctor, not a lawyer.

After the cutting was done, there was enough room for my Arduino with a little bit extra.

Picture was taken with the inky cardboard.

To mount the cardboard to the battery cover, I had a few options: Double-sided tape, sticky "Zots", and hot-glue. I chose sticky Zots as the best blend of reliability and non-permanence. After the Arduino and breadboard were secured, it looked like this.

The battery cover went right back on the rover body, and had no obstructions. Naturally, I won't be putting the original top piece back on.

Part 6 will be about how I decided to power the rover. This is made more difficult by the fact that by default, the rover carries only 3 AA batteries: 4.5 Volts.

More tips!

1. Don't wave hot knives around... I think you would be very disappointed with only nine fingers.

2. Try not to do things that will be irreversible. Later (Part 6), I found that I needed a bigger breadboard. Had I used hot glue to attach it, I would be trying to cut it off with the soldering iron.

3. Take time to do things right. While it probably wouldn't have been fatal, conductivity between leads would not have been healthy for Arduino. I'm glad I checked with a multimeter.

Edit: 8/25/16: Updated list of links

Edit: 7/6/17: Updated list of links

The Rock, the Paper, and the Scissors

Four months and seven(ish) days ago, I started working on my first Android app. It was to be a rock paper scissors game, including a Lizard-Spock bonus feature (In a separate $0.99 version), and bluetooth phone-to-phone functionality. On June 19th, I uploaded it to the Google Play store.

It had humble beginnings: Solid color background, placeholder textures, hard-coded strings... Kind of like this:

Before

The animations were made slowly: Trying out a series of commands based on the current tick, and then compiling it to see what happens. If I didn't like it, I would have to make changes and re-compile.

I found free images from the internet (Who can copyright a digital piece of lined paper?), and modified them in GIMP to look right. Some modifications were simply removal of color, and others were all-out remakes.

Finding sound clips was one of the harder parts. A good 90% of the sound effects that I found weren't what I was looking for, and usually I would have to edit the pitch, speed, and volume of the clips in Audacity.

No points for guessing where the sound for the baby scissors army came from.

The Bluetooth feature still isn't ready. It's a very complex system and I've been doing research, learning, and planning on how to implement it. It will be on both the free and paid versions of the app, and they will even (hopefully) be compatible.

Coding the physics simulations weren't the easiest things either. I had to invent gravity, make the confetti descent look realistic, build a function for detecting collisions... One of the more interesting aspects of this was developing a mathematical formula to get the upwards velocity x needed to get up to y height with a gravity of 2 pixels/second/second. I'll share this particular one with you:
x = -2√y + 1
Or as it appears in my code:

plyr2XSpeed = (byte) (2*Math.sqrt((player2.getY() + player2.getHeight())) + 1);

The +1 is margin for inaccuracy.

Stay in school, because the engineers (Specifically those who work hard in math) are going to rule the world! (Bwa ha ha-COUGH!  COUgh! Cough! ha ha...)

After

If you have an Android device that is part of the 89.2% of Androids that *should* (Please tell me about bugs) be compatible with my app, you can download and start playing the free version TODAY! Just go to this link and click on the green install button (Google Play is probably the only place where this is safe to do... Everywhere else, the green buttons are probably deceptive ads.):
https://play.google.com/store/apps/details?id=g3ckobot.therockthepaperandthescissorsfree

Again, the bluetooth mode is not ready yet. It will be made available for both the free and full versions of the game.

Downloads and positive reviews on the store are really helpful to apps. They are the primary thing to boost their position in searches, and give a readily available average to users contemplating the use of their 19 MB.

Thank you for taking the time to read this. I hope you find this post and my app entertaining.

Arduino Rover Part 4: Bluetooth

A few weeks ago, I picked up the Arduino Uno that I've had for a while, and started thinking about what I should build with it. I decided on modifying an old toy rover that I had, and making it wirelessly drivable... but with 2 way audio and a camera feed.

This is the fourth part of several posts. I will be explaining about how I connected my phone to Arduino via Bluetooth.

Links:
Part 1: Initial Plan and Reverse-Engineering
Part 2: Preparing the Rover Chassis
Part 3: Motor Control
Part 4: Bluetooth!
Part 5: Mounting
Part 6: Batteries
Part 7: The Test


The rover was coming along nicely, however I still couldn't control it remotely. Options for communications were:

A. WiFi: Hosting a webpage on the rover, and inputting commands from a computer or phone. Advantages: Higher bandwidth, range while in free WiFi. Disadvantages: would only work in free WiFi, and would require a special "shield" that goes on top of Arduino.

B. Bluetooth: Connecting via phone and driving with an interface. Advantages: Works without WiFi, doesn't require special shield, uses Arduino's built in serial capabilities for bit-by-bit communication. Disadvantages: Lower bandwidth than WiFi, lower range while in free WiFi zone.

Let's compare:

WiFi

Bluetooth

Bandwith

Flexibility

Control quality

Weight and size

Cost

Cool factor (0.25 points)

Sorry, WiFi, but I think Bluetooth wins 4.25 to 1.

This means that a continuous video feed is not really an option. The highest serial 'baud' that Arduino can muster is 115200. If I was to try to send a 640 by 480 pixel video feed of 10 frames per second (using grayscale instead of color), that would be 640 * 480 * 10 = 3,072,000 necessary bytes per second. That's about 3 megabytes per second, 26.66 times what is available. Kind of disappointing. On the bright side, I'll still be able to press a button on my phone and receive a single picture... over the course of 2.66 seconds.

I looked online to see how people usually do Bluetooth connections with their Arduino and discovered that the most popular Bluetooth module was the HC-06. After some research, I discovered that it was capable of using a higher baud rate than Arduino could handle, but had a lower default. It also ran on the standard 5V that Arduino outputs... Not bad. There were also guides everywhere, so the HC-06 it was.

It's $9.49 on Amazon with free 2 day shipping (Amazon Prime only). When I got mine, I think there was a 50% sale.

While waiting for it to come in the mail, I had to slap together some Android code. I downloaded this guy's example and set about reverse-engineering it. There was a disturbing number of references to Chihuahuas. I've been working on my own app for a while, so all I had to focus on was the Bluetooth code. Please note that the project folder is formatted for Eclipse. I had to manually copy the source code into Android Studio (I only took part of it).

Modifying the code was a big task (Android code terminology ahead!). The first thing I did was delete the Chihuahuas. Then I ditched the layout and created my own (one that will be easier if I'm looking at the rover rather than my phone). I changed the search term for the paired devices from "HC-05" to "HC-06". Then I set up the controls to broadcast a single-byte command every quarter of a second depending on which buttons were pressed, rather than as the buttons were pressed. I added another activity for pre-driving setup (custom search term, more stuff to be added later). I also worked on cleaning up and custom-formatting the code.



Then there was the Arduino code to design. A quick Google search revealed that it's as simple as making a SoftwareSerial on the proper pins. I didn't bother downloading anything for it. The complete code sends a message through the HardwareSerial to my computer every time it receives a command.

On the day of projected arrival, I discovered that the relays had come early, and didn't notice the big yellow bubble-protected envelope containing the HC-06 (facepalm). I realized my mistake in the late afternoon...

On the hardware side of things, it's pretty simple to set up.

Here's where the pins go:
GND --> Arduino's GND
VCC --> Arduino's +5V
RXD --> Voltage Divider to TX on Arduino (More on this in next paragraph)
TXD --> RX on Arduino (Don't send these to the 0 or 1 pins. These are used to communicate with the computer)

After doing my research, I noticed that some people skipped the voltage divider, and some people regard it as necessary. Both groups say that it works for them, but the RXD pin is technically not supposed to be exposed to the full 5V of Arduino's pins. Here's a link to the page I learned most about how to do it.

Looking into my inventory, I don't have any 20KΩ resistors. That's ok. I'll just use two 10KΩ resistors in series.

Plugging everything in and verifying hardware connections... No bluetooth connection. More troubleshooting:

Switching RX and TX pins: Nope.
Staring at it to use the Force: Why??
Checking on Bluetooth menu in phone settings: Getting somewhere. It sees the HC-06.
Tapping on it and inputting the default password (1234): Bingo! Now the phone and Arduino are "paired" together!
Trying again: It works! Every quarter of a second while pressing a button on my phone, Arduino sent a message of "Received right command" or "Received forward command"!

I wonder why the Chihuahua code didn't automatically pair with the device... Probably doesn't want to accidentally pair with random devices (smart).

I think I'll wait to post downloads of my own code until the post where the rover is driving successfully (Sure, I'll do it sooner if the comments ask me to). I encourage anyone wanting to, to try and make their own code. I only downloaded the Chihuahua code to figure out how to create and maintain a bluetooth connection (I'd been struggling). Anyone with the same problem can go ahead and get the Chihuahua code. The Arduino code is so simple it shouldn't be necessary to download.

Part 5 will be about my search for ways to mount my Arduino to the rover.

Tips jar is for you, not me!:

1. Be conservative. It wouldn't have been very fun to kill the bluetooth module via overvoltage.

2. Do it yourself (if you can). It's very important to learn what's going on under the hood, and the best way to do that is to make it yourself. If you're stuck, you can get some help, but still do your best to understand.

3. Don't give up troubleshooting!

Edit: 7/8/16: Updated list of links
Edit: 8/25/16: Updated list of links
Edit: 7/6/17: Updated list of links