AccelCar

High Level Design    top

Rationale and Inspiration

Originally, our plan was to create a quadcopter which was controlled in a similar manner to AccelCar's controls. We wanted to make something that could move around and interact with the physical world. Defying gravity was something we thought would be very cool to try, but unfortunately, some of the components we had did not work, and there were tight time constraints in terms of shipping in new components. Therefore, we changed the quadcopter into a remote-controlled car. For more information about the quadcopter, please see to the quadcopter section in the Appendix.

Background Math

Source:" Yaw Axis Corrected" by Yaw_Axis.svg: Auawise Licensed under CC BY-SA 3.0 via Wikimedia Commons.

Remote Control Tilt Angle

To calculate the angle at which the remote control was, we used the following equations:

where θ_x and θ_y are the pitch and roll of the accelerometer, and A_* is the measured acceleration data from the accelerometer module for the specified axis. (Source) Since the “atan” function in C’s “math.h” library returns the inverse tangent in radians, 57.295 factor simply converts the value from radians to degrees.

Mapping Angles to Speed and Direction

Once the tilt angle of the remote could be easily accessed by the microcontroller, we needed to figure out how to change the speed and direction of the car based off of these tilt angles. We decided to map the tilt angles linearly to the speed of the motors. Since the speed is controlled by the duty cycle of the PWM signal going from the MCU to the motor driver, this simply meant mapping 0-90 to 0-255. In addition, the angles are signed (i.e., the X-angle is negative if the remote is tilted forward and positive if the remote is tilted backwards), so the signs of the angles determined whether the wheels rotating forward or backwards. Negative angles simply translated to spinning the wheel in the opposite direction; we never set OCR0A or OCR0B to negative values. Thus, if the remote was only tilted forward or backward (with no side-to-side tilting) then the PWM values for the left and right motors (OCR0A and OCR0B) would be:

where θ_x is the pitch of the remote control, and θ_max is the tilt angle at which we want the motors to go full speed (60-70 degrees, since that is the greatest angle that a user would feel comfortable tilting the remote). Also, since it is possible for θ_x to to be greater than θ_max, we check the bounds on the calculated value to ensure that neither OCR0A nor OCR0B overflow.

The tricky part was determining how to change the PWM duty cycle for each motor so that the 2 motors would mirror the side-to-side angle of the remote. We wanted the speed of the turn to be related to both the pitch and roll of the remote. In other words, the more the remote was tilted forward/backward, the faster the turn would be; similarly, the more the remote was tilted left/right, the tighter the turn would be.

We determined that, in order have a quick turn for a large pitch and slower turn for a smaller pitch, the PWM values would have to be modified from the OCR0A/B calculated from the equation above. Furthermore, the tighter the turn, the greater difference we would need between the speed of the two wheels. We decided that for a right turn, we would keep the right wheel speed proportional to the pitch while also decreasing the left wheel speed. In short, the greater the sideways angle of the remote, the greater the decrease for the left wheel, and vice versa for a left turn.

If the remote was tilted sideways at its maximum angle, we want the tightest turn that we could get, so the wheels would be travelling in opposite directions (1 forward, 1 backward). Thus, if the car was tightly turning right, then the amount to subtract from the left wheel speed would be twice of what it originally was. If we wanted the car to turn less tightly, it would correspond to a smaller sideways tilt, and we would simply subtract less. So calculating the OCR0* for the slower motor is as follows:

where θ_yis the angle of the remote’s roll, and θ_max is the tilt angle at which we wanted the car to have its tightest turn.

The figure below describes how the wheels turn relative to the rest of the car when the car is moving forward, moving backward, making a sharp left turn, and making a sharp right turn. The diagrams are a top view of the wheels, and the front of the car is the top of the figure.

Logical Structure

Our project is structured so that it breaks down into 2 main components: the remote and the car. The operation of our car is summarized in the diagram below:

The three different modes of operation are just setting up the car, running the car, and stopping the car. Setting up the car is highlighted in green. Running the car normally is highlighted in black, and should the car lose Bluetooth connection with the remote, the car has a emergency stop.

