MECANUM COLLISION VEHICLE

By Kiet Nguyen, Edwin Varela ECE 153B Winter 2020

DATE: Week of 02/20/2020

The components we ordered from Amazon have finally arrived. We ordered stepper motors, drivers, and a battery pack. The goal for this week is to determine what other components are missing and how to power and drive the motors. We also made a tentative schematic for our vehicle.

DATE: Week of 02/29/2020

This week we focused on setting up the Creality Ender 3 pro 3D printer and used it to print the parts we need for the wheels. We also worked on getting the stm32 board to communicate with the a4988 drivers to power the motors.

After adjusting the printer we finally got some good prints.

DATE: Week of 03/02/20

We finished the skeleton code that will generate the PWM for each pin that drives the ultrasonic sensors, Bluetooth transceiver, and the individual motors. We chose pins A0 A1 A2 A3 and TIM2 for the drivers to control the motors. We use one timer and its four channels to create four different PWMs with four different CCR values. The ARR is the same for the four channels that share the timer. The direction pins for the drivers are E10, E13, E12, and E15. The Bluetooth uses B6 and B7 for transmitting and receiving and the accelerometer uses pins B8 and B9. In addition, we're planning to add the car remote control feature using the Bluetooth transceiver.

We are running into a problem; the NEMA 17 motors won't spin even with the driver are being fed the appropriate PWM. We measured this using a oscilloscope. We tried to test the motor with the Arduino UNO board and saw that even with the PWM, the motor wouldn't spin. One possibility is that our logic voltage input is not high enough for the driver to detect the binary logic. More testing and debugging!

DATE: Week of 03/08/20

This week we finished assembling the base and 4 mecanum wheels we 3D printed for the vehicle. The wheels required various rollers that are offset by 45 degrees. This formation allows the vehicle to move laterally left and right not just forward and back. This is accomplished by setting the direction of each wheel separately; which is something we still need to work on this week. The base had to be printed in parts because it was too large for the printer. To modify the base and the wheels we used Autodesk Fusion 360. Ones we had the dimensions we wanted we used Cura (a slicer program) to translate the 3D models from STL files to g-code files (file format for 3D printer). To connect the base together we printed a connection platform with aligned holes for bolts and nuts.

After a few hours in the lab we were able to set the control speed and direction for each individual motor. The problem we were having previously was solved by adjusting the potentiometer on the drivers.

Unlike many motors that run on logic active high input, Nema 17 stepper motors run on transitions of the input, which is a PWM. Therefore, many motors use the levels of input voltage in order to determine the angular speed, but in order to do the same for Nema 17 stepper motors, the frequencies are adjusted. Given the board STM32L476 that has a limited number of physical GPIO pins, we are able to use four physical GPIO pins that operate on one timer and four channels. The four channels will have the same PSC (prescaled) value and ARR value, but each individual channel will have 4 different CRR values, having 4 different duty cycles. The difference in duty cycle, however, won’t affect the spinning speed. The requirement for each driver pin are:

DIRECTION – logic input – 0-3.3V

STEP – PWM

VDD – 5V from the STM32 board

1B, 1A, 2A, 2B – Motor’s coils

GND – ground

VMOT – battery voltage for the motors (8-15V)

It’s possible to use one pin to generate a common PWM for all four drivers/motors, but due to the flexibility-oriented design of the project, where each individual runs at a logic input (on/off) or at a different direction, 4 pins are required for the PWMs, and another 4 pins are required for 4 directions. The other pins on the driver are not needed, as we are running the wheels with full-step resolution. However, when we need to turn the vessel, it’s required that both wheels on one side spin faster than the two on the other side, which means they must have different frequencies.

We overcame this challenge of using one timer to output 4 different frequencies. The frequencies are to be determined by software. We define 4 variables called “factors” (front-left, front-right, back-left, back-right). Given a PWM, we can set the channel output to low/high depending on how large the “bigger period” is. For example, to turn the vessel in the right direction, the left wheels must spin faster the right wheels.

Next in the agenda is to fully implement the Bluetooth and Ultrasonic sensors for collision detection and figure out the power supply connection.

Expected Behavior:

Vidoes: Vehicle Performance

Provision:

One reason we believe that the vehicle struggles to move laterally left and right is because of the weight of the robot. We also think that the quality of the 3D printed wheel can be improved. We noticed that some of the rollers needed for movement were not spinning loosely enough. We also attempted to use both the built-in L3GD20 gyroscope and the LSM303C accelerometer to measure the rotate angle and accelerated speed. Although the gyroscope and the accelerometer works separately, when implemented together, they run into the communication conflict which leads to the issue that only one of the modules can run at a time. As far as we know, this is due to how the SPI_Read/Write functions (full-duplex mode) are implemented for the gyroscope, as in order to make the accelerometer work, we have to write the code for the SPI protocol communicating in half-duplex mode separately. The acceleration is supposedly used to measure the speed and the angular speed measured from the gyroscope to measure the turn angle. Perhaps, designing a pcb board could help the performance and look of the robot be reducing weight and clutter.