System Overview

Project Flow

The progression of the project has an order, but some parts may be followed loosely. We organize this project in an order we believe makes the most sense. However there are some modules and components of the BT RC Car that can be done in parallel and out-of-order from what we have presented. Of course, depending how far out-of-order one goes, it may not easy to complete a given task (gap in learning), or bottlenecked from completing.

What we have imagined for the project slow is as follows. Start with an Arduino UNO and breadboard the majority of the project. That is, through a single Arduino UNO, read from the thumbsticks, write to the motor driver (motor + H-bridge) and servo - no wireless component yet. Then split off the hardware across two Arduinos and get the same concept working wirelessly using the bluetooth modules.

The next few steps can be done concurrently, however proceed with caution as the next few parts are things integrating together and there are a lot of inter-dependencies.

Then we introduce the ATtiny85, the (explicit) ATMEGA328p, and how we program these AVR microcontrollers. We will not explicitly breadboard with these, instead we will give the appropriate background and guidance to orient you to work on the PCB design component and integrate the aforementioned microcontrollers. With the exception of using the ATtiny85 and ATMEGA328p, we have breadboard everything - so knowledge of the PCB schematic should be straight forward to create from the breaboarded circuitry. We provide the PCB in the BT RC Car kit, however you are encouraged with the practice of this project to pursue PCB printing!

After the PCB design of the remote and vehicle, or concurrently, we turn to the 3D modeling using SolidWorks or your favorite 3D CADing software (e.g. OnShape, Autodesk Fusion360, etc.). This is possibly the most interesting and creative component of the project. Here we will show you our explicit design as an example, but we encourage you to add your own creativity. The challenge is visualization as you bring PCB to be fitted into your design. This is the epitome of the measure twice, cut once principle. It will also significantly develop or hone your technical prowess using these powerful prototyping tools - the same of which are used in industry. After the design, you make your cuts with a laser cutter or 3D print your design.

Another concurrent task is soldering. The PCBs we provide will work, it is just a matter of soldering it together correctly. Be very patient with soldering as it is a task you will want to get right the first time - fixing PCB mistakes can be a massive headache if you are not experienced.

Next, we have the real integration process. We have our laser cut and 3D printed chassis, and our soldered PCBs, time to put everything together to make the realization of the BT RC Car! One of the beautiful parts here is that You should already know how everything should fit together - we already designed how it should come together. It is seeing the visualization turn into a reality that is an exciting experience! Of course, there maybe some interesting pitfalls and that we why we provide the working examples.

Finally, it is time to bring the BT RC Car to life. We already coded the behavior of the BT RC Car in the prototyping phase, it is just a matter of making small refactors; mostly just pin number translation from Arduino UNO to ATtiny85, you can use the same pin configurations as the Arduino UNO for the ATMEGA328p - remember this is the Arduino UNO chip, just in a different package! Upload your code, fine tune any changes, and make your BT RC Car drive!

And that is it! Keep this module in mind as you progress through the project. You will be doing smaller tasks that will be introduced with generalized concepts. It is up to You to internalize the learning experience as you progress - so do not lose sight of the big picture!

Now, lets make fun!

Hardware Setup

The thumbstick, analog stick, or joystick (although when we think of joystick we imagine the arcade style - large ones that you use your entire hand to play with) is an analog device. It has two potentiometers, one for the X axis and one for the Y axis, that takes in a voltage across its VCC (labeled +5V) and GND pins. You can move the thumbstick in approximately 45 degrees in each axis direction from its resting state as well as any position as a function of both axes. As you move the thumbstick around the internal potentiometer's third pin behaves as a voltage divider constantly giving a voltage between GND and VCC.

If you press down on the head of the thumbstick it depresses until it actuates an onboard momentary push-button. This is the only digital component of the thumbstick. We will not utilize this push-button feature in the BT RC Car, however we show how to use it for completeness.

Let us make the circuit to play with the thumbstick. Construct the following circuit to connect the thumbstick to the Arduino UNO:

Testing the Thumbstick

To test this module, we will use the following code:

// Program to test the thumbstick
//
// Prints the X and Y analog readings
//  and the state of the SW (push-button)
//  of the thumbstick to the Serial Monitor
//
//  Arduino to thumbstick connections
//  Arduino 3.3V or 5V to VCC of thumbstick
//  Arduino analog pin A0 to X pin of thumbstick
//  Arduino analog pin A1 to Y pin of thumbstick
//  Arduino digital pin 2 to SW pin of thumbstick
//  Connect GND from the Arduino to GND on the thumbstick



#define BAUDRATE 9600

#define thumbstick_x A0
#define thumbstick_y A1
#define thumbstick_sw 2

int raw_analog_reading;
int switch_state;
 
void setup() {

  // Start Serial Monitor for feedback
  Serial.begin(BAUDRATE);

  // Configure with internal pull-up resistor
  //  so we do not need a physical pull-down resistor
  pinMode(thumbstick_sw, INPUT_PULLUP);
}

// Continuously print the X and Y analog readings 
//  and the state of the push-button of the thumbstick
void loop() { 
  Serial.print("(X,Y,isPressed)=");

  Serial.print("(");

  // Read + print thumbstick X
  raw_analog_reading = analogRead(thumbstick_x);
  Serial.print(raw_analog_reading);

  Serial.print(",");

  // Read + print thumbstick Y
  raw_analog_reading = analogRead(thumbstick_y);
  Serial.print(raw_analog_reading);

  Serial.print(",");

  // Read + print thumbstick switch state
  //  Note: We invert the reading because of the internal pullup resistor
  switch_state = !digitalRead(thumbstick_sw);
  Serial.print(switch_state);

  Serial.println(")");

  delay(10);
}

This code is straight forward, it simply prints each of the analog values from the thumbstick for both the X and Y axis. It also prints the status of the onboard push-button. We are using a feature of the Arduino UNO that the pin of the microcontroller than employ its own internal pull-up resistor. Thus, when the button is not pressed, it will return a logic level HIGH value until pressed; then returns a logic level LOW value until released. We invert (!) the state when we perform the digitalRead from the switch so that it feels more intuitive to the user.

An example of the code running:

Playing with the thumbstick should feel intuitive. The digitalRead from the button constantly prints a 0 until you press the button, and then prints a 1 until released. The printing of the analog X and Y values will show a clear minimum and maximum value. At rest, that is without moving the thumbstick, the analog readings should be at some steady-state value with should be approximately half of your maximum analog reading.

The onboard ADC of the Arduino UNO has a 10-bit resolution, thus we get 2¹⁰=1024 steps of analog voltage readings from the thumbstick potentiometers that range from GND to VCC. These readings are mapping GND through VCC to 0 through 1023. If you are using VCC=5V, you may get the full range of the ADC - that is, you may see a minimum value of 0 and a maximum value of 1023. If you are using VCC=3.3V (as shown in the GIF above), then you may observe that you never reach the full range of the ADC. This is because the ADC is voltage reference is with respect to 5V. This is not a bad thing that we miss out on some resolution, it will work just fine.

You may have observed that, depending on the orientation in which you are holding the thumbstick, which direction - relative to the thumbstick - increases or decreases the analog readings to reach your minimum and maximum. It may even feel backwards or upside-down from your expectations. This is no problem, we will address this in an exercise!

Challenge: Remote Control Analog

In this challenge, we are essentially forming the basis for the remote. Looking ahead, we will have two thumbsticks that control the motor and servo. The hardware setup is similar as shown earlier, except we are not interested in the push-button and we only want to use one of the analog pins from each of the thumbsticks. For one of the thumbsticks use the x-axis potentiometer (later will control the steering) which we will refer to as the steering thumbstick, and for the other thumbstick use the y-axis potentiometer (later will control throttle) which we will refer to as the throttle thumbstick. As for which side (left or right - like most gaming controllers) you want the throttle or steering thumbstick on is up to you.