Hardware Tradeoffs

Some considerations between possible hardware that could be used as opposed to the hardware that was chosen for the final project were:

1. DC motors vs. brushless motors vs. servos
2. Handwritten radio frequency protocol vs. Bluetooth communication
3. Plywood vs. acrylic car body

To go into more detail about 1, we chose to use DC motors, because when they have a gearbox, the car can run at a smooth and reasonable speed with enough torque to move the entire body of the car. Servos could replace the DC motors, but they generally run slower in terms of RPM with more torque. Due to our goal of making our car more of a real life Mario Kart, we eliminated the servo since it could run the car at a faster speed, even though it did move the car pretty well. Using the servos could give us more flexibility in designing the physical body of the car, as the car could be much heavier and the servos could move the car without any problem. There was no reason to have a bulkier car (unless we wanted our car to carry a lot of weight or push heavier objects such as other robots); thus, we eliminated the servo. The brushless motors that we managed to scrap from the old quadcopter project (add link to project?) had high rpm, but they required the use of motor controllers and a programming card to operate them. Due to timing constraints and that the brushless motors were designed for the use of quadcopters, we went with the DC motors.

The second hardware tradeoff was choosing between using Bluetooth and writing our own RF communication protocol between the remote and car. The benefits of regular RF communication are that it has longer range and is faster than Bluetooth. The disadvantages of using RF are that we would have to make sure we were not violating any rules regulating the radio frequency band, and whatever protocol we chose to use would have to be written by us. The benefits of using Bluetooth communication are that Bluetooth is widely used, and we did not have to worry as much about violating FCC rules that regulate the frequency band, as Bluetooth is used for data exchange over short distances. The only disadvantages of Bluetooth are that it is slower, and it appeared that our Bluetooth modules would only be able to communicate over short distances. Since the RC car does not operate at high speeds, the slower communication is not a huge issue. Also, we do not want to communicate with the car at a distance where we cannot visibly see the car, so the short range communication distance of the Bluetooth is not too much of a problem, either. Furthermore, through testing of our AccelCar, we determined that our Bluetooth modules actually have quite a large range. Another benefit is that since Bluetooth is so standardized, any smartphone could easily communicate with the car if we configured the modules to pair with any Bluetooth device, and a smartphone with an accelerometer could easily act as a remote in place of the remote we have created. A final advantage to using Bluetooth was that a previous ECE 4760 group, Ellen Chuang and Julie Wang (Wireless Pedometer), already had useful documentation for using the HC-05 Bluetooth module, so this implied easy setup.

The final tradeoff between hardware was choosing between the material for the body of the car. We had a choice between acrylic and plywood, and we chose plywood over acrylic, because plywood is very easy to drill holes into to customize the motors to mount onto the body easily. Acrylic requires a special drill bit to create a hole, which Phillips 238 does not seem to have. It is very likely a drill bit could be cracked if used incorrectly. In addition, the acrylic would have to be laser cut to get the rectangle shape of the body. The plywood was easier to cut with a saw, so we used the plywood in favor of the acrylic.

Software Tradeoffs

Some tradeoffs between software were designing our own communication protocol versus using the Bluetooth protocol. While designing our own RF protocol would have meant that communication between the remote and car would be faster, we decided to use prepackaged Bluetooth instead, because speed was not as much of an issue for this project, and because we felt that the time spent sorting out bare RF would be better spent elsewhere.

Another software tradeoff was deciding whether or not to take advantage of the accelerometers and Bluetooth capabilities of cell phones, in order to make our device even more extensible and user friendly. We decided not to do this due to time constraints, but it would certainly be possible to do this.

To avoid jitter in the angles sent from the remote, we only send values from the remote every 100 ms. This is still fast enough to achieve relatively seamless controlling.

Standards

Our final project utilizes a HC-05 Bluetooth transceiver module which complies with the V2.0 Bluetooth standards. In addition, the Peter Fleury’s I2C C library was used to communication with the MPU-6050 accelerometer/gyroscope sensor.

