Menu

Team 8 - Super Robot Builder Squad!


While exploring the hallways on campus, I discovered a flyer for MIT’s premier IAP robotics showdown. It was then my life was transformed as five strangers joined forces to become a squad. Our quest: To design an autonomous robot from top to bottom to defeat the evils of mismatched colors spread across the floor.

Super Robot Builders Squad MASLAB Team 8!

Team members:

  • Eric Boehlke
  • Mario Contretras
  • Charlotte Tingxiao Sun
  • Mina Mengyuan Sun
  • Yang (Gilbert) Yan

Journal

2018/01/29 1106 GMT-0600

    Yang: Obviously we've not been writing our journals as diligently as originally promised. I can't say our robot is coming along much better, but we've made some pretty amazing progress considering my own personal inexperience. The most interesting thing for me has been the disabling of components, namely two (now burned-out) fuses on the first day, a (probably shorted) teensy on the third, a (overly discharged) lipo battery by the first day of the second week, a (inoperable video driver) NUC by the third day of the second week, and another discharged lipo soon after. Today is the first day of the fourth and final week: we have a mock competition tomorrow, and the final competition on Thursday. Our final bot is hopefully being assembled as I write; it is smaller than one version we designed earlier, which should help it move around the field and balls easier. Eric is working on some code for path-finding, and Mario should be working on integrating encoders such that our positioning is more accurate. Charlotte is assembling the robot, and I'm working on the interface between Eric's code and the code to move the robot. We're using ROS, by the way, which there has been a series of debates about. Mengyuan has been pretty busy with her internship lately it seems and I don't know if she'll be able to help out more with the project.

    We've definitely had our share of mistakes and setbacks coming to this point, and looking back there were many things that we could have done better. Unfortunately my ME and EE experience is lacking, but I'll definitely try to help out next time. We'll want hardware to be one interation ahead of software at all times to maximize workflow. RIght now, the assembly of the robot is delaying testing of the code. I think our team also lacked a strong leadership. I would wish someone with more experience could take charge, but I've tried my best to make some assertive calls even though my experience is lacking, because it's worse to not make any calls at all. Thankfully, Eric pushes his ideas sometimes. Each of our committment levels are also a little lacking, but I think that's understandable. After all, MASLAB isn't life.

    To be honest, part of me is writing this out of wanting to try out the new .gitattributes file I've added to our repo to not mess with line endings anymore between CRLF/LF. So I'll end it here and commit and see what happens I guess. Some of the stuff I learned about Ubuntu, NUC, Teensy, SFTP/SSH/Git are pretty interesting, and I feel a little urge to start a project of my own. Maybe I'll learn some Ubuntu API...

2018/01/31 1106 GMT-0600

Mario: Okay, it's time for a journal update. A large one at that. We (being myself and Charlotte) haven't written much about the mechanical design of the robot but the idea is rather basic. We have an intake driven by a continous rotation motor that takes in balls and shoots them up a ramp. Once the balls get over this initial ramp, they follow a path of downward sloping ramps. Gravity pulls the balls down through our robot and they fall into a mechanical storage unit we're calling the "hopper". The hopper has a mounted servo in the front that uses a 3D-printed linkage prevents the balls from escaping their home. Once the robot is properly positioned in front of a goal our plan is to send a command to the servo through the Teensy to move the linkage and allow the balls to roll through.

Eric and I tested our initial design and decided that we needed to make our robot smaller to be able to navigate the field with less wall interference. Charlotte adjusted our CAD to make our robot smaller and to integrate the electronics better while I got to work on making our motors base their rotations on encoders rather than time and speed signals.

