Day 7 (1/12/2018)

Introduction

The team is still working on the various prototypes in the room. The entire team needs to help with making the prototypes so if you are available during build time please stop in and help for a bit. By next Tuesday all prototypes have to done and ready to present. At Tuesday’s meeting we will vote on the best prototypes. The other deadlines will be available on the team calendar. Also on Wednesdays the build time will be changed to be from 6 pm – 9 pm. Additionally, The drill press stand should be done in the upcoming couple of days.

Some more miscellaneous news

  • Dr. Steve Jons has suggested using the ceiling and a vision processing system to figure out the absolute position of the robot.
  • The elevator carriage is in progress.

 

Active Intake

The team did a little bit of work on the active intake today. The pivots were brought in a little bit to make sure the active will fit in the frame. There was also progress made on the CAD. Tomorrow it would be nice if the active could be tested. There was also a discussion of where the motor for the wheels should be. The team was thinking that there would be a shaft in the pivot that would have belt connected to both wheels and the motor which will be attached to that bar.

 

Programming

Today programmers worked more on Pure Pursuit. It is starting to get smoother and smoother, and it can be seen that the robot can now rotate and move. However, it is still deviating far enough from the waypoint-based trajectory that it is forced to stop. This is because it cannot find any goal points within the given look ahead distance. Oddly, when the robot is supposed to go straight it initially rotates. This might be due to a number of reasons, but most probably it could be because of:

  1. Inversion somewhere in motor-related code (something should be multiplied by -1). This would cause the robot to rotate when it should go straight
  2. The robot thinking it is not where it really is.
    1. Tomorrow we will test the estimation of absolute robot location in teleop to provide insight to this issue

We also crushed some other issues today as well. Both a mag and quadrature encoder were on the robot which would have led to problems since they have different resolutions. However, this really was a problem because the quadrature encoder was not connected to the robot at all (chain + cable = not happy cable). This caused the location estimation function that used left and right encoder values to give wrong data.

A side note: trajectories can get more complicated (and fun) when more minute details are considered. There is a paper that has been briefly looked over and will most likely serve as a foundation for upcoming trajectory improvements.

Something cool…

Coming soon