Existing Products

We found several projects online that are similar to ours, in that they are remote-controlled cars whose motions are controlled by the tilt angle of the controller. They differ from our project in the type of remote control that is used and in the way that data is transmitted from the remote to the car.

A previous ECE 4760 project, Accelerometer Controlled R/C Vehicle (Fall 2008), is based on a similar concept and was created for similar reasons (ease of use and fun), but it uses regular RF instead of Bluetooth to send data to the car.

The Accelerometer Car project on Instructables [link] also uses a regular RF receiver/transmitter to communicate between the car and remote.

The Arduino Android Gyroscope Bluetooth-Controlled Car (YouTube [link]) uses the accelerometer/gyroscope and Bluetooth on an Android phone in much the same way that we did for our remote.

Lasty, the ROBOCar [link] uses a Raspberry Pi on the car and an actual Wii Remote as the controller.

While various incarnations of this project have been done in the past, our project still presented unique challenges in the way that our various components and modules worked and interacted.

A quick search of Google Patents [link] reveals that U.S. Patent US8106748 details a similar structure to the one in our project, but our project differs from the patent in that our remote control only has accelerometer sensing, with no manual input mode.

Overall Design Approach

The design of the AccelCar involves the construction of 2 components: the remote and car.

As can be seen in the diagram above, the remote is composed of the Atmega1284P microcontroller, an accelerometer/gyroscope sensor where the microcontroller obtains data from the chip, and a Bluetooth transceiver to transmit commands to the car. On the car side, the microcontroller controls the direction and speed of the motors as well as receives the commands from the remote through its Bluetooth transceiver.

Software Design   top

As mentioned earlier, our entire project was broken down into two main components: the remote and car. Since these are 2 physically different components, the software for them are different from each other.

Remote

The remote is composed of two main hardware components: the accelerometer/gyroscope breakout board and the HC-05 Bluetooth transceiver. The software of the remote therefore involved integrating the information received from and sent to these two components.

Gyroscope/Accelerometer

The accelerometer board utilizes I2C protocol to communicate the values of the acceleration vector of the board on the xyz plane. Therefore, we had to set up an I2C library in our code for the remote to do basic I2C signals such as the start and stop signals. We utilized Peter Fleury’s I2C library for AVR which contained these basic functions. We also referenced Brian Harding’s I2C code from the Spring 2011 project, FaceAccess [link], as an example of using Peter Fleury’s library.

To get the accelerometer to return data to the microcontroller, it was very important for us to read from the MPU-6050 datasheet and register map which had all of the relevant information for the sequence of commands we should send out to the accelerometer in order to get information or write information to the board. Here is some of the information that was pulled from the data sheet that is useful for understanding how I2C worked with the accelerometer board.

HC-05 Bluetooth Module

The HC-05 Bluetooth module is meant to be plug-and-play using the MCU’s UART pins. While we had some issues setting up the modules, once the hardware was set up, sending information over the Bluetooth modules was as simple as sending information to stdout and reading information from stdin. From the remote, we sent ordered pairs of integers, made up of the tilt on the x angle and the tilt on the y angle of the accelerometer. The Bluetooth module on the car receives those pairs and scans in the angles so that they can be converted to appropriate PWM values for the motors.

We actually had some trouble reading in stdout (e.g., getting garbage data, getting only some values, etc.). When we were sure that the issue was not in hardware (i.e., baud rate, pin connections), we fixed the software as follows: We ensured that the format we were scanning from stdin was the same as what was being sent (printed) to stdout. We used TinyRealTime so that motor control code was not interfering with reading in from the UART. fscanf for stdin is delimited by whitespace, so the ordered pairs being sent over Bluetooth cannot have spaces. In other words, we send (x_angle,y_angle) and not (x_angle,<space>y_angle).

Emergency Stop Button

