# AccelCar

Contents

Our project aims to take the fun of a Wii Remote and translate it to real life. The AccelCar is a remote-controlled car that is controlled by the way that a user tilts the remote, similar to the way Mario Kart Wii is played. The angle of the tilting determines the speed and direction in which the car should move.

The remote control consists of a gyroscope/accelerometer module, which is used to find the angle at which a user is tilting the remote. That information is sent over Bluetooth to the RC car, where those values are used to spin two wheels at the right speed and direction to get the car where it needs to go.

Our motivation for this project was to create a neat toy with unique controls that can be played by people of all ages.

## High Level Design

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

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 two 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 θy is 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 two 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.

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.

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 Bluetooth 2.0 standards. In addition, 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 on 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 two components: the remote and car.