In our github (https://github.mit.edu/MASLAB-2018/team-8/tree/master/catkin_ws/src/superteam8w00/src), in teensy_node2.py we have written our first iteration of using our encoders to make driving more accurate. The turn2 and drive2 functions are just some debugging functions we wrote; the actual functions we used were drive and turn. The drive function works by taking in a parameter called distance which is a measure of how far the robot should move in inches. The function converts this distance into a number of ticks that we aim to travel. This new tick goal is the value that both the right and left encoders aim to reach. The idea is that while either encoder is below the tick goal, we continue to drive the motors at self.FORWARDSPEED. If one encoder is going faster than the other, we lower it by some amount self.VARIATION. This type of controller is known as a bang-bang controller because it is a controller that "uses feedback to switch abruptly between two states" (Courtesy of wikipedia: https://en.wikipedia.org/wiki/Bang%E2%80%93bang_control). Whether we "bang" the left speed or right speed depends on which encoder is counting faster. We added a time delay in time.sleep because we believed that the code was running too fast for the Teensy to execute commands.

The turn function works in a similar fashion. First, we did some kinematics to figure out how the robot rotates in plane (its orientation in plane will be given by ϴ) as a function of its wheel rotations (ϕ).

After some math, we determined that the amount of ticks the encoders needed to read (ϕ_ticks) is equal to the distance from the wheel to the center of rotation, a, divided by the wheel radius, r, multiplied by how much we want to rotate in plane, ϴ, and multiplied by k, a constant that converts from radians to ticks. In short, ϕ_ticks = (aϴk)/r. Once we calculate the ϕ_ticks , we set the tick goal for each encoder individually, since rotation involes one encoder counting positively and one counting negatively (Which one does which is dependent on whether you want to make a clock-wise or counter clock-wise turn). Our code defines theta as positive counter clock-wise with our wire configuration. We use the same "bang-bang" control as the drive function except that in the turn function we look at the absolute value of the encoders since they will be either positive or negative.

This code was pretty good, allowing us to drive relatively straight and our turns were off by only about ~5 degrees. Despite that there was still room for improvement: we did not perform center of mass calculations for our robot so abruptly going from self.FORWARDSPEED to 0 speed as we ended our move command caused our robot to tip forward and rotate slightly. In addition, the stackup error of the ~5 degrees on the turn function allowed us to drive relatively accurately but not as accurately as we hoped to drive.

We then iterated in teensy_node3.py to change our drive function's to include both a "bang-bang" controller and a proportional controller. We change our value, forward_speed, as we get clsoer to our tick goal. We take the minimum of a preset self.FORWARDSPEED and of k_drive multiplied by avg_err plus dead_band, which are a controller constant, the average error the encoders have in relation to the tick goal, and an estimate of the motor dead band. The logic behind this control scheme for the forward_speed is because at the beginning of any drive command, our average encoder error will be huge in relation to the tick goal because we clear our encoders and set their values to 0. This would blow up the value k_variation x avg_err + dead_band and could saturate our Teensy. In addition to this, if we proportionally slowed down throughout our entire travel time to our tick goal, our response to the move command would be unnecessarily slow. Taking the minimum of these two values makes a lot of sense because we can continue through most of our move command at a constat speed, self.FORWARDSPEED, and only slow down using our proportional controller toward the end of our goal. After a bit of trial and error, we found an optimal k_drive constant! We still look at the error between encoders (i.e. is left or right driving faster than the other). We use a simple "bang-bang" controller to subtract an amount self.VARIATION from our variable forward_speed. We considered making self.VARIATION a variable parameter based on a proportional controller but we decided against it because it would involve more constant tuning and coding. In the end, using this mix of proportional control to regulate our forward_speed to the tick goal and using a "bang-bang" controller to adjust speeds between wheels allowed our robot to slow down smoothly to a stop and allowed us to drive straight to about within 0.33 degrees (This number was based off the encoder error; we have no way to tell what the actual misalingment is without metrology due to wheel slipping).

Our next goal is to edit the turn function in teensy_node3.py to be more accurate. We are considering whether we want to use a gyro to assist the encoders in calculating the plane angle ϴ but we might just run a lot of tests and take the average error of ϴ and hard code that error in because we only have one day left before the competition and integrating a new sensor into an already existing CAD and code base is somewhat tedious.

We'll be back with another update soon (hopefully). Cheers!

2018/02/01 0242 GMT-0600
Yang/Gilbert

I have around five hours to make our robot a bit better. Tonight I have exclusive access to everything I need except extra supplies and the actual court to test our robot on. This is a pretty big handicap, but I'll try to work with it. I think I'll try to do hardware things as much as possible. There are many things we need to do, but the competition is quite close, so I will need to prioritize. While a code refactor would be nice for future workflows, I doubt we'll get to that point, so I'll prioritize making things work. The reduced workflow is difficult, but with SFTP, SSH, and VNC setup already, it'll be a lot easier than before to test things out, espcially with local access. I'll try to document my progress as well, but that update will come later.

Pray to the miracle workers...