Customer Handoff & Final Project Documentation
Table of Contents
Final Design and Administrative DocumentationWe worked out of a shared RIT OneDrive folder and periodically uploaded to EDGE. This allowed us to collaborate live and use the full Office desktop and mobile apps. We also used Microsoft Project synced with a RIT Sharepoint task list.
- Autonomous Operation Tutorial Video
- Autonomous Operation Instructions Document
- Using RVIZ and Generating Maps Video
- Modifying a SLAM Map Video
- Additional instructional videos can be found on the Official APM YouTube Channel. Contact Abraham Long for the login info.
RepositoriesContact a Phase 4 member for getting access to these repos.
After downloading both the Arduino Software and the Arduino Repository, all libraries (i.e. throttle, steering, PID, etc.) must be copied over to the program's library location. Any time an edit is made, the files must be recopied.
- Encoder and Brake Protoshield Schematic
- APM Main Electrical Diagram
- EMS Schematic
- Stock Golf Cart Wiring
- Find all of the CAD files and drawings here.
- Golf Cart Manual
- Golf Cart Service Manual
- Customer Requirements
- Engineering Requirements
- Engineering Requirement Test Plans - Aside from a few test plans that dealt with areas of the cart with drastic changes, a majority of the tests passed with little issue. The two main "failures", steering mode switching and object height, dealt with systems that had changes to their functionality, and were mitigated due to those changes and other additions.
- Issue Tracking
- Risks & Constraints
- Project Schedules
- Technical Paper
Recommendations for Future Work
- Define the tasks you want to solve, and get started in planning them out ASAP. Think of all possibilities before you move forward. The first solution you think of may not be the best.
- Find a reliable way to detect curbs, this will allow the Nav-stack and the software we put in place to work without relying on localization. (Radar, Computer vision)
- Controls / Embedded
- Design a system that allows the cart to drive backward, this will require more data in the rear of the cart.
- Close the loop on the control system. The throttle was run in open loop which doesn't match the ROS conventions. Steering control loop is very responsive, this isn't necessarily a bad thing, but a maximum steering wheel velocity should probably be set in ROS
- Remove Arduino from the ROS system, I think it might be a big bottle neck ~400Hz max topic rate. Also fully port ros_lib so that higher message types can be sent from the Arduino removing the potential for error in the encoder calculation.
- Modify the SLAM algorithm to allow for starting with an existing map, allowing pose estimates and or an external particle filter (amcl?)
- Provided ROS support for Ackermann. The controller should consume either cmd_vel or cmd_ackermann preferably.
- Understand everything we did with software. From there, design a custom global and local planner. Global planner plans the full route around already defined obstacles. The local planner makes a route that the APM is capable of following while sticking to the global plan as much as possible. It also avoids collisions with any obstacles not in the global map.
- Make a better case for the IMU we threw it together so it was water proof
- Find the 0.25 inch gap in the wheel encoders that prevent them from working well consistently. There also may be some electrical issue or signal noise. The localization with the IMU, laser_scan_matcher, and the wheels works really well (when the encoders are working). The IMU + laser_scan_matcher as currently configured doesn't work well.
- Enable the use of the already assembled hall effect current sensors on the EMS boards and improve the state of charge algorithm by tracking actual Amp-hours instead of just voltage. Data sheets are available online for the Trojan 8V batteries. Refer to the documentation in the Gates Review Folder under EMS.
- The brake proximity sensor under the driver's floor board needs testing and possibly replacing. It sometimes fails to sense the pedal when releasing the parking brake.
- Abe: MSD is different than most classes. It is more flexible. It is what you make it. Using open source ROS packages is easiest to get a lot of functionality quickly but is hard to debug.
- Billy: Planning is hard. We underestimated just about everything we did. MSD 1 needs to strike a balance between learning the system and the curriculum, both are useful. Time tracking is tricky, total accuracy is the best way, but it is more difficult to maintain. Focusing on just one problem at a time and controlling testing (both test plans and prototype testing) / debugging is essential to solving a problem. Not every piece of (ROS) code is right, there are things that people do that are unreliable and don’t make sense. The simplest way is the best even if you have to sit down and write it yourself.
- Giovanni: Learning ROS has a steep learning curve. The only way you will learn it is by diving into head first. Get your hands dirt asap. Be careful when doing this though. If you try to get too in-depth with it at first, you will have a tough time understanding how everything is functioning. It is good to just accept that some things just work for reasons that you do not entirely understand at the moment. As you learn more about the system, you will be able to dive deeper into how things work. So when learning, go breath-first, not depth-first.
- Ryan: This entire project has an immense amount of different parts, all working together to ensure that everything goes smoothly. Make changes one step at a time, and test after each step. Too many changes made without testing leads to hours wasted trying to find the problem.
- Jian: Knowing that there will be unfamiliar software to be used in the project, it's better to get accustomed to them prior to the MSD II.