MECANUM COLLISION VEHICLE
By Kiet Nguyen, Edwin Varela ECE 153B Winter 2020
Objective:
Our goal is to build a small robotic vehicle that can move laterally left and right as well as forward and back. We will attempt to use ultrasonic sensors to avoid obstacles and the accelerometer to display acceleration. We will be custom printing 3D Menacum Wheels and a base for the vehicle. The robot will be controlled via Bluetooth and will have an autopilot collision detection mode.
Components:
4 x Nema 17 Stepper Motor
4 x A4988 Drivers
HC 05 Bluetooth Tranceiver
STM32 Board
Ultrasonic Sensor
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.
Ordered Parts
Potential Schematic
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.
Fully assembled 3D printer
After setting up the printer our first print came out awful. It turns out we needed to adjust the belts of the x and y axis or else we would get pretty nasty looking layer shifts.
After adjusting the printer we finally got some good prints.
Roller for the Wheels
Left Outer Wheel Base
Printed Wheel Base
Left Inner Wheel Base
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!
Trying to Drive the Motors
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.
Editing Base Model
Mecanum Wheels
Base of the vehicle. No ceiling.
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.
Controlling Multiple Motors
Different frequency for different wheels using one timer.
DATE: Week of 03/15/20
This week we assembled and wired the vehicle completely. It took many hours to get all the components to work and communicate properly. One issue was ensuring that each peripheral was powered with the right voltage. We ended up frying 2 stm32 boards completely after "accidentally" passing 13 V to them when our voltage divider failed. Luckily, a friend let us use his board so we had to be very careful not to damage this one-since it would be the last board we had. We also had to file the wheels to properly fit them to the motors. The rollers on the wheels also required additional lubrication to reduce friction and allow proper lateral movement.
The built-in LSM303C accelerometer is configured to operate on 100GHz datarate, 2-g offset scale, and SPI communication protocol. At first we planned to implement the communication using the I2C protocol but we found it easier to do it in SPI. We did not implement the high-pass filter and the offset calibrator which can drastically enhance the acceleration measurement, given the the limited amount of time for the project. It is important to calibrate and calculate the initial offset for the accelerometer before it starts. We manually did some measurements and calculate the average of the offsets for two axes (x and y; z is not used in our project) and subtract the measured values from the offset. The raw output values have to be converted from the g-values to m/s^2 unit, with the tolerance of ±0.05. We believe that with the high-pass filter, we could get better accuracy for the measurement.
Given the half-duplex communication nature, we found it necessary to have one SPI connection pack alternate between half-duplex configuration for the LSM303C module and full-duplex configuration for the L3GD20 module. The design aims for very packed setup, so only one SPI is needed for the two modules.
About the functionality of the motors, there is a tradeoff between speed and torque. The faster it spins, the less torque it produces. For this reason, every time the vehicle, which is considerably heavy in weights, attempts to reduce its wheels' angular speed to increase the torque. More info in the nema 17 datasheet.
Fully Assembled
The Vehicle is able to functions but we are still having issues with how smooth it moves. We also need to adjust the Ultrasonic sensor and accelerometer configurations to get accurate readings.
Vehicle Controls:
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.