LCDs and New Batteries

We’ve made some significant progress in the past few weeks!

The IR protocol came together nicely. We encode each shot with a team number (1-4), damage level, and status effects (currently including slow movement, cannon disable, and stun). For the IR receive we just put the phototransistors in parallel. As we discussed in our design review, this could potentially lead to errors if two phototransistors receive a message simultaneously, but we’re going to ignore that possibility for now.

In addition to having the shots encoded, we modified the controller code so that it will display which weapon is selected and how much ammo is remaining. We adjusted it so that the ammo will only decrement if the tank actually fires a shot. The code can be accessed at https://github.com/TylerQuacken/Laser_Battle_Bots.

In looking at the different weapons, we realized a few things. For one, we’ll have to allow some time toward the end to adjust parameters to make sure the game is well balanced—we wouldn’t want one weapon being overpowered. For another, we realized that we wanted more buttons. The more capabilities we included, the more buttons we need to control them. We attempted unsuccessfully to use an R2R Ladder to multiplex the inputs, but failed because we only had momentary switches rather than SPDT switches. We ended up using a voltage divider method instead. This limits us to only being able to use one button at a time, but by splitting the buttons into categories of functions that would never need to be used simultaneously, we decided this was an acceptable option.

The last electronics change we made this week was included piezo elements on the robot and controller to allow for sounds. We’ll post more updates as we move forward with decorative lights and sounds.

Our hardware was also upgraded in the past couple weeks. We got our new batteries in, and the robot is driving faster than ever!

We also printed a new chassis. Some aspects were successful, while others weren’t quite as useful. We wanted to prevent lateral motion of the motors by including supports for the back end of it, but the tolerances weren’t quite right. We plan to fix it by just providing supports for the motor to screw into instead. We also redesigned the front of the robot to be able to more easily fit the breadboard and H-bridge. We anticipate modifying this again once we have PCBs.

We also redesigned the fit for the modular housings, which are still in the prototyping stage. The peg fits didn’t work as well as hoped, so we decided instead to use a clip-style fastener. After we determine the optimal dimensions for the clip and prove that it will work, we’ll move ahead with the first modular housing prototype.

We got a little behind in the past couple weeks, but we’re pretty much back on track with our milestones now. In the coming week, we plan to get our electronics fleshed out, then order our PCBs. From there we’ll start designing our controller and the modular housings, as detailed in our milestone schedule.