speedEV
ABOUT POE TEAM INTEGRATION SPRINTS COSTS CONTACT
Pick up and Go!
The only RC car you can drive at top speeds with no practice
The only RC car you can drive at top speeds with no practice

Learn more about the project

ABOUT THE PROJECT

What defines speedEV?

Easy

speedEV is an RC car designed to make driving as simple as possible. We have implemented intelligent driving controls which allow anyone to pick up a controller and enjoy driving at high speeds.

Connected

speedEV sends real-time car data over bluetooth to a remote computer. The computer interprets the data, allows users to visualize it, and sends speedEV a modified control algorithm to enhance the driving experience.

Robust

speedEV is built to last. We used tough materials like ABS and aluminum that make speedEV capable of enduring most conditions thrown at it. We are keen on creating an RC car that will hold up through the years.

Speedy

speedEV, as the name suggests, is speedy. Its motors generate 1 horsepower and can accelerate to 28mph in under 3 seconds!

Mechanical Integration

Our RC car contains three major mechanical systems, the chassis & mounting plates, the two drivetrains, and the steering system. Each system was designed to be easily manufacturable within the time and cost constraints. Our design decisions were made around a goal of creating an enjoyable driving experience. Analysis was performed to ensure that every component could withstand the forces they experience.


Drivetrain:


The design decisions made in the drivetrain make the most impact on the driving experience. We chose to use two seperate high horsepower motors so that we were never mechanically power limited. We chose an overall gear ratio that allows us to reach a reasonably high top speed, while maintaining enough available wheel torque to break traction at almost any speed. Having a drivetrain system that is slightly overpowered for our application allows us to use our custom electronics board and integrated sensor suite to actively limit and control our motors; ensuring an easy and enjoyable driving experience at any speed.

Chassis:

Our chassis and various mounting plates are all made from waterjet ABS plastic sheet. This material was chosen for its impact resistance, manufacturability, and relatively low cost. These ABS components utilize robust mortise and tenon joints. The components were designed to reduce stress concentrations and absorb impact energy, ensure our car is robust enough to be driven hard.

Steering:

Our steering system is a simple two-linkage mechanism to reduce slop and increase steering precision. The joint between the wheel assembly and the steering linkages utilizes a friction fit; although this requires more maintenance, it increases the longevity of our mechanical systems and reduces the need for repairs. If our front wheel hits an object, instead of the mechanical components permanently deflecting, the steering friction fit slips, absorbing the impact energy.

mech

Electrical Integration

The electrical system on the car is what connects all of the communications and controls to the mechanical system. We opted to go for a custom PCB rather than an arduino because we could make harnessing easier and provide breakouts for better integration.



Some key features of the system include a buck converter for steady and efficient power conversion from the battery. A problem we encountered early on was that an Arduino couldn’t drive all of our electrical components of a 9V battery. A buck was designed and implemented to mitigate this issue. A drawback of it includes the space it takes up compared to a cheaper but less efficient linear voltage regulator.

Another implementation is double redundancy for the microcontroller, so if in the future, if we required more IO or wanted to send data to multiple places and have multiple control loops, it can be easily integrated as some of the brakouts for the components like the accelerometer are shared and others are isolated, like our TX and RX lines.

What went well:

  • The board was capable of driving all electrical components
  • Manufacturing and turnaround times were fast and relatively cheap
  • Reverse protection in power input saved our board
What went poorly:
  • First revision did not work as intended
  • No positively retained connectors, which led to problems when the car was subjected to harsh conditions
Next steps:
  • Be more space efficient with the board
  • Reroute IO breakouts for easier harnessing (spatially conscious)

Takeaway: I have improved at specing components, designing PCBs and become faster
elec

Software/Firmware Integration

The firmware on the car is what is responsible for differentiating our project from a remote control car you buy off the shelf. Rather than routing the signal from the remote control directly to a steering or driving motor, the signal is processed and altered by an on board microcontroller. The firmware is also responsible for reading accelerometer data and outputting it over bluetooth.

Given that we all wanted to build a remote controlled vehicle with responsive controls, we determined that data from a "control room" application would inform the design of the control loop. The current iteration of the project plots the acceleration and angular velocity of the car in real time. Building this feature enables us to build more and more features later on, making it easy to extend the platform's capabilities.