The remote also has an “emergency stop” push button, which can be used to stop the car remotely. When this button is pressed, it pulls the interrupt pin of the MCU (pin D.3) HIGH; when it is released, this pin is LOW. Thus, our remote code enables the external interrupt and has one interrupt service routine (ISR). The ISR is triggered on either a positive or negative edge of D.3, so when the button is pressed and held down, the ISR sets a flag that says that the car should stop. When the button is released, the ISR clears that flag. This flag is checked each time before the Bluetooth module sends a message over UART, to see if the message sent should be the actual angles read in by the accelerometer or just zeros.

Car

The program on the car involves reading in data from the Bluetooth module (see section above for details), then mapping the angles read in (through UART) from the module to PWM signals. These two steps are done in two separate tasks on TinyRealTime so that angles can be read in parallel to the PWM values being updated. The mapping from angle to PWM value simply implements the math discussed in the “Background Math” section above.

The car also has an emergency stop, which is activated when a pin connected to the STATE pin of the HC-05 becomes LOW. This part is done by polling, since checking the state of one pin does not take much extra time and because, due to the slow speed of the car, we can afford to wait a couple extra milliseconds between polls.

Hardware Design   top

As mentioned earlier in the Overall Design Approach section, there were 2 main hardware components: the car and remote. The figure above shows how the hardware would interact with each other.

Remote

A more specific schematic of the remote is shown in the Schematics section of the Appendix.

On the remote, there is a HC-05 Bluetooth Module that is powered by 5V and connected directly to the RX and TX of the microcontroller to communicate through UART. There is also a GY-521 breakout board for the MPU-6050, which is the accelerometer sensor used to measure the tilt angle of the remote. The SCL and SDA are pulled up to 5V with a 4.1k. The AD0 pin is pulled down to ground to ensure that the slave address of the board defaults to 0x68. If it was pulled up to 5V, the slave address would otherwise be 0x69. In addition, there is a normally open button/switch connected to port D2 pulled down to ground for the user’s benefit. When the switch is closed, the microcontroller will send out stop commands to the car just in case the user wanted to stop the car, or stop it and reorient the remote.

Car

The car’s circuitry is slightly more complicated than the remote. The schematic is shown in the Schematics section of the Appendix.

The main components of the car circuitry are the Atmega1284P, H-Bridge breakout board, motors & flyback diodes, HC-05 Bluetooth module, and voltage level converter. Notice that there is a 6V power source (4 AA batteries) for just the motors and a 9V battery to power just the microcontroller. The DC motors that were used are 3V to 6V, so the 4 AA batteries are enought to move them.

The TB6612FNG motor driver breakout board we used can supply up to 1.2A for the motors, which is enough for the DC motors to produce enough torque to move the entire car. It also contains 2 H-bridges, which is needed for our purposes to allow the car to move forward, backward, and turn by turning the direction of motors in clockwise or counterclockwise direction. The breakout board datasheet contains specifications for different modes of operation: clockwise & counterclockwise turning of motor, change of speed, and stopping the car. The table about these modes are located in the datasheet and displayed below:

We had to follow these specifications to control our motors. Ports A0 to A4 of the microcontroller control the direction in which the motor should be spinning (clockwise or counterclockwise) by controlling the voltage levels of the AIN or BIN pins of the H-bridge breakout. The STBY pin is always high when we want the motors turning. The 2 PWM signals coming from the microcontroller (ports B3 and B4) control the speed of each motor, and they go into the PWMA and PWMB pins of the motor driver board. The pins A01-2 and B01-2 are outputs of the motor driver to apply a voltage across the DC motors.