Further specifications include the following. For your steering thumbstick, regardless of what side it is on (left or right in physical placement), when you actuate the steering thumbstick head LEFT it should print out the minimum analog reading that your thumbstick produces (e.g. 0 or something close). When you actuate the steering thumbstick head RIGHT it should print out the maximum analog reading that your thumbstick produces (e.g. likely in the range of 500-1023).

For the throttle thumbstick, we do essentially the same thing. When you actuate the throttle thumbstick head DOWN it should print out the minimum analog reading that your thumbstick produces and when you actuate the throttle thumbstick head UP it should print out the maximum analog reading that your thumbstick produces.

The X printout comes from the first thumbstick when actuating LEFT and RIGHT; and the Y printout comes from the second thumbstick when actuating UP and DOWN. The behavior of your code should simulate the something similar to the GIF below. In this scenario we chose the left thumbstick to be our steering thumbstick actuating LEFT and RIGHT. Similarly, we chose the right thumbstick to be our throttle thumbstick actuating UP and DOWN.

Challenge Solution

Note that this solution is NOT the only solution. This is just how we realized it. It should look almost exactly the same as the code we started with when testing the thumbstick. The only difference is the removal of the push-button code, and that we have two physical thumbsticks as opposed to one.

The schematic should be similar to as follows:

Again, the code can vary, but here is what we have for our solution:

Hopefully this challenge was not too difficult, this was meant to be very simple - after all, we just started. As we progress through the BT RC Car project, the challenges will get increasingly more difficult. However, we are taking things step-by-step, so pay attention to the increasing difficulty gradient, versus dumping a bunch of requirements and specifications and expecting the same results at the end. Taking a problem and breaking it down into these smaller steps is a valuable skill - especially for teaching others (hence this project page).

Hardware Setup

The servo is a powerful device. Unlike the thumbstick, a sensor; the servo is an actuating device. Servos are digital devices, which means it receives 0's and 1's to function. But when we write to servos there is a degree at which we want a servos poition to change to. The way this is accomplished is through a PWM (Pulse Width Modulation) pin on the microcontroller to control the position of the servo (generally between 0 and 180 degrees). Although the the servo is a digital device, the method by which we control the servo is considered an analog method to the Arduino - that is, we send a signal of a particular width (logic level HIGH for a set amount of time) using the analogWrite function.

The Arduino UNO produces a PWM signal with 8 bits of resolution (2⁸=256). This allows us to write various steps to a PWM driven device. Arduino has a built in Servo library that takes care of the heavy lifting. It gives support of creating the waveform and all we have to worry about is to what degree we wish the servo to turn to between 0 and 180 degrees.

If we have a simple circuit, we can generally get away with powering the servo with the Arudino UNO onboard 5V rail. However, if we had several servos or the servo was working under a heavy load it may not operate well through your computer's USB port limited at 500mA. Servos can be power hungry devices if they are actuating quickly or under a heavy load. They can also become noisy and get hot under these conditions. For this module, we are OK to power the servo through the Arduino 5V rail, however when we make the actual BT RC Car, we want our servo to be delivered with sufficient power.

In general most digital servos have three colored wires: red, black, and white or orange:

The circuit for the servo is as follows:

Testing the Servo

To test the servo we use the following code:

// Program to test the servo
//
// Prints the position of the servo
//  and sweeps from 0 to 180 degrees
//  and sweeps back from 180 to 0 degrees
//
//  Arduino to servo connections
//  Arduino 5V to VCC (red wire) of servo
//  Arduino digital PWM pin 9 to SIG (orange or white wire) of servo
//  Connect GND from the Arduino to GND (black wire) of the servo



// Import Arudino's Servo library
#include <Servo.h>

#define BAUDRATE 9600

#define servo_pin 9

Servo servo;

void setup() {

  // Start Serial Monitor for feedback
  Serial.begin(BAUDRATE);

  // Attach servo pin to Servo object  
  servo.attach(servo_pin);
}

void loop() { 

  // Sweep from 0 to 180 degrees
  for(int i = 0; i <= 180; i++) {
    Serial.print("position=");
    servo.write(i);
    Serial.println(i);
    delay(5);
  }
  delay(500);

  // Sweep from 180 to 0 degrees
  for(int i=180; i >= 0; i--) {
    Serial.print("position=");
    servo.write(i);
    Serial.println(i);
    delay(5); 
  }
  delay(500);
}

The code is the typical servo sweep code that comes as an Arduino example sketch. It continuously sweeps between 0 and 180 degrees.

An example of the code running:

Challenge: Servo Steering with Thumbstick

In this challenge, we will use the steering thumbstick to control the servo. As we actuate the thumbstick from left to right, record the minimum and maximum attainable values. We recommend using a variable to record these minimum and maximum values. Similarly, define variables for the minimum and maximum value we want to write the servo to - when we put together the BT RC Car, we may want to narrow the range from 0 to 180 degrees.

Next, we want to map the 10 bit (1024 steps) analog readings from the thumbsticks to the the 8 bit (256 steps) pwm signals for the servo. Arduino has an extremely useful function called map that will map one domain to another. With the mapped value, we can write this to the servo and we will be able to move the thumbstick left and right and see the servo move left to right as well.

If the mapping was done well, then when the thumbstick is at rest it should be within 2-3 degrees from being 90 degrees, which is our center and how our future BT RC Car will move straight.

It is not necessary to have printouts, however we include them here for illustration. This is the kind of behavior you want to emulate:

Challenge Solution

Note that this solution is NOT the only solution. This is just how we realized it. Pretty much we fused the thumbstick challenge with the servo example code. The interesting part that we have added that is a bit different is the Arduino map function. It is a very useful method to use for all kinds of applications. We will use it again soon. We also added the minimum and maximum value variables. This is extremely effective to do in all sorts of applications - especially if these kinds of numbers are used more than once. It is common to have these constraining variables, and most people will put them hardcoded (just the number in the function), but making a variable for it allows us to change all instances at once and not have to scroll through out code to make the change, instead we have levers or knobs at the top of the code in which we tune our code in a very clean manner. The pitfall of this is that our code may get longer and look more cluttered - we probably should have used shorter variable names.

The schematic should be similar to the following:

If your servo is jittery or your observe the LEDs onboard the Arduino UNO flickering when the servo moves, you may need a dedicated power supply because your servo is not powered adequately through your computer USB port and the Arduino onboard 5V regulator. We recommend putting up with the jittering until we get to the PCB.

Again, the code can vary, but here is what we have for our solution:

We have the workings of half of a wired remote. Next up, we need to add our motor driving circuitry and then control it with the thumbstick so we can control the throttle!

Hardware Setup and Configuration

The motor operates via a current that energizes a thin electromagnet that generates an electric field. There is a permanent magnet surrounding the electromagnet which attracts and repels the electromagnet. This causes the electromagnet to spin. As it spins, the polarity from the power source is flipped via brush contacts, which perpetuates the spinning. The shaft of the motor spins with the electromagnet which is what we will observe as the motor actuating.

Looking forward, we will attach a pinion gear to the shaft of the motor which will drive a larger gear attached to an axel that will drive the back wheels of the BT RC Car. The front wheels are controlled by the servo which gives us full control over the vehicle.

The driver is an H-bridge. An H-bridge is essentially a device that allows us to control the direction of current through two pins. These two pins will be connected to the motor, so we can effectively drive current in either direction and our BT RC Car will be able to move forward and in reverse. The H-bridge pins are referred to as the enable and phase. The phase pin determines the direction. A digital HIGH corresponds to one direction and a digital LOW corresponds to the opposite direction. The enable pin is the the magnitude of power, or speed, in the given phase direction.