FIRMWARE


A lot of the work of the work up front on the firmware side was in figuring out how to read data coming in from the RF receiver and transmit it back out to a motor. Once we eventually got that working, it was easy to start manipulating the signal. We developed an algorithm that allowed for a full range of steering at low seeds, while also attenuating the steering at high speeds to prevent the car from spinning out. We drove the car several times while we tuned the function, ultimately arriving on a parabolic attenuation curve with an offset, such that 100% steering was achieved at no throttle, and only 40% of the maximum steering angle was delivered at full throttle.

While we were able to implement a successful steering assist feature, we also hoped to develop one that could adapt in real time to accelerometer data. If the car sensed it was rotating faster than possible while maintaining traction, the car would automatically reduce the steering angle, and increase the steering attenuation factor. Unfortunately, the accelerometer data was so noisy that we could not do this reliably, and we could not sample at a high enough rate to use a rolling average of data points. If we had more time, we would have liked to debug this issue and implement accelerometer data into our steering algorithm.

Additionally, we would have liked to implement torque vectoring based on acceleration data. Not only did the accelerometer inhibit our ability to do this, but we also had trouble getting our Electronic Speed Controllers (ESCs) to work reliably with a 14.8V supply, so each motor got it’s own battery, and torque vectoring would not have enabled us to increase power delivery to the front/rear wheels as we had hoped.

What went well:

  • The code was written such that when it came time to add new features or change functionality, it was really easy
  • We were finished quickly enough to iteratively test and develop a steering assist algorithm
What went poorly:
  • We spent way to much time in the middle of the project trying to output PWM to the ESCs before asking for help, and wasted a lot of time.
Takeaways:
  • If we can’t solve a problem in 2-3 hours, ask for help, even if we still have new ideas to try. Having another set of eyes is really valuable.
  • Having a working MVP weeks ahead of time is SO useful for testing, validation, and optimization

SOFTWARE


I began with key requirements in mind before choosing the technologies we would use. The system had to be easily expandable, near real time, and quick to implement. After analyzing a few potential solutions, I decided to have a bluetooth connection between the Arduino and an Android phone. The Android phone would then push data through websocket to an online webapp.

The use of bluetooth allowed for an android app to control the car. The use of websockets allowed for any web application to send information to the android device, which can then change the state of the car. This opened up the possibility to have self driving programs run on the android device and send throttle and steering commands to the Arduino, or tune driver assist parameters from a web application. These are all features we would love to implement in the future.

The current web application is relatively simple. It takes in data from a websocket and plots the data using a javascript library called Plotly.js.

What went well:

  • We focused heavily on achieving our individual learning goals and based most of our project and engineering decisions off of that. I was able to learn a lot about new web technologies and build one of my first websites.
What went poorly:
  • Project scoping and everyone agreeing on what the MVP is could have happened more quickly and been more clear. From the beginning, we didn't have a super clear definition of the MVP to work towards.
  • We struggled with focusing energy on the most valuable problems at any given time. In this context, a valuable problem is one that once solved, would move us closer to our MVP by the largest amount.
Takeaways:
  • I learned that having a clear definition for a project to work off of is very important in a team environment.

Full Documentation at github

firm

THE TEAM

Some cool guys

James

James Ho

Project Manager / Software Integration

Enjoys going to bed at 9pm when there is lots of work to be done.

Kyle

Kyle McCracken

Mechanical Integration

Enjoys spending copious amounts of time re-machining components after breaking them.

Adi

Aditya Sudhakar

Electrical Integration

Enjoys forgetting heatshrink every time he solders wire.

Alex



Alexander Wenstrup

Firmware Integration

Enjoys plugging everything in backwards, often frying important things.

15+
Cans of Redbull
20+
Connectors Made
80+
Hours Debugging
1
Sexy RC Car

OUR SKILLS

Subjects & Overlap

×

CONTACT US

Lets get in touch. Send us a message:

Needham, MA, US

James: jho@olin.edu

Kyle: kmccracken@olin.edu

Adi: asudhakar@olin.edu

Alex: awenstrup@olin.edu