Drive train system integration plan
Scope
The scope of the document is to provide a practical guide for all the members to help make the drivetrain system move before June 15th. Note: June 15th is the deadline agreed upon by all UWRT group members to complete the system. We want to convert the system into a robust enough one that can work under any circumstances and not a rover that sometimes works well.
This document will be significantly different from all the confluence space documents. The goal is to provide a practical guide for any member going to test the system and provide a handbook of research on what action they should take to make the system ready
The document will provide the following part:
Objective
The system involved(graphics and description)
Steps to set up the system
Potential backup solution
This document is intended to help people understand how to test the system. It will describe detailed step-by-step guidance for the system. The main goal for people testing the system is to debug any unforeseen circumstances if something goes wrong.
Milestone 1:
Skeleton board with two sparks max controller motor turning as expected.
Ver 1: sensorless control
Ver 2: close loop control
Involved subteam:
Mechanical:
Current progress:
The mechanical solution for the spark max requires a minimum change
Reason:
Spark Max is a product similar to Odrive, so the drivetrain's motor and gearbox mount need not be changed. The only thing that needs to be done is to mount Spark Max into the EBOX.
Follow-up steps:
There is no immediate follow-up. We will wait until the spark max arrives at the bay and is tested with all six motors.
The mechanical solution for spark flex requires a decent amount of change to the current drivetrain system.
Reasons:
The Spark Flex generates less torque than the Spark Max and uses a proprietary motor. The advantage of it is that we already have four of them. So, this can be a robust backup solution if Spark Max with the odrive motor combination does not meet our expectations or the newer 4 Spark Max controller does not arrive on time.
Immediate action:
Start assembling the mechanical solution for spark flex; let’s make the backup available even if we do not need it immediately. @Saheed Quadri @Yu-Ming He
@Yuchen Lin does not know anything about mechanical, but is it possible for us to have it available before June 6th. At that time, we can tell what solution will be the best. But if we have four assembled, we are in an excellent position to handle any unforeseen circumstances.
Electrical:
Create a harness as defined by this document.
Characterize the motor current consumption.
Read this document: https://www.ti.com/lit/ta/ssztb40/ssztb40.pdf?ts=1716471816606 and set up CAN termination if needed.
Oscope checks the signal integrity.
Create a SOP for charging and discharging the 48V battery.
Identify areas that may need overcurrent protection and solder fuse as a backup.
Firmware:
Task 1:
Look into the library(abstract 90% of the CAN wrapper job)
Reasoning:
The library is usually tested. Therefore, there will be less of a possibility of errors being experienced. https://docs.revrobotics.com/sparkmax/software-resources/spark-max-api-information
Questions to be answered:
What are the functions that we need?
What input does it take, and what is the output?
Do we need to preprocess ROS message?
Do we need to post-process CAN message?
What is the difference between the library and, for example, a library like this? https://github.com/ROS4SPACE/ros2can_bridge
Task 2:
Test the odrive motor with the spark MAX controller and characterize it
Reasoning:
Currently, our team is uncertain if the motor is working as expected. Therefore, we need to connect the SPARK MAX controller with the odrive motor and see if all six motors can generate enough torque with spark max. Spec: motor is 270 kV * 12V (norminal operating voltage) = 32400 RPM
Setup procedure:
connect the SPARK MAX to the Interface using the built-in USB
Download REV Hardware Client https://docs.revrobotics.com/sparkmax/rev-hardware-client/getting-started-with-the-rev-hardware-client#installation-instructions
Make sure the current operating mode is in Brushless mode: https://docs.revrobotics.com/sparkmax/status-led#standard-operation
Solder the bullet connector onto the SPARK MAX
First test the motor in Sensorless mode
Task 3:
Investigate the motor close loop control with the encoder
Reasoning:
Close loop control will provide more accurate control which is needed for the drivetrain
Task 4:
Integrate with software and make sure the motor on each side will turn correctly based on the joystick input command.
Software:
@Alex Szabo Need you insight in this section
General:
Order 4 48V to 12V (40A) buck converter: Valefod 36V / 48V to 12V 40A 480W Step-Down Transformer DC to DC Buck Converter DIY Power Supply $250
Order a CAN transceiver: https://www.adafruit.com/product/5708#technical-details $10
Order 5 SPARK MAX controller(if verified working): https://www.revrobotics.com/rev-11-2158/ (need express shipping) around $120 *5
Locking and keyed 4-pin JST-PH connector(PWM/CAN): https://www.revrobotics.com/JST-PH-4-pin-Sensor-Cables/
Locking and keyed 6-pin JST-PH connector(Encoder):2.0mm Pitch 6-pin Cable Matching Pair - JST PH Compatible
Deadline: June 4th
Milestone 2:
Migrate all the systems into the Ebox and verify the functionality with all six wheels and motors configured.
Deadline: June 11th
Milestone 3:
Get most members on board with the current system with proper documentation and set up a roadmap for the following term and practical solutions to convince Professor Teerestra of the capability as a team. We need to start rolling the wheel of meeting next year's SAR objective and ask Teerestra to meet every term to update us on the progress. We also need to explain to Teerestra the challenges we experienced along the way and prove that we are actively improving along the way and will not step into the same boat for next year's SAR or whatever competition we are aiming for and potentially considering the Canada university challenge. Send out an email to Professor Teerestra and ask for his availability to review the system.
We also want to present Professor Teerestra with our design idea: “We want to convert the system into a stable enough and robust one that can work under any circumstances, not a rover that sometimes works well but does not fully test features.”
Question: Is it possible to move the rover to a field, take a whole working video, or move it around E7? In the meantime it need to demonstrate all the promised features (comms show ros message posting and a working drivetrain)
Deadline: June 15th
Assignee: @Yuchen Lin
Milestone 4:
Root cause Analysis of all the challenges faced in the previous iteration and see what lesson we can learn from it.
Assignee: @Yuchen Lin