Electric Vehicle Charge Robot Lite

Hi everyone! My name is Tyler Erwin and I'm a senior at San Jose State University majoring in Mechanical Engineering with a minor in Robotics. I was joined on this project by Michael Kamas, Julia Casares-Iglesias, Charlie Nino, and Eric Ling. They are all majoring in Mechanical Engineering as well. We're all members of SJSU's American Society of Mechanical Engineering (ASME).

Our Project was to develop an Electric Vehicle charging robot to overcome some of the limitations of charging electric vehicles. There are ongoing research studies of automated robotics being utilized to charge electric vehicles in order to minimize user interaction with the pump. Our mechanical engineering department has a similar project that we used as a reference to ensure our drone ran efficiently. To make our robot unique, we utilized a square design, color sensors for lane detection, created code with MicroPython, and placed the scissor jack component on the top of the robot. Additionally, our vehicle isn’t large enough to charge an electric vehicle. However, our robot can be used to charge a cellular device. However, this robot can be developed at a larger scale to hold the correct charging components for an electric vehicle.

Our model is fully functioning and shows an understanding of how mecanum wheels, object detection, lane detection, robotics controls and processing from various sensors. Our vehicle can follow a lane to a charging point, charge at the station, then return from the station to rest at the resting point.

As one of the leading innovative fields shaping our future, electric vehicles are an evolving market that requires numerous innovative solutions in order to function. One of the leading aspects of EVs that cause them to be under appraised is the limits of charging. Not only for the consumer, but for the manufacturer, storage and sites are in high demand across the nation. Stations require complex build planning that costs exuberant amounts. Additionally, for the consumer, sometimes it may be hard for the individual to grasp how to charge their vehicle.

In our design some of the components we incorporated are the Raspberry Pi Pico, Motor Drivers ‘H-Bridge- L298 Module’, Grove Distance Sensors, 6V Battery pack and two TCS34725 Color and Light Sensors. Our vehicle is modular, so the lower part of the vehicle is the drive and main sensor compartment, with the upper section being used to actuate the scissor jack. We need to be able to detect lane changes, so a color sensor was determined in order to meet this objective. It does so by detecting the HUE value of the floor in which the robot rolls on, and based on this color it will actuate the mecanum wheels in a specific direction. Mecanum wheels are wheels with an omnidirectional design in order to allow vehicles to move in any direction. In order to achieve the direction changes of the vehicle, we needed 4 mecanum wheels connected to two drivers. One driver ran two of the same mecanum wheels, whether it be the left or right, in parallel. The voltage required to run this system made one of our additional objectives to find a battery system that controls the pico and the drivers separately. The mecanum wheels when run in the system can cause the vehicle to go forwards, backwards, strafe left, and strafe right. Then we wanted to make sure if the vehicle approaches an obstacle or wall, it doesn’t proceed to run into it. We utilized a distance sensor on each side of the vehicle in order to detect objects approaching and prevent the vehicle from crashing. We also connected LEDs into the system and utilized the Maker Pi Pico’s speaker in order to give information to the user of what state the vehicle is in and what it is detecting. This includes whether an object is detected, a color is detected, a charging point is identified, or the resting point is identified.

Please see the budget attached for the referenced supplies.

In order to actuate the mecanum wheels properly in the ideal directions the two left wheels would need to be diagonal from each other and vice versa for the right wheels. Both wheels of the same type would need to be connected in parallel to the driver, with the opposite black cord of one motor being placed in the same port as the red coord of the motor on the other side diagonally. This is to keep the wheel mounts the same position to make printing easier and to get the necessary drive. In order to drive the motors, we used the L298N drivers and set the ENA, IN1, and IN2 into the GPIO pins of the pico. We defined four functions for up, back, left, right and stop in order to easily understand the final code functionality. The states in the final code call on the functions in order to drive the robot.

Based on the part file specifications, we created the mounting holes for the DC motor onto the shape to allow it to sit against the part and spin with no tolerance issues. Additionally, we added two screw holes on the top that way we could attatch to the base plate.

