>>>Pi Wars 2020<<<
1OrangeBot Disaster: Steering
Following the MVP design strategy, a minimal version of the planned platform layout was built to evaluate performance and feasibility.OrangeBot was designed to deploy four independently controlled fixed DC motors with encoders to achieve a good mix of speed, torque and control. In this layout, steering is achieved by having the right side motors advance at a different speed from the left side motors.
Illustration 1: OrangeBot Platform Layout
The following elements of the vertical slice were tested
successfully:- Electronics
- Motors
- Encoders
- Forward/backward motion
- Remote control using Maze Runner remote control software
stack
OrangeBot could not turn at all.
1.1Problem
OrangeBot uses the layout of our beefiest robot, OBY, in which the platform is meant to steer like a tank. During OrangeBot design, a tool was built to compute performance, allowing choice of the correct motorsOne problem, that became obvious after this disaster revealed itself, was that the tool did not (and still doesn't) account for torque that emerges when motors are not moving along the axis of motion of the platform.
Illustration 2: Out-of-Axis Steering Torque
The OBY platform was capable of producing 133.3 [Kgf] of push,
meaning the steering torque is inconsequential to OBY's operations.
By contrast, OrangeBot motors were restricted in size by the Pi Wars
rules while optimized aggressively for speed. Furthermore, a supplier
shortage meant that a faster weaker motor was chosen instead of the
design target.Compounding the problem were the high grip wheels of the platform, designed to improve precision, clearance and control. In forward motion, rolling friction is weak, but during a drag turn the sideway slide friction must instead be fought. The high grip wheels proved true to their name.
The end result was that OrangeBot was simply unable to turn, even with 100% differential power applied to all four wheels, the motors simply stalled and the platform stood like a dead stone.
2Search for a Solution
The problem was identified early enough in the project that even a full redesign would be doable within the time constraint of the Pi-Wars.Solutions considered:
- Overvolt: Overvolting the engines to 24V or
even 28V would allow for double the stall torque. It would have
(barely) solved the problem while causing overload stresses on the
reducer and causing a significant loss of precision as the platform
brute forces sharp turns.
- Lower Friction: By reducing the friction of the
wheels, the torque to fight against lowers, and turn become easier.
This solution causes loss of precision and loss of clearance.
- Smaller Wheels: By reducing diameter, torque is
increased. This causes a loss in clearance.
- Layout Change: By moving the pivot in between
torque wheel, force becomes always parallel to the wheel themselves,
solving the problem at the source. This can be achieved in several
ways.
- Replace Motors: Replacing motors with a
stronger slower variant solves the problem at the source, at the
cost of significant delivery times, redesign, rework the wheel hubs
and motor brackets and economic cost.
2.1Lower Friction
Applying black tape on the wheels was enough to lower the friction of the wheels themselves.
Video 1: Black Tape Steering
While the solution was workable in the strictest sense of the
word, it was clear that the result was not Pi-Wars worthy. Given the
time available it was decided to search for a better solution.The only solution that was not an hack and allowed to reuse the motors, was to change the layout of the platform.
3Possible Layouts
A new search for layout was conducted with an additional constraint. The wheels must always face the direction of motion projected from the pivot.Now, the pivot position moves according to the steering radious of the platform. At least some of the wheels must rotate to be parallel to the motion relative to the wheel itself resulting in three possibilities.
- Traction wheel(s) with active rotation (servo)
- Trailing wheel(s) with active rotation (servo)
- Trailing wheel with trailing rotation (roller)
Illustration 3: Possible Layouts with Rotating Wheel(s)
Removing one of the traction axis moves the pivot in between the traction wheels, allowing them to be fixed in all turn configurations and removing half the complexity. Unfortunately, half was not enough.
With the second axis reduced to a single trailing wheel mounted on a trailing vertical axis, all the complexity is removed. This also removes the need for core joint to ensure all four wheels touch the ground.
SOLUTION: Two fixed traction wheel with one trailing rotating wheel.
4Layout Change
Solution was validated by testing a small rolling wheel.
Illustration 4: Layout validation
What followed was a design phase with fitting of components to
find out how to best design the rolling wheel. Diameter was maximized
as a bigger wheel would have allowed to reduce the clearance loss
penalty. Such rolling wheels are common, and can be found on local
hardware store.
Illustration 5: Final Layout
The final choice landed on a 60mm rolling wheel with a v-shaped
flat track.5Conclusions
A misstep during the first design phase of OrangeBot, caused the turn torque to be overlooked. This, combined with other factor, caused for motors too weak for the job to be chosen for the platform.Thanks to the MVP design strategy, the mistake was caught early on, allowing for a wide array of solution.
Final solution was to reduce the scope of the platform, replacing two traction wheels with one trailing rolling wheel.
This solution maintain precision, and lowers weight, at the cost of a slightly reduced top speed and halved pushing power of the platform.
No comments:
Post a Comment