To power the H-bridge, we give two power sources: one power source is our microcontroller digital logic signals, the other power source is across the H-bridge pin that powers the motor. We will be using the Arduino UNO to power the motor for now, but will use a LiPo battery later to make our BT RC Car fast.

We will be using a breakout board for the DRV8838 H-bridge which looks and operates as follows:

The motor does not look like anything special, small and cheap DC brushed motor:

The circuit to test the motor driver is as follows:

To test the motor driver circuitry, we will use the following test code:

// Program to test the motor driver circuitry
//
// Prints the phase (direction) and enable (speed) of the motor driver
//  Ramps up to max speed, then slows down, in one direction
//  Ramps up to max speed, then slows down, in opposite direction


#define BAUDRATE 9600

// Motor Driver variables
#define enable 5
#define phase 6
#define FORWARD HIGH
#define BACKWARD LOW
#define THROTTLE_MIN 0
#define THROTTLE_MAX 255

void setup() {
  // Start Serial Monitor for feedback
  Serial.begin(BAUDRATE);

  // Set phase (digital) pin as an output
  pinMode(phase,OUTPUT);

  // Set initial condition for motor driver
  digitalWrite(phase,FORWARD);
  analogWrite(enable,0);
}

void loop() {
  // Sweep motor at phase = FORWARD,
  //  and motor speed at enable steps 0 to 255
  //  speed up 
  digitalWrite(phase,FORWARD);
  for(int i = THROTTLE_MIN; i <= THROTTLE_MAX; i++) {
    analogWrite(enable,i);      
    Serial.print("(phase,enable)=(");
    Serial.print(FORWARD);
    Serial.print(",");
    Serial.print(i);
    Serial.println(")");
    delay(5);
  }
  delay(500);

  // Sweep motor at phase = FORWARD,
  //  and motor speed at enable steps 255 to 0
  //  slow down
  for(int i = THROTTLE_MAX; i >= THROTTLE_MIN; i--) {
    analogWrite(enable,i);        
    Serial.print("(phase,enable)=(");
    Serial.print(FORWARD);
    Serial.print(",");
    Serial.print(i);
    Serial.println(")");
    delay(5);
  }
  delay(500);



  // Sweep motor at phase = BACKWARD,
  //  and motor speed at enable steps 0 to 255
  //  speed up 
  digitalWrite(phase,BACKWARD);
  for(int i = THROTTLE_MIN; i <= THROTTLE_MAX; i++) {
    analogWrite(enable,i);       
    Serial.print("(phase,enable)=(");
    Serial.print(BACKWARD);
    Serial.print(",");
    Serial.print(i);
    Serial.println(")");
    delay(5);
  }
  delay(500);

  // Sweep motor at phase = BACKWARD,
  //  and motor speed at enable steps 255 to 0
  //  slow down
  for(int i = THROTTLE_MAX; i >= THROTTLE_MIN; i--) {
    analogWrite(enable,i);  
    Serial.print("(phase,enable)=(");
    Serial.print(BACKWARD);
    Serial.print(",");
    Serial.print(i);
    Serial.println(")");
    delay(5);
  }
  delay(500);
}

The code appears long, but the print statements are most of its volume. The print statements are not necessary either, they are just for illustration and potential debugging. Observe the several #defines we have at the top of the code, these are for tuning later. For example, FORWARD is assigned HIGH, but after we construct the BT RC Car, it may (coincidentally), be that this will be in the backward direction, so we can tune this later as appropriate. It also saves our code from these random looking numeric constants. By making a variable (or #define), we make the code more readable.

There are four loops in this program, and they practically all function the same. In the first loop, we are increasing the motor speed from 0 to 255 in a the directio labeled as forward. In the second loop, we decrease speed in the same forward direction until the motor stops. In the third and fourth loop, we mimic the same behavior as the first and second loop, except the motor operates in the opposite, reverse, direction.

When we construct the BT RC Car and integrate the motor, the explicit direction of forward and backward may change depending on the connections made with the H-bridge and the orientation of the motor. Thus, we are using explicit variables to make this a simple change later.

The behavior of this program is illustrated as follows:

Challenge: Motor Driving with Thumbstick

Similar to the last module with the servo, we challenge you to control the motor driver with the thumbstick. However, there is a catch! When the throttle thumbstick is pitched forward (up), we want the motor to move forward (again, this forward is relative - for now). When the throttle thumbstick is pitched backward (down), we want the motor to moev backward. And, when the thumbstick is at rest we want the motor to not move at all.

Now if you experienced from the last few modules, or have used analog sensors in other projects. They tend to be a bit noisy or jittery in their analod readings. We have also experienced them having drifted slightly from day to day, or week to week. So we cannot use just a single value for the thumbstick at the rest position and expect the motor driver to not operate. We need a dead zone, that is a threshold for which within some tolerance the thumbstick analog readings will stay in this dead zone reliably. Then once exceeding some threshold in the forward direction, the motor driver will drive forward. Similarly, once exceeding some threshold in the backward direction, the motor driver will drive backward.

The threshold tolerances that you choose should be a few points above and below the resting throttle thumbstick analog reading.

It is not necessary to have printouts, however we include them here for illustration. This is the kind of behavior you want to emulate:

The behavior should be similar to the following:

Challenge Solution

Note that this solution is NOT the only solution. This is just how we realized it. Pretty much we fused the thumbstick challenge with the motor driver example code. Again, we have utilizing the Arduino map function to map the analog throttle thumbstick readings into a range for forward and a range for backward to be written to the motor driver. We keep adding several variable constants to define the threshold, minimum, and maximum values to make modifying the code easy and accessible at the top of the program.

The schematic should be similar to the following:

Again, the code can vary, but here is what we have for our solution:

Next up, we are going to combine this exercise with the steer thumbstick + servo challenge to get the functionallity of an RC Car that is wired - that is, without the wireless bluetooth connections - yet!

Challenge: Prototyping RC Car Functionality

In this challenge, we combine the work of the last two challenges. That is controlling the servo with the steer thumbstick and controlling the motor driver with the throttle thumbstick. If you have been building atop of your code, you may already have this functionality complete. If you have not, then it really should be an exercise of fusing the code from these two challenges together into a single program.

With the completion of this challenge you should have the behavior of an RC Car - just wired, no wireless component yet.

However, this challenge contains a special problem that you may run into - we certainly did. When you complete this challenge, you may run into a massive problem that will appear to have ruined your BT RC Car in the making. This may have been a problem you have run into if you have built other projects, and we are addressing it here: noise.

The completion of this challenge yields the following behavior:

If you observe carefully, you will see every time we active the motor, the servo acts erratically. When I actuate the servo alone, it seems to be behave as expected. However, when I actuate the motor, the servo always slams to one side and becomes stuck - even if I wriggle the steer thumbstick around, there is no response. This is because the motor is extremely noisy and is wrecking havoc on the rest of servo and the rest of the circuitry.

Unfortunately, it would seem our project must halt here. And in terms of prototyping and explicitly using a breadboard - this is the sad truth. However, it is time to learn a new skill: Printed Circuit Board (PCB) design. A PCB can fix this problem. And as we will get to, there is a few elements of PCB design that will fix this problem: a GND plane, spatially closer circuitry, isolating GNDs and noisy components, and better electrical connections.

If you have never heard of GND planes, that is OK, but these low-impedence GND connections clean up a lot of noise in your circuitry. Using the breadboard wires for power and GND buses, these are still terrible connections.