Another part of the car was the Bluetooth transceiver which will receive the commands coming from the other Bluetooth module on the remote. This Bluetooth transceiver was again directly connected to the Rx and Tx pins of the microcontroller to communicate through UART. However, for this circuit, we need to read the STATE pin of the Bluetooth to see if the transceiver somehow lost connection with the other module. We measured that the STATE pin outputs 3.3V when the Bluetooth is paired with another device and 0V when it is not paired with anything. We want the car to automatically stop if it loses communication with the master control, and the microcontroller can read this change in voltage as a interrupt and stop the car. However, the microcontroller cannot register the level of a pin as 1 unless the voltage on the pin is around 4V and above, so we had to use a voltage level shifter to shift the 3.3V to 5V so the microcontroller could detect the change in voltage. The voltage level shifter breakout board was relatively easy to use, and you had to supply it 5V and 3.3V (on HV and LV pin respectively)for it to output a 5V on pin TX0 when the input (pin TX1) was 3.3V and output 0V when input is 0V. If you didn’t supply the level shifter with 3.3V, it would always output a 5V to TX0 pin, which would never change the voltage level on pin D3.

Physical Design

The physical design of the car involved creating a car chassis to hold all of the electronics and batteries as well as have it easily mount with the motors and wheels. The body of the car had dimensions of 7 inches by 6.25 inches, just wide and long enough to fit the 2 motors and the soldered board & microcontroller. The chassis was made of plywood and holes were drilled to allow easy mounting of the 2 DC motors and the 3rd ball bearing wheel. Plywood was also strong enogh to hold the microcontroller, soldered car circuit, motors & wheels, and the 4 AA battery pack. Some components were significantly heavier than others, so we had to distribute the weight evenly throughout the car to prevent flipping. The battery pack was place between the 2 DC motors to keep the weight in the center.

Top view of AccelCar

Bottom view of AccelCar

Testing

One of the main methods that we used to debug the car and remote circuitry, as well as certain components, was using UART to print out the values of variables in software. Another method that we employed was splitting up the code for distinctive modules like accelerometer sensor and Bluetooth module code before integrating all of them together. For figuring out I2C to interact with the accelerometer breakout board, we had to debug with hardware and software.

To ensure that the I2C library was working, we used the oscilloscope to display the voltage levels of the SCL and SDA lines of the microcontroller. For example, we had code that would utilize the i2c_start(), i2c_write(), and i2c_stop() methods of Peter Fleury. The sample sequence for the first oscilloscope shot below was: Start, slave’s address (0x68) + write bit (0), acknowledge, write a specific register address of the accelerometer board - WHOAMI (0x75), acknowledge, start, slave address + read bit (0), acknowledge, data from slave, not acknowledge, and stop. This sequence was requesting the contents of the WHO_AM_I register of the accelerometer board, and the slave data that was returned was 0x68, which was expected.

Read contents of WHO_AM_I register of accelerometer board

The 2nd test sequence we wrote to the accelerometer was to set the configuration of the gyroscope to full scale range of 2000 degrees/second to see if the write sequence worked. The data written to GYRO__CONFIG register was 0b00011000. It appeared that all of the signals were outputted correctly from the microcontroller to the accelerometer correctly.

Write 00011000 to GYRO_CONFIG register

Then, when we noticed that we still could not get data from the accelerometer board, we searched online and found that the board is initially asleep and needs to be woken up to send data to the microcontroller. To figure out if two Bluetooth modules were communicating data to each other, we set up two microcontrollers so that one microcontroller sent the strings “on” and “off” repeatedly, and the other microcontroller physically turned on or off a green LED to match what it received.

Once everything was put together, we tested the system as a whole. This involved first ensuring that the car’s wheels would spin when the remote was tilted. Doing this check verified that we were able to get tilt angle values to from the remote to the car. Another test was to check how quickly the car responded to the remote, which we could do by simply tilting the remote back and forth and seeing how quickly the car’s wheels changed direction. The final test of the system as a whole was the turning and maneuverability of the car. For our first iteration of the turning code, we found that there were issues with the signs of the numbers we were sending to the car, as well as not handling turns correctly when the car was going in reverse. Thorough testing of the car ensured that a user unfamiliar with the car would not be thrown off by quirks or bugs in the car’s operation.

Another important test was checking to see that the car stopped when the Bluetooth module on it got disconnected from the remote. To test this, we first tilted the remote to give the car a starting speed, then turned off the MCU on the remote (thus powering down the remote’s Bluetooth module) to see that the car eventually stopped.