In order to avoid collisions, object detection using ultrasonic distance sensors was necessary. Four sensors are placed with one on each side of the Charge Bot. The sensors are polled by the sonics() function near the start our code, which reads each sensor sequentially, compensates for read errors, determines the closest reading, and then returns the closest distance, the name of the sensor with that reading, and a list of all four readings as a 3 item tuple. The main code then calls this function within both movement loops (states 2 and 4). If the minimum reading is under a set range, it will then determine where it fits within 3 further ranges. Based on these values it will display the distance when running under the computer and stop all movement. The bot will also light all 4 indicator LEDs and beep a different tone for each of the 3 distance ranges, as shown in Figure 5. If no object is within a concerning range, all the distance readings are printed along with the current state and color reading.

The dimensions for the hole inserts of the top of the mecanum wheel mount was used on the bottom base to mount the wheels properly to the frame. From there we added extrusions for the distance sensors mounts, which we then extruded M2 screw holes to fasten the part to the frame. We also added a couple temporary screw holes that came in handy later for mounting the color sensors.

In order to actuate the robot, battery specifications needed to be met. A 5 volt power bank was needed to drive the microcontroller and the components powered by it. A 6 volt battery pack was needed to power the drivers. In theory the charging port for the phone can be connected to the extra USB in the power bank for the pico.

We reused the structure of the bottom base for the top base to have structural uniformity and ensure that the vehicle remained easily modular. Additionally we created a support overhang to ensure the tower was rigid and printed at a high infill. Additionally, because the DC motor needed to be mounted to the frame, we created an offset piece that holds the motor as shown in the fourth image. It is similar to the mecanum wheel mount just extended on the bottom to attach between the tower and the plate.

As the scissor jack utilizes the same motor type as the mecanum wheels, the code follows the same formatting for the jack as the mecanum wheels by defining 3 functions, “scissor_up”, “scissor_back”, and “scissor_stop” in order to actuate the jack. We did manually testing with various weights to determine the time to actuate the jack from the retracted to extended state, as we weren’t able to utilize the stepper motor we had purchased due to a low torque rating.

The scissor jack was the most sophisticated part of our project, requiring us to build a mechanism that we could simulate in Fusion 360 and print efficiently. We designed the contraption around the base slot we made, setting the furthest distance 6 inches apart. From there it was simple geometry to determine the link lengths and develop the model. We essentially flipped the bottom plate upside down for the top plate of the jack. We also separated the plate from the slot post production to make an easier print. We tried making both a DC motor and Stepper motor mount but finalized with the DC motor mount. We also made a slot holder for the quarter inch thread the motor turns and had 4 screw holes to tighten the joint. We have the jack fully simulated in Fusion 360, with the ability to actuate, perform FEA, and print straight from the model. We also toleranced the part to account for loose fits and tight fits. When applicable we used the nut cutouts on the slots so that the thread would slide through the nut as it moves.

We used the TCS34725 Color and Light Sensor to distinguish between path directions and find the destination. The library for this sensor had to be found online, as Adafruit only provided a library in CircuitPython. This library includes a function that returns a tuple containing the clarity, red, green, and blue values detected by the sensor. While helpful, having four pieces of data made it difficult to determine color at a glance. Our solution was a function that converted the CRGB value into the hue, saturation, and value. Hue specifically made the colors much easier to tell apart even in varying light conditions and at colors with two approximately equal values, such as yellow containing equal amounts of red and green.

This color sensor uses the I2C bus to communicate with the Pico. Since our original plans included four color sensors, we needed to find a way for each of the two I2C buses on the Pico to tell two of them apart. They have no alternate address, so the easiest solution would have been a multiplexer. Instead, we took advantage of the Pico machine library containing both I2C and SoftI2C, nearly identical libraries with the same functions. Identical sensors could be on the same bus without an address conflict if one was using I2C and the other used SoftI2C. Our final design only used two color sensors, however, so it was ultimately unnecessary, but the ability to use both on the same bus allowed greater flexibility in choosing which pins to use.