Spatially locality helps a lot, if your circuit is like ours - very neat with wires cut to size - then you are helping your circuit, versus having long jumper wires for making breadboard connections that are approximately a centimeter or two away. When we create the PCB, everything will be very closer together - the vehicle board will be smaller than the Arduino UNO board.

Isolating grounds could help on your breadboard circuit, but without the assistance of power planes - you will probably not notice any improvements.

Finally electrical connections. Jumper wires have a very small connection surface area, and in combination of all the above makes for terrible electrical conductivity. We will largely use surface mount components which have superior surface area contact.

A combinational improvement of all these factors in our PCB will grealt improve the performance of our BT RC Car.

So if you are having this noisy issue right now it is OK - we are having it too! We did not purposely make this happen to illustrate a point, this really happens to us too. So for this challenge, implement the behavior that is expected, and whether you have the noise issue, or not, the challenge exercise is still building atop what our BT RC Car code.

Challenge Solution

Note that this solution is NOT the only solution. This is just how we realized it. As we mentioned in the challenge specification. It is just a fusion of the steer thumbstick + servo challenge with the throttle thumbstick + motor driver challenge.

It is OK if you have the noise problem with the servo and motor interfering! There is no fix for this unless we use different hardware or until you make the PCB!

The schematic should be similar to the following:

Again, the code can vary, but here is what we have for our solution:

Nothing special here. Really is a copy-paste of the steer thumbstick + servo challenge and the throttle thumbstick + motor driver challenge.

Next up, we take a break from the circuitry that - literally - drives our BT RC Car and we will turn our attention to the HM-10 bluetooth module!

Bluetooth HM-10 Module

We have a tutorial already created for how to use the Bluetooth HM-10 module in general. So, instead of transcribing everything in that tutorial here, we will simple direct you to the tutorial.

The Bluetooth HM-10 tutorial is linked here: Bluetooth HM-10 Tutorial. Your task is to go through the following modules:

We give working of examples on how to use the HM-10 module. As you progress, think of how we will tie this into the BT RC Car. It is also important to understand the inner workings of how the communication prototcol works and what technologies we are using.

When you complete the listed modules, proceed to the integration challenge.

Challenge: Prototyping BT RC Car Functionality

In this challenge, you will be breaking up the work we have been doing on a single Arduino UNO into two Arduino UNOs. We will refer to one set as the remote and the other as the vehicle from here on out. Furthermore, we will be communicating between the remote and vehicle using the wireless bluetooth modules.

Your task, is to combine what you have learned with the HM-10 bluetooth module with what we have done in the last challenge to demonstrate the same functionality wirelessly.

You will need to send at least two pieces of information over the bluetooth (inside the struct). That is, the steer thumbstick analog reading and the throttle thumbstick analog reading.

There is one more piece of data that should be sent that was not covered explicitly in the bluetooth HM-10 module and that is a checksum. When we make a transmission, there is a chance that an error occurs. This could be "over the air" error that causes a bit to flip when transmitting through the channel. It could also be on the transmitting or receiving side that data is lost or becomes erroneous. Regardless, there is a very simple way we can detect some of these errors - but we will not be able to correct them. We will use a checksum, which in this case can be the sum, difference, and, or, xor, etc. of the data we wish to send together and placed into a variable that it itself is also transmitted (which could also be erroneous).

On the receiving end, we compare the transmitted checksum variable in our struct with the same operation we did to create the checksum on the transmitting side, with the received data. We compare them to make sure that they return the same value, which ensures us that our packet has a higher probability of being correct (of course, it could be coincidental that there is enough error to actual appear as correct - when this happens, we take the loss in this application).

For example in our implementation, we transmit the throttle and steer analog readings, which are being stored as ints. Our checksum variable, also an int, equates to the XOR (or ^) of the throttle and steer analog readings. We transmit these three data types in our struct on the transmitting side. On the receiving side, we receive these three (potentially erroneous) variables in our packet. We compare the checksum in our received packet against the recalculated checksum of the received throttle and steer analog readings from the packet. These should be identical. If they are, we assume the data is perfect (it could still be erroneous, but we take the loss at this point). If they do not equate, we throw away the packet, and bet on probability that we will get our perfect packet very soon. For the BT RC Car application, we will be communicating at approximately 100 Hz, so a garbage packet here and there will not make our BT RC Car act completely erratic.

We show the same GIF as before since the behavior we expect is identical. However, this is now happening wirelessly between the remote and vehicle sets. We are demanding more power from the Arduino. On the vehicle side we have the motor + H-bridge + servo + bluetooth, thus the performance - even with an external ideal power source - will start to degrade. Keep in mind, the PCB will fix all of this soon!

Challenge Solution

Note that this solution is NOT the only solution. This is just how we realized it. As we mentioned in the challenge specification. It uses the same concept from the last challenge with the addtional of the bluetooth module.

It is OK if you have the noise problem with the servo and motor interfering! There is no fix for this unless we use different hardware or until you make the PCB!

The schematic should be similar to the following for the remote:

And for the vehicle:

Again, the code can vary, but here is what we have for our remote solution:

And, our vehicle solution:

Besides the explicit bluetooth code. We also add the checksum bit to improve some of the performance. The RC Car behavior will not execute unless an acceptable package is received.

The preprocessor code is added so it is easy to turn off print statements. Removing print statements dramatically increased performance.

AVR Microcontrollers

To learn about AVR microcontrollers in general we direct you to our AVR Microcontrollers tutorial. You will need to follow the sections for both ATtinys and ATMEGAs since we will be using both in this project. We will be using the Sparkfun Pocket AVR Programmer as our bootloading device, you may skip any mentions of Arduino as an ISP.

After reviewing the AVR microcontrollers tutorial, you should have the ATtinyCore bootloaders installed, be familiar with the board settings for both ATtinys and ATMEGAs. (For the ATMEGA328p, it is essentially the Arduino UNO, so not much to be aware of here). You should also have your Pocket AVR Programmer configured for your computer.

Next, we will introduce the ATtiny85 and ATMEGA328p explicitly and how we will be using it in this project!

AVR Microcontrollers: ATtiny85 & ATMEGA328p

We will now cover the ATtiny85 and ATMEGA328p in detail as it pertains to the BT RC Car. This includes how we will convert the prototyping we have done up to this point on the Arduino UNO. That is, how we will use the ATtiny85 to replace the Arduino UNO for the remote and how we will use the ATMEGA328p to replace the Arduino UNO for the vehicle.

The ATtiny85 & BT RC Car Remote

We will be using the ATtiny85 in our BT RC Car remote. It is extremely small and has just the right number of pins to be a perfect fit as our remote. We used the Arduino UNO to do our prototyping, and now we need to port our pin mapping and code to the ATtiny85. There are some changes that need to be made, but it is certainly possible!

Now we will cover the ATtinyX5 series in general and then how we will use the ATtiny85 explicitly in the BT RC Car. To learn about the ATTinyX5, we direct you to our ATtinyX5 Microcontroller tutorial. Since we will be using the Sparkfun Pocket AVR Programmer, you need only pay attention to the sections pertaining to the Pocket AVR Programmer explicitly to bootload and program the ATtiny85. We cover the ATtinyX5 through-hole package in the general tutorial, but the pinout is exactly the same, as well as any behavior, so they are identical to each other in every way except one is a surface mount chip and the other is a through-hole chip.

Here we show a reference of the ATtiny85 pinout:

This pinout describes the physical and logical layout of the ATtiny85. The physical layout are the physical pins - pins one through eight in a counter-clockwise fashion. The logical layout of the ATtiny85 are the numerous labels tied to each physical pin.

We have the ATtiny85 device in our EAGLE libraries and it is represented as follows:

Observe the similarities and differences. The numbers represent the physical layout of the ATtiny85. However, the order of these numbers do not match the physical layout of the ATtiny85. The reason is because they are organized logically. On the left, the power connections are shown (i.e. VCC and GND). On the right, the GPIO (general purpose input and output) pins are labeled and ordered by port (e.g. PB = port B).

Each of the GPIO pins have one or more functions. The pins that you can program using the ATtinyCore in the Arduino IDE are labeled on the far right inside the parentheses (e.g. D# for a digital input or output pin, A# for an analog input pin, PWM# for a digital PWM or analog output pin). You would use these pins like you would in any typical Arduino sketch.

Back to the remote, so we need to think about what pins we used for the remote. From the module 05 Challenge: Prototyping BT RC Car Functionality, we have a circuit that should be similar to the following:

Observe we need power, two analog pins, and a means by which we can communicate to the bluetooth HM-10 over serial. On the Arduino UNO, we have a hardware UART with a dedicated TX and RX pin. On the ATtiny85, we are not so fortunate. But, there is a solution and we were prototyping with it the whole time. That is, we were using a SoftwareSerial library on the Arduino UNO. Technically on the Arduino UNO we could have used the hardware UART the entire time (and probably would have had increased speed and performance), but we were using SoftwareSerial and the ATtiny microcontrollers are capable of using this library.

Technically we could use any pin for the SoftwareSerial on the ATtiny85, but we need to make sure, of the five GPIO pins, we still have two analog pins in addition to the two pins we will need for TX and RX with SoftwareSerial.

As you read in the AVR Microcontroller and ATtinyX5 Microcontroller tutorial we will need to bootload the ATtiny85. This requires the AVR ISP programming header to be present and we need to make these appropriate connections on our ATtiny85 as well. Since we only use this once and independent of any of the BT RC Car functions, we label them implicitly, in parenthesis, if they are doubling up with another pin necessary for the BT RC Car Remote. The pins we have chosen and use in the PCB provided are the following:

ATtinyX5 (physical pin)	Connected Device(s)	Schematic Label
1	AVR ISP	RESET
2	THUMBSTICK	THUMBSTICK_R
3	THUMBSTICK	THUMBSTICK_L
4	ALL	GND
5	AVR ISP LED	MOSI
6	Bluetooth AVR ISP	TX (MISO)
7	Bluetooth AVR ISP	RX (SCK)
8	ALL	3.3V

If this appears a bit confusing, it should hopefully become more clear when we design the PCB board for the remote. But this is giving you a preview of how we are mapping the Arduino UNO pins to the ATtiny85 for our remote to retain the same functionality.

So this is how we will use the ATtiny85 to replace the Arduino UNO. We are being extremely efficient in this way. The Arduino UNO, and even the ATMEGA328p microcontroller that the Arduino UNO is based off the ATMEGA328p, is a lot larger and more expensive, but the ATtiny85 is very small and we are using every pin on the ATtiny85. This is the efficiency.

Next, we discuss the ATMEGA328p explicitly and how it will be our microcontroller for the BT RC Car Vehicle!

The ATMEGA328p & BT RC Car Vehicle

We will be using the ATMEGA328p in our BT RC Car vehicle. It is the exact same microcontroller at the heart of the Arduino UNO. The difference here is that we will be using a surface mount package that is a lot smaller, versus the through hole package that rests on the Arduino UNO development board. We used the Arduino UNO to do our prototyping, and now we need to port our pin mapping and code to the ATMEGA328p. Luckily, we did not choose the pins we have for just any reason. We have used the exact same pins in prototyping the vehicle on the Arduino UNO as we will use in the BT RC Car Vehicle PCB. There is only one change we will make, and that is taking advantage of the hardware UART in the ATMEGA328p and use it to perform our serial bluetooth communication (instead of using SoftwareSerial as we have during the prototyping phase).

Now we will cover the ATMEGA328p in general and then how we will use the ATMEGA328p explicitly in the BT RC Vehicle. To learn about the ATMEGA328p, we direct you to our ATMEGA328p Microcontroller tutorial. Since we will be using the Sparkfun Pocket AVR Programmer, you need only pay attention to the sections pertaining to the Pocket AVR Programmer explicitly to bootload the ATMEGA328p. We will not, however, use the Pocket AVR Programmer to program the ATMEGA328p. Instead, we will be using the Sparkfun FTDI Basic Breakout. We cover the ATMEGA328p through-hole package in the general tutorial, but the package we will use on the BT RC Car is a bit different. The ATMEGA328p PDIP (plastic dual in-line package) package is a through hole package (in the general tutorial) that has 28 pins, however the package we will use is a surface mount device in the industry standard TQFP (thin quad-flat package) package which has 32 pins. The only difference is that we have four extra pins, two of which is an extra VCC and GND pin, the other two are not being used. So we effectively have the same number of GPIO pins and are the same in every respect that we will use it.

One of the beautiful advantages to this, is that we can literally program our BT RC Car Vehicle and the ATMEGA328p microcontroller package that we are using exactly like we would an Arduino UNO. For all intense and purposes we are creating a custom Arduino UNO that will behave exactly like the Arduino UNO development board - except that we do not have broken out GPIO pins.

Here we show a reference of the ATMEGA328p TQFP pinout:

This pinout describes the physical and logical layout of the ATMEGA328p. The physical layout are the physical pins, namely pins one through 32 in a counter-clockwise fashion. The logical layout of the ATMEGA328p are the numerous labels tied to each physical pin.

We have the ATMEGA328p device in our EAGLE libraries and it is represented as follows:

Observe the similarities and differences. The numbers represent the physical layout of the ATtiny85. However, the order of these numbers do not match the physical layout of the ATMEGA328p. The reason is because they are organized logically. On the left, the power connections are shown (i.e. VCC and GND), the RESET pin, the crystal oscillator connections (i.e. pin 7 and 8), and some NC (not connected pins) (i.e. pin 19 and 22) that are literally not being used in any way shape or form. On the right, the GPIO (general purpose input and output) pins are labeled and ordered by port (i.e. port B, C, and D).

If you arguing that there are GPIO pins on the left-side, yes, you are technically correct. However, they are considered special, necessary, or completely useless. And for this reason we include them on the left.

Each of the GPIO pins have one or more functions. The pins that you can program using the Arduino UNO core in the Arduino IDE are labeled on the far right inside the parentheses (e.g. D# for a digital input or output pin, A# for an analog input pin, PWM# for a digital PWM or analog output pin). You would use these pins like you would in any typical Arduino sketch.

Back to the vehicle, so we need to think about what pins we used for the remote. From the module 05 Challenge: Prototyping BT RC Car Functionality, we have a circuit that should be similar to the following:

Observe we need power, one pin for the servo (does not necessarily need to be a PWM pin, but Arduino recommends pin 9 and 10 for servos), two PWM pins for the PHASE and ENABLE to control the H-bridge, and a means by which we can communicate to the bluetooth HM-10 over serial. On the Arduino UNO and thus ATMEGA328p, we have a hardware UART with a dedicated TX and RX pin. Although when we were prototyping we used the SoftwareSerial library to perform our bluetooth communication, we will take advantage of the hardware UART when it comes to the BT RC Car Vehicle.

As mentioned earlier, since the Arduino UNO and ATMEGA328p are effectively the same thing. We do not have to make any major pin changes except that when we design the PCB board, we will use the dedicated hardware UART TX and RX pins.

As you read in the AVR Microcontroller and ATMEGA328p Microcontroller tutorial we will need to bootload the ATMEGA328p and use a serial programmer to program the ATMEGA328p. This requires the AVR ISP programming header and the serial programmer header (we call it the FTDI header on the schematic) to be present and we need to make these appropriate connections on our ATMEGA328p as well. Unlike the case for the ATtiny85, we have no overlapping or doubling up of pin functionality. However, we still outline the pins we have chosen and use in the PCB provided are the following:

ATMEGA328p (physical pin)	Connected Device(s)	Schematic Label
3, 5, 21	ALL	GND
4, 6, 18	ALL	5V
7, 8	Crystal Oscillator	XTAL1
9	H-Bridge	PHASE
10	H-Bridge	ENABLE
13	SERVO	SERVO
15	AVR ISP	MOSI
16	AVR ISP	MISO
17	AVR ISP	SCK
29	AVR ISP	RESET
30	Bluetooth Serial Programmer	RX
31	Bluetooth Serial Programmer	TX

If this appears a bit confusing, it should hopefully become more clear when we design the PCB board for the vehicle. But this is giving you a preview of how we are mapping the Arduino UNO pins to the ATMEGA328p for our vehicle to retain the same functionality.

That concludes the ATtiny85 and ATMEGA328p for now. We will revist these again after we design and solder the PCBs where we will discuss bootloading and programming the remote (ATtiny85) and the vehicle (ATMEGA328p).

Next up, we dive into the PCB design of the remote and vehicle!

PCB Design with EAGLE

If you have never used EAGLE or need a refresher, we have an Introduction to EAGLE PCB Design tutorial that we encourage you to follow. This tutorial will also get you started downloading and installing EAGLE. Furthermore, this will get you equipped with the basics so that you can keep up with the pace of the EAGLE content in this project. In these modules, we proceed slowly, however we are not going to go over the basic tools of EAGLE and assume you have the EAGLE Libraries integrated into the EAGLE environment.

PCB Design: Remote & Vehicle

Now we proceed with the PCB designing phase! We will first do the remote as it is an easier board. After, we turn to the vehicle which has a few more considerations that have to be taken into account while designing.

Let us make fun!

We have completed the PCB design phase of the BT RC Car project! Next we will solder the PCB board replicas that we just designed.

Soldering: Remote & Vehicle

We will be soldering remote and vehicle. We will start with the remote followed by the vehicle. When soldering boards that have both through-hole and surface mount devices, we start with the SMD components, then solder the through-hole after. There are a couple stages that we follow when soldering the surface mount components:

After which we solder all the through-hole components to complete the soldering phase.

Let us get started. First the remote, followed by the vehicle. Optionally, you could do them at the same time if you choose!

Next, we are going to do some simple tests for our boards to make sure they do not explode in your face when you turn them on. Perform these tests for both the remote and vehicle PCB.

Testing the Remote and Vehicle PCB

First, take a few minutes to visually inspect your board for any solder bridges. This is extremely important. If we shorted the battery at any place, something will get hot, smoke, or break. If we shorted any signals, then you will get garbage or static results that may result in the inability to program the device, read from sensors, or write to actuators.

Next, retrieve a digital multimeters (DMM). Most decent DMMs will have a continuity check function available. Set the DMM to this continuity checking function. This continutity checking function will simply check the if the two points of contacts are connected electrically. So the first check we want to make sure that where the battery connects is NOT shorted. We can do this my touching the DMM leads to either terminal of the connector where the battery will connect.

Most DMMs are very similar. If you have never used the continuity feature before, we illustrate how to use it on this model.

The symbol represents the continuity feature. On our DMM, the continuity feature is a mode on a dial position that is grouped with resistance mode and diode mode.

The mode button on the DMM cycles between the three modes. Select continuity mode.

Resistance Mode

Diode Mode

Continuity Mode

As a sanity check to check that the DMM is working properly, is set to the continuity mode, and that the leads are not broken (producing an open ciruit) anywhere, touch the leads of the DMM together.

If you hear a beep or observe that a resistance is displayed then you have a short and thus there is continuity. If there is no beep, or the resistance displayed is OL (overload), then you may be in the wrong mode or there is a problem with your DMM or the leads.

Now test continuity across the battery connector (should NOT beep). If you are NOT signaled that there are any shorts across the battery, you are so-far so-good, but we want to be absolutely certain. Take some time and check other parts of your circuit that you think may be shorted.

If you hear a beep or receive the signal that indicates that there is a short. Then you need to visually inspect your board again for any shorts. You may have to reflow or use a soldering iron and rosin to fix any devices that are shorted. It may also be good to test that certain components are connected too, in which a beep would be a positive test!

If you have a nice power supply available to you, many feature a current-limiting feature that is extremely useful for double-checking that your board does not have a short.

We have a short introduction to a Keysight E3631A DC Power Supply that supports this feature. If you have access to one or another power supply with similar features, we highly encourage taking this precaution and use it.

With this, you can set the current limit at 20mA, and the power supply output to 7.4V. Place the power supply leads across the appropriate positive and negative terminals of the PCB, respectively. You should see the power LED turn on. If the power LED does not turn on, flashes for a second and turns off, stays dim, or the power supply shows signs of a short. Disconnect the circuit and debug as appropriate.

If you are not fortunate to have such a power supply, then at this stage, you have to take your chances and power your device. Or if you did, then it is time to power your device with the real thing. We recommend keeping close to the power switch or have the ability to remove the LiPo battery at a moments notice if you experience a short.

If you see LEDs come on and no immediate shut-off, smoke, or popping sounds. You are probably good. We recommend lightly placing your fingers on each of the integrated circuit (IC) components (most notably the voltage regulators) to make sure they are not getting extremely hot. If so, immediately turn off the device and debug as appropriate.

This completes the soldering of the remote and vehicle PCBs. Be sure to add a small dab of glue on the wires to keep them from breaking on both PCBs. Your PCB should turn on with the LiPo battery and turn on the power LEDs. Nothing interesting will happen at this time, we have yet to program the PCBs. We will revisit the PCBs when we integrate them into the mechanical CADed parts, and then program them!

Next up, we move onto arguably the most anticipated part of the BT RC Car project - CADing and modeling the actual car and remote!

CADing the BT RC Car

Navigate to the following link to access the BT RC Car GitHub Repository. Clone or download the repository to your local machine. (Same process for obtaining the EAGLE Libraries shown in the Introduction to EAGLE PCB Design tutorial). Unzip the .zip if you downloaded the repository.

In the bt_rc_car folder, navigate to mcad > BTRC remote case. You need to 3D print the remote_case_botto.STL part in this folder.

In the bt_rc_car folder, navigate to mcad > BTRC vehicle chassis > 3D print STL parts of car. You need to 3D print all of the .STL parts in this folder.

Watch and follow the following video where we walk you through the process of creating a 3D model in SolidWorks from a physical object through appropriate measurements.

Watch and follow the following video to create a 3D model of your BT RC Car Vehicle chassis mainframe.

After completing the last video, navidate to the downloaded or cloned BT RC Car repository to bt_rc_car > mcad > BTRC vehicle chassis. Open the BTRC car frame documentation.PDF. This will have SolidWorks Drawing diagrams for the remaining parts. You need to create these parts following the same principle from the previous video.

Create parts A, B, C, and D.

If you have not done so already, take the time to download and install Inkscape. The link to the Inkscape download page is here: https://inkscape.org/en/release/.

Next, watch and follow the following video where we demonstrate how to convert a SolidWorks object into a vector graphic. With this, we will be able to import a vector graphic into a 2D vector graphic software Inkscape. After which, we can use Inkscape to add some creativity and art to our PDFs that we will laser cut shortly.

Using the same principles as the previous video, personalize your remote cover. For example, you can add (a raster for) your name onto the cover. You can add other shapes and symbols. With some browsing around, you can find methods to engrave simple graphics from the web.

You may laser cut all BT RC Car vehicle chassis parts using ⅛" plywood. You may laser cut the BT RC Car remote cover part using ⅛" clear acrylic.

Finally, Watch and follow the following video where we demonstrate how we created the 3D model SolidWorks Assembly in the module 00 BT RC Car: System Overview.

This includes the CADing portion of the BT RC Car! Next, it is time to assemble everything together.

Remote Assembly

The remote is not terribly complicated in terms of assembly. But do be careful when assembling as everything is tightly fitted together.

You should have the following items from the Bill of Materials (BoM)

First we simply plug in the thumbsticks into the 5-pin right-angle (RA) female header pins.

Next, we insert the battery into the remote casing. The battery should fit snug into the remote. The battery leads can be facing either side on the top, or bottom. However, you should use strong tweezers to push the wires between the thumbstick peg so that it fits snug. Route the balancer connectors (i.e. the white JST connectors) around the pegs.

Connect the LiPo battery connector to the remote connector. Then fit the remote PCB into the remote casing. The thumbstick holes should fit snug around the pegs of the remote casing. Then screw in the screws.

Finally, simply place your remote cover over the remote casing, and plug in the bluetooth!

You can go ahead and turn on your remote. It is not doing anything yet, however the power LED should turn on the same as in the soldering module testing phase.

And that is all there is to it for the remote! We will return to programming the remote in the Integration module. Next up, vehicle assembly!

Vehicle Assembly

Now we demonstrate the vehicle chassis assembly through the following video. Again, take your time on this part to do it correctly as it is much more difficult than the remote. Pay attention to detail as this is essential to produce a high-quality vehicle that will run fast and handle well.

And this essentially completes the vehicle assembly. Be sure to run the motors to smooth out the gears.

To complete the vehicle assembly, solder the motor wires stemming from the PCB to the DC motor leads. We do not show any media for soldering the DC motor to the vehicle PCB motor wires - we hope this is straight forward. Do not worry about polarity, we will address the direction of motor actuation (or vehicle driving direction) in the Integration module.

Finally, onto the last module - actually putting this BT RC Car into action!

Remote

We will now progress testing the hardware on the remote one element at a time. Again, we do not have much to work with on the remote since we have no access to Serial debugging statements.

Bootloading and Programming the Remote ATtiny85

We encourage you to refamiliarize yourself with the AVR Microcontrollers and ATtinyX5 Microcontroller as they provide the general details of bootloading and programming the remote (i.e. ATtiny85). We will be using the Sparkfun Pocket AVR Programmer to both bootload and program the remote.

Remove the bluetooth if it is connected. Having the bluetooth connected messes up the upload process since they are sharing pins with the AVR ISP headers. It may result in bricking (i.e. destroying) your ATtiny85.

Rememeber, during the PCB Design: Remote & Vehicle module we did not connect the AVR ISP pins to power. So technically, we do not need to worry about the power target switch on the Pocket AVR Programmer. However, just to error on the side of caution and get you in the habit of being aware of it. Make sure the power target switch on the Pocket AVR Programmer is set to: No Power.

On the remote PCB, there should be an AVR ISP header as follows:

Note the small labels for the AVR ISP pins. With the Pocket AVR Programmer, insert the cable into the AVR ISP header as follows:

To remember the convention as to which direction the cable is to be inserted for future use, we use the following: The cable wires point towards VCC. Another convention is: MISO is pin 1 and is on the side of where the 2x3 cable header key resides

If you observed that there are two LEDs on, on our board, and one on yours, you are OK. Only one of your LEDs, the power LED, should be on. This photo was staged and taken after we already bootloaded and programmed the remote.

We are now ready to bootload the remote.

For both bootloading and programming the remote, do NOT have the bluetooth plugged into the remote. You risk destroying the ATtiny85.

Power on the remote if you have not already. Then, proceed to burn the bootloader.

If burning the bootloader fails, check that you are powering the remote and that you have the Pocket AVR Programmer cable mounted appropriately. If still no luck, debug the SPI connections between the AVR ISP header and the ATtiny85 to make sure none of them are shorted together, and that there is continuity between the appropriate signals.

Great! We are off to a good start.

Now it is time to program the ATtiny85. Fortunately, programming the ATtiny85 uses the same method as burning the bootloader.

We have intalled a debugging LED onto the remote. We were thinking ahead knowing the limited debugging capabilities of the remote without having a hardware UART.

So let us program the remote to simply blink this LED. If you recall from the PCB Design: Remote & Vehicle, the debugging LED pin connection is as follows:

Device	Arduino IDE Programming Pin #
Debugging LED	0

We will not display any media demonstrating this. It is pretty straight forward. If your LED is blinking at approximately the rate you set it at - you are good! If it is not, proceed to debug the circuit and check your code that you are using the appropriate pin or any other logic errors.

Thumbstick Calibration

Next up, the thumbsticks. Again, we have no debugging statements to read from the thumbsticks and print them to the Serial Monitor. However, we just tested the onboard LED and we actually have this LED on a PWM pin - and for a good reason. The analog readings we get will be between 0 - 1023. Note that, this is different from when we prototyped on the Arduino UNO. Why? Because the analog reference on the Arduino UNO is 5V. Even though we were using 3.3V to the thumbsticks during the prototyping phase, the analog reference was still referencing to 5V! Since our remote is powered by a 3.3V regulator, the analog reference on the remote is also at 3.3V - hence why we will get readings between 0 - 1023.

With these readings, we can map 0 - 1023 to 0 - 255 and analogWrite() this mapping to our onboard LED. This is a convenient sanity check before we transmit the readings over bluetooth.

The pinout for the thumbsticks are as follows:

Device	Arduino IDE Programming Pin #
Left thumbstick	A2
Right thumbstick	A3

We test each of the thumbsticks, one at a time, writing the mapping to the LED. It is hard to see it because it is next to the bright power LED. But as long as you discern that the brightness is changing we are signaled that the thumbstick (and LED) are behaving.

Testing of the left thumbstick:

Your thumbstick may actuate on the opposite direction depending on how you soldered the jumper.

Observe the LED brightness changing - it is subtle.

Testing of the right thumbstick:

Your thumbstick may actuate on the opposite direction depending on how you soldered the jumper.

Observe the LED brightness changing - it is subtle.

That tests the thumbsticks. They are ready to be transmitted when we get to it.

This completes the testing on the remote. Not much, as the hardware and software is relatively simple. Next we move onto the vehicle which is a bit more involved.

Vehicle

Similar to th remote, We will be testing the hardware on the vehicle one element at a time. Luckily, we do have the Serial Monitor on our side here if needed.

Bootloading the Vehicle ATMEGA328p

We encourage you to refamiliarize yourself with the AVR Microcontrollers and ATMEGA328p Microcontroller as they provide the general details of bootloading and programming the vehicle (i.e. ATMEGA328p). We will be using the Sparkfun Pocket AVR Programmer to both bootload the vehicle - and this will happen just once. As for programming the vehicle we will utilize the Sparkfun FTDI Basic Breakout (3.3V) device (i.e. Serial Programmer).

Rememeber, during the PCB Design: Remote & Vehicle module we did not connect the AVR ISP pins to power. So technically, we do not need to worry about the power target switch on the Pocket AVR Programmer. However, just to error on the side of caution and get you in the habit of being aware of it. Make sure the power target switch on the Pocket AVR Programmer is set to: No Power.

On the vehicle PCB, there should be an AVR ISP header as follows:

Note the small labels for the AVR ISP pins. With the Pocket AVR Programmer, insert the cable into the AVR ISP header as follows:

To remember the convention as to which direction the cable is to be inserted for future use, we use the following: The cable wires point towards VCC. Another convention is: MISO is pin 1 and is on the side of where the 2x3 cable header key resides

We are now ready to bootload the vehicle (i.e. ATMEGA328p).

For bootloading the vehicle, do NOT have the bluetooth plugged into the vehicle.

Power on the vehicle if you have not already. Then, proceed to burn the bootloader.

If burning the bootloader fails, check that you are powering the vehicle and that you have the Pocket AVR Programmer cable mounted appropriately. If still no luck, debug the SPI connections between the AVR ISP header and the ATMEGA328p to make sure none of them are shorted together, and that there is continuity between the appropriate signals.

Great! We are off to a good start. Now we are ready to program the vehicle!

Programming the ATMEGA328p

Now it is time to program the vehicle (i.e. ATMEGA328p). We will be programming the vehicle with the Sparkfun FTDI Basic Breakout - 3.3V (i.e. Serial Programmer).

We did not install a debugging LED onto the vehicle. Perhaps on a future iteration we will do this.

However, we will still describe the process for programming the vehicle here.

It is important to always remove the bluetooth if it is connected. Having the bluetooth connected messes up the upload process since it is connected to the same TX/RX pins as the Serial Programmer, so when the Serial Programmer tries to program the vehicle it sends signals to both the ATMEGA328p and the bluetooth HM-10. Both of these devices will "respond" to the attempt to be programmed and will confuse the Serial Programmer which will (usually) throw a syncing error on the Arduino IDE.

The location of the Serial Programmer headers is as follows:

There are some labels, however as you can see, they are being blocked by some other silkscreen and component footprints.

The Serial Programmer connects to the header as follows:

Be sure to power the vehicle, then uploading to the vehicle will be straight forward. It will be like literally programming a custom Arduino UNO.

Remember to also remove the bluetooth HM-10 when programming too!

Servo Calibration

Next, we will perform servo calibrations. After all we want the car to go as straight as possible without actuating the steering thumbstick. However, some servos with the horn attached, even written at 90 degrees will not be perfectly centered. Even with this calibration it might not be perfectly centered - however, we will do our best to center it. Other reasons for non-perfect straight movement depends on the wheels, some imperfections in the wheels, 3D printed parts, and laser cut pieces.

The other calibration we want to make is the servo handling, or turning, range. That is, how far will the wheels move in either direction when actuating the thumbstick. Ideally we would turn starting at the center of (ideally) 90 degrees, then turn left 90 degrees, and right 90 degrees, giving us the full 180 degree range of the servo. However, if you try this, the design of the vehicle does not allow the full 90 degrees. The 3D-printed servo bar that allows the wheels to turn will slip out before it reaches the full 90 degrees in each direction. Even if it could, we would not want this. Since our vehicle has a very simple design that does not utilize a differential to allow for better handling. So, if we turn too hard, the position of the wheels will start to reduce our ability to move the car forward and backward. (It is tough to describe, so feel free to experiment with this to see for yourself). With that said, this is designed to be a simple car. So, we want to restrict the range to allow an acceptable amount of handling. Regardless, it will still be a fun zippy BT RC Car.

The header for the servo is as follows:

The servo does have a polarity. There are three wires for the servo. Power, ground, and signal. Power (VCC) is red, ground (GND) is black, and signal (SIG) is orange or white. The PCB has labels for the servo header, so connect the servo appropriately.

The pinout for the servo is as follows:

Device	Arduino Programming Pin #
Servo	9

Now it is time to calibrate the servo. We will start by calibrating the center position.

We recommend to start by writing the servo at 90 degrees and see the alignment. Then proceed to adjust as appropriately until you are satisfied with the center-most position.

Uncentered Servo Horn

Centered Servo Horn

Next, we will calibrate the range of handling. With your newly defined center. We recommend sweeping the servo side-to-side evenly across the center. Calibrate the range with these couple things in mind:

Do not sweep so far as to have the horn slip out of the servo bar.

Consider the trade off of how wide your turn radius will be depending on how large your sweeping is.

If you see the vehicle chassis actuate far enough to start to displace the wood chassis, consider reducing the sweep range. This may be putting too much stress on the chassis.

If you sweep over a small range, the vehicle turn radius will be larger. That is, you will not turn as sharply.

If you sweep over a large range, the vehicle turn radius will be smaller. That is, you will turn more sharply. However, it increases the friction of the turns, so it will be harder to move the vehicle both forward or backward.

Here is what our servo range calibration looks like:

This is probably about as much stress on the chassis we want to apply before we risk breaking the chassis or reducing the lifespan of the chassis.

Again, we are showing about the maximum distance, you are more than welcome to reduce the handling range, and even adjust this later as well after you start driving the BT RC Car around!

This sets the center and range calibration for the servo. Take note of these values, this range is what we will map the steering thumbstick to.

Motor + H-Bridge Direction Calibration

Finally, we will test the motor and H-bridge. We want to make sure that everything is working and that the motor rotates in both the forward and backward direction. This will also help us to determine what state phase needs to be written as for the appropriate forward and backward direction.

During our testing we do not want our vehicle to drive uncontrollably away from us, so make sure to prop-up the vehicle such that it cannot run away form us. We used the bluetooth modules (jokingly to remind you that you should not have them plugged in while we are programming the vehicle). But anything that allows at least the back-wheels to be raised will work.

Make sure nothing will rub against the gear that protrudes from the bottom of the vehicle when propping-up the vehicle.

The pinout for the H-Bridge is as follows:

Device Physical Pin	Arduino Programming Pin #
H-Bridge enable	6
H-Bridge phase	5

Next, you can write any program you want to test the vehicle. We are sweeping the motor up, from 0 - 255, then back down, from 255 - 0, in both the forward and backward direction.

If you hear a high-pitched whirring sound when writing very low PWM values - this is normal. It means that the motor is stalled and is not good for the motor in general. When the motor is stalled it pulls a lot of current, that may cause the servo to bug out (even though we were very careful to isolate the motor and servo from each other).

Take note of what state the H-Bridge phase is for both the forward and backward direction. We will map the throttle thumbstick to actuate the motor in the appropriate direction at the speed we desire.

This completes the testing on the vehicle. We are now ready to bridge the connection between the vehicle and remote via the bluetooth HM-10.

Bluetooth HM-10

This is it. We tested all the hardware components except the bluetooth. And the reason is obviously because we need both devices to do this. This is where we have to take a leap of faith. Recall the ATtiny85 gives us no Serial Monitor feedback. However, the ATMEGA328p does! And, in our project we only need the remote to talk to the vehicle and tell the vehicle to turn and drive. So this one-way communication is easy to test. We have the remote transmit to the Vehicle. If we are receiving the data on the vehicle, print it to the Serial Monitor, and it looks good - we are in business! If we do not get any information or it is not correct. We need to review the code. Remember, unless you soldered something pooly, we guarantee the PCB having gone through several revisions will work properly.

For the bluetooth, we literally coded the appropriate behavior in the Bluetooth: HM-10 module for controlling the servo and motor on the Arduino UNOs. However, there are minor adjustments needed to map to the different hardware, but the logic is all the same.

With that, we expect you to test out the bluetooth module on your own from the remote to the vehicle. We will only tell you what the hard-wired pins in case you forgot from the PCB Design: Remote & Vehicle for bluetooth module to the remote and vehicle.

Again, before you jump all the way to transmitting thumbstick data to control the vehicle servo and motor. We highly recommend making a separate program to test just transmitting hard-coded data over bluetooth from the remote to the vehicle.

The BT RC Car

At this point, you should have confirmed that all components of the BT RC Car are working on both the remote and vehicle. The rest is in your hands. You have the foundation set and now you just need to complete the realization of the BT RC Car on the production hardware. We have taken you through the prototyping phase. Take what you have learned and apply it to create the BT RC Car!

Once you get your car driving, you have effectively completed the BT RC Car project!