Post BattleCry things To-Do

[Louis L]

Stuff carried over from the previous list (post-NE-CMP things to-do) plus others.

Near term:

• What's wrong with the top intake motor? Is there also something wrong with the lower intake motor? [done, see follow-on to thread]
• C++ - what's wrong with the intake arm motor? [6/9, it's magically working fine now]
• Take robot portrait. One use of the picture is for our annual gift to our sponsors. [done]
• Team party - when/where? [6/2, done; will be held at Zach's house on 6/11]
• Post videos to team youtube channel. [5/30, done]
• Post pictures to team Facebook account. [5/30, done]
• Plan - Post-season, Off-season, Pre-next-season competition in the
• Clean out our workspace at GMS and move stuff to WHS [6/17, done]
• Presentation to 8th graders at GMS [added 5/26] [6/16, done]

Further out on the calendar:

• Update kiosk. A list of team accomplishments would be a good place to start. Update the Mission Statement.
• LabVIEW - how to use test mode? [done. It requires a bit of work to be useful and is not like Java/C++]
• LabVIEW - how much time does it take to read quad encoder? Is there a fix for sampling loop with this read?  [done, changed from 10ms to 25ms loop]
• Create Student Handbook - collect ideas for inclusion
• Get carpeting used by FIRST.
• Update team web site [added 5/30]
• Release Scouting software [added 5/31]

[Vanshika C]

Also, the presentation to the eighth graders at the middle school in late June. I'll let you know the date once the admin at GMS reply to my email.

[Louis L]

Here's an update on robot testing we did today. I looked at several problems. All testing was done over a wireless network.

• Upper roller not working - Could not reproduce this no matter what we did. Shook and tugged every wire we could get to. Looked at related sensors. It worked as it should.
• The Pablo Problem - if you don't know what this means, it takes too long to explain! I was finally able to reproduce this problem so it's no longer just Pablo! Looking at the code, I can see a situation where the conditions could induce parts of what we're seeing (a race condition). But the ease with which we're seeing it makes this unlikely to be the path taken. Also it wouldn't replay the all-in-one as far as it does. So no matter what, it doesn't make sense.
• Winch limit switch issues - I do think that we have an issue with the limit switch. I update both the code and the hardware to make it better. After lots of testing, it seems to be far better. Initially I was able to make the limit switch fail very easily. The failure looked like this - the shooter would come down, trip the switch and stop its movement. But then the switch would disengage so the ball wouldn't load (note this does not explain what happens when we're using code that loads the ball without checking the switch, see #1 above). The problem here is 3-fold. First the chassis contorts when pulling down the shooter arm. When it stop moving, it contorts again. If the switch is barely tripped, the second contortion and disengage it. Second, there's a layer of tape that holds a piece of plastic in place under the arm. This plastic is there to make the switch contact patch wider. The tape was applied at an angle and not uniformly across the width of the plastic. As the chassis twists the small metal switch contact slides sideways and moves between the taped and un-taped area of the plastic. Because the tape has a finite thickness, this contributes the the switch bouncing from closed to open again. Third, we're really not using the limit switch across its intended range of motion. What we really want to do is have the arm activate it but continue past the tripping point before stopping. But we also have to be careful - if we go past the metastable point, the arm starts to come back up and that can release the switch.

Hardware - I changed the shape of the limit swith contact arm so that it trips earlier. The key to this working well is that the leaf springs back to its original shape after each use. I'm not totally convinced this is true.
Software - I changed the LabVIEW code so that when it detects the winch limit switch, it continues to pull for another 10ms. This hopefully will reduce or eliminate the chance of the switch bouncing.

[Ed B]

Any experiments of tethered vs wireless to get closer to field conditions?

[Ed B]

The limit switch we added is detecting shooter motion at the end of its travel when it is barely moving. The original (tiny) limit switch on the detent arm is in a much better place, but is subject to sideways motion from. Play in the pivot bearings. Could we redo a switch at that position maybe by adding a pin or screw to the connecting link for a switch to detect without being susceptible to sideways motion? In that position, there should also be much less motion from frame distortion.

[Louis L]

Any experiments of tethered vs wireless to get closer to field conditions?

I only ran wireless. The robot was on my workbench directly in contact with the surface.

But note that any irregularities on the surface translates to more frame contortions. This happens also with changes in tire pressure. I saw this firsthand by moving a single wheel over a workbench bench-dog hole.

[Louis L]

The limit switch we added is detecting shooter motion at the end of its travel when it is barely moving. The original (tiny) limit switch on the detent arm is in a much better place, but is subject to sideways motion from. Play in the pivot bearings. Could we redo a switch at that position maybe by adding a pin or screw to the connecting link for a switch to detect without being susceptible to sideways motion? In that position, there should also be much less motion from frame distortion.

If we're going to get into the guts of the shooter, we should also adjust the hard-stop so that it stops the arm at just the right place.

[Louis L]

Update - after a meeting on Tuesday 5/31, we decided to make the following fixes on 6/1:

• The device to lower the Cheval de Frisse was re-aligned. The metal support plate was straightened and the limit switch pushed out away from the motor to give it better clearance from a mounting bolt. This lessens the chance of the switch getting caught on the bolt and stalling the motor. Part of the motor housing was missing so it was taped over.
• The upper intake motor was a bit loose so it was removed, tightened and put back.
• The LabVIEW code was updated to use the stall current to detect when to stop the winch motor. The limit switch is only used to detect if the arm is down; it is not used to decide when to turn off the winch motor.