Talk:DEWBOT X Midknight Mayhem

During the mentors' matches, Douglas noticed that the drive train was not working correctly. He suspected a pivot out of calibration. Robot would not drive straight.

We checked this back in the pit and what we observed was:

1. The wheel treads on the robot's left side are completely worn. The right side treads are not nearly so worn (both were changed at the same time: at FRC Championships)
2. In crab drive, everything looks normal. Left front wheel starts driving a bit later than the rest, but angles and drive directions look okay.
3. In ocelot, we some drive angles that don't seem to make any sense.

The differential wear suggests we have wheels fighting each other as we drive, most likely due to incorrect angle. This would also explain the not driving straight complaint.

This could also tie into the low drive speed issue. We need more data.

Drive Speed Issue

Which checking drive speed with video on 14-June, we discovered that DEWBOT X's top speed was no more than 6 ft/s (avg = 5.6 ft/s; std dev = 0.5 ft/s; n = 9). It should be about 9 ft/s.

If drive-train frictional forces were causing this speed reduction, each of our CIMS would be drawing about 60 amps and the 40 amp breakers (not to mention the 100 amp main breaker) would be tripping constantly. They are not.

Action List for 2-July meeting

• Video each pivot wheel for speed determination at 120 or 240 fps (Use GoPro Black) - determine rotational speed for each wheel for each test
  • Robot on blocks - driven by on-board control at top speed
  • Robot on blocks - driven by PWM tester at top speed
  • Robot driving straight ahead top speed (joystick straight ahead w/out correction)
  • Robot driving straight ahead top speed (correcting to maintain course)
• With robot on back, simultaneously video robot bottom and Xbox controller to have linked video of control input and wheel angle output - high quality video needed here - 30 or 60 fps 1080p

Velocity testing Procedure

Wheel velocity was measured for each wheel on Prime using a GoPro Hero 3 (or Hero 3+) Black shooting WVGA at 240 fps. Wheel rims were marked to facilitate revolution count. Video frames per wheel revolution were counted to determine velocity. All four wheels were tested and are identified using cardinal directions: Left Front (LF); Right Front (RF); Left Rear (LR); and Right Rear (RR).

In stationary tests with the robot on blocks, video frames for ten revolutions were counted. By using 10 revolutions, the systematic precision of the velocity measurements was on the order of 0.05 ft/s (varying with velocity measured).

Stationary (on-blocks) measurements were taken under cRIO control with all four wheels running, and under PWM tester control, during which only the wheel being tested was driven. With the PWM tester, separate velocity measurements were made for 100% forward drive and 100% reverse drive.

Non-stationary velocity by frame count for each individual revolution. Due to the short runs, there are fewer revolutions measured per wheel at terminal velocity (4-10), but acceleration information is obtained in addition to terminal velocity.

In cRIO-controlled tests (stationary and non-stationary), two wheels (left and right) were videoed simultaneously, with front wheels and rear wheels being measured in separate runs. Two GoPros (a 3 and a 3+) were used for the simultaneous video, both controlled by a common remote.

Results of Velocity Testing

Initial tests were conducted with the robot on blocks and controlled with the cRIO. All systems operated simultaneously. The slingshot was held in tension during these tests, but the compressor was not running (because the storage air pressure was at target level). Wheels drives were run at full speed.

Average maximum wheel speed was measured at 9.64 ft/s. This is close to the original Drive-train model predictions (9.77 ft/s).

At 9.64 ft/s, the CIMS should be drawing 20.5 amps each and are operating very close to optimum efficiency.

Velocity was significantly higher (10.36 ft/s average) when wheels were driven individually with the PWM tester. While not certain (and no relevant data was collected to resolve this), it is likely that the higher velocity reflects higher battery voltage available when running only one CIM on blocks as opposed to running four CIMS (on blocks) while also powering the rest of the robot's systems (save compressor, which was off).

Reverse drive was a slightly higher than forward speed. While small, the difference is statistically significant.

Finally, the velocity was lower with the robot moving (average 8.89 ft/s). Left and right velocities are identical, as contact with the field forces consistent wheel velocities during straight travel. Front and rear velocities differ, and the lower rear wheel velocities may reflect battery discharge between these two tests (speculation). The front wheel tests were run first and the battery was not changed between tests. The compressor was off for both tests.

All of the wheel velocities measured on 2-July are reasonable in light of the original design expectations. The matter of the 14-June measured ~6 ft/s robot velocity is not satisfactorily resolved at this time.

Swerve Angle Testing

Swerve Angle Test - 2-July

We simultaneously videographed DEWBOT X's bottom and the driver's Xbox controller (Kira driving). There were synchronized (using the two soundtracks) and combined with the controller shown in the video center.

Crab and Snake drive look quite reasonable (but with occasional slow responses). Need to look more closely at Ocelot. Ocelot works very effectively, but maybe it can be made more efficient.

Speed Testing - 9-July

Speed run - 9-July

Wheel rotational speed was measured on 2-July. We returned to measuring robot velocity directly on 9-July.

Method: A drive-line was applied along the long axis of the carpet with 2" wide, blue gaffers tape. Distance markers were also applied to the carpet at right angles to the drive-line at one foot intervals, also using 2" wide blue gaffers tape. A GoPro Hero 3+ Black set to record video at 240 frames per second (WVGA) was mounted on the robot front frame looking down and forward. A number of maximum power runs were made along the drive-line, initially with the compressor running, and the with the compressor off. The elastics were tensioned, so power consumption was normal (except that it is expected that the compressor will always be running while the robot is in competition). Speed was determined by counting video frames in Adobe Premier Elements (with video slowed to 12.5% (1/8^th speed) to make the 240 fps video conform with Premier's 30 fps norm) from one distance marker to the next. The time/frame-count when the leading edge of the distance marker's gaffer tape touched the bottom of the video frame was taken as the reference time for each distance marker.

The video clip at right shows one of the speed runs (Trial A) at 1/8^th speed (converted from 240 to 30 fps).

Precision: The precision of velocity measurement is related to the frame count per 1 foot travel intervals. This was generally about 30 frames, yielding a speed of 8 ft/s. A one frame change corresponds to -0.26/+0.28 ft/s at this velocity. Precision declines with increasing speed (lower frame count).

Results: Three speed runs were suitable for measurement (it turns out to be hard to stay on the drive-line while driving): one with the compressor running (Trial A) and two with the compressor off (Trials B & C).

The data shows both acceleration and terminal velocity, as well as deceleration during maneuvering (to stay on the drive-line). Terminal velocity periods were identified as periods during which frame counts (marker-to-marker) were lowest and did not vary by more than +/- 1. All three trials showed clear terminal velocity periods under this definition.

Terminal velocity during Trial A (compressor on) was 7.8 ft/s (σ = 0.12; n = 8). During Trial B (compressor off) it was 8.0 ft/s (σ = 0.13; n = 10) and during Trial C 8.1 ft/s (σ = 0.12; n = 5). The difference between Trial B & C results are not statistically significant.

---