In order to mount the color sensor to the frame we used one of those extra holes on the top and bottom base plate to secure the color sensor. We used a similar concept to the ultrasonic distance sensor where based on the part specifications we mounted screw holes for the part to hold it in place.

We utilized Fusion 360’s FEA simulation software to run our mechanism under the identified load case. When running the simulation we used the actual load case of the scissor jack and the stresses that would be experienced by all of the links in the mechanism. In it, we found the material properties of PLA through another CAD package called OnShape (modulus of elasticity, yield strength, ultimate strength, etc.) and then imported these values into Fusion 360 to represent material properties as accurately as possible. 

The load case was to fix the bottom of the scissor jack as it would be fixed in it's real life use case, have the scissor jack at the fully extended position, and then add the load on the top plate of the scissor jack at its center with the load being the weight of the wireless charging module. We utilized the extended position as this was the setup identified to have the most stress.

Additionally, we ran the simulation to see the most likely area of displacement that would occur under the load fully extended. As expected, the load caused the side of the top plate least supported by the jointed system to bend. However, the amount of bend wasn’t to a high extent.

In order to 3D print the mechanism and allow for the ideal movement, particular sizings and sensible connections must be accounted for. We utilized M3 Screws as joint rods for our mechanism. In order to be a tight fit into parts, a 3 millimeter hole must be inserted. In order for a loose fit into parts, a 3.25 millimeter hole was needed. For the cross links and the slider slots, a 3.25 millimeter hole was needed. This would allow the jack to rotate freely. For the cross links and the rotating points on the bases, a 3 millimeter hole was needed. Additionally, the distance between the cross links in the CAD model is 4.5 inches, but in the physical model a 4.49 cross link is used to allow the cross links to not be a tight fit around the system.

We utilized an Creality Ender 3 printer to make all our parts. This was the main constraint for the size of the project, as we designed the entire model to fit within the space of an Ender 3 so we could print at home rather than taking up the club printers while other students were trying to print.

Every part was created with a 20% infill at a cubic format to be strong enough to withstand the weights of the objects attached while also having relatively small print times.

The outcome of our project was a success, we were able to learn about mechatronics and various controls, sensors mechanisms and MicroPython and our final product was able to perform despite some challenges. This project was a great learning experience not just for demonstrating what we learned but also having something to learn from and struggle through all of the challenges we faced and feel accomplished when things got resolved. Overall our project did work and perform well after numerous hurdles and accomplishments. It was important to be patient since it can be frustrating when components or code do not work the way we expect. Some of the major challenges we faced were surface friction and color sensor registry issues.

For the surface friction issue, our mecanum wheels were prone to slipping while on smooth surfaces going in one direction the bot might slide slightly, the various surfaces caused different effects but ultimately when adding the scissor jack, this extra weight helped to lessen the sliding. The color sensor was one that we did not get to experiment in any related course work with but the issue was with the color sensor registry and the RGB values that varied a lot. Additionally the shades of color, lighting, and glossiness of the paper also played a role in the library not matching the correct colors. Because of this we had to adapt our library to output more refined color registration (hues). 

The majority of our components for the body, mounts, and scissor lift had to be 3d printed, with our CAD model tolerances were a challenge to ensure everything fit together nicely. It took various test prints and some reprints to make sure everything was solid, all the holes lined up, pieces fit together and the structure was stable enough to not break. 

Some components, since many of them were borrowed from the university's mechatronics lab, after trying them out had to be switched for something different. We utilized a stepper motor that did not have a high enough max torque and was unable to successfully move our scissor jack, so we had to experiment with what we could get a hold of and ended up using the extra 1:90 DC Gear Motor to successfully incorporate it into the code and have it perform adequately. 

Improvements for further work and if we had more time to refine our product, we would ensure our color sensor had no issues reading new shades of the same color. We would also have more logic added into code to have more situations. Another part that may be added is a speaker that can play various sounds or voice recordings to play when there is someone standing in the way of our bot, the robot will politely ask them to move. We also want to likely develop a shell to hide the wiring on the inside, as we need all the wiring for the nearly 70 connections on the robot.