Vito Cassisi – Tech Blog Delving into technology

Building a robot: A worklog – Part 2

Them's fighting words!

I've been busy, and a robot has emerged from the Lego filled trays that occupy my desk. Usually I'd document the building process as I go, but I decided to build the thing bit by bit between doing uni work, thus documentation was left to last. So, I'll be analysing my first finished prototype as a whole, whilst focusing on individual design choices and implementations. Here we go!

Note: You can read the previous log here.

BOB++ v3.0 Prototype 1

The first prototype is quite different from the original BOB++ design. The servos have been placed perpendicular to the Intelligent Brick. The reason for this was to combat a couple of issues, the first being structural integrity. The original design had the servomotors adjacent and directly attached to the Intelligent Brick. Although this allowed for a low centre of mass (the Intelligent Brick is heavy with batteries installed), the mounting points were insufficient to secure the servos without them being moderately loose.

The current prototype fixes this by removing the direct connection, thus allowing a frame to be built around the brick. This frame can then facilitate the servos in addition to other sensors. A strong frame is superior to connecting everything directly to the brick since the available mounting points are often awkward to use.

Having the servos mounted as they are in the prototype was a decision to allow:

a) A frame to be built without the servos being in the way.
b) The servos to be mounted to the front of the robot to prevent an overly wide design.
c) A low centre of mass.

The position of the Intelligent Brick is improved over the original design, particularly in regards to battery access. The bottom of the brick is now completely accessible, meaning the battery door can be removed and replaced without issue. On the other hand, the LCD display and brick controls are difficult to access due to the overlying frame. This isn't much of a concern since there's a sufficient gap to navigate the firmware menus, and the screen can be read if need be. At least I don't have to rip the robot apart to charge the batteries!

You may have noticed that there's only two rubber tyres on this build. This is because I plan to bring across the spin behaviour its predecessor utilised. This involves rotating the two drive wheels in opposing directions, causing the robot to rotate on the spot. Since this spinning motion causes the back wheels to slide perpendicular to their rotation (i.e. to their side), I decided that it'd be better off to have a single low friction rear wheel. At this point in time its a solid plastic wheel, however it'll likely be replaced with a trolley wheel in a later prototype.

The ultrasonic sensor is at a higher level than before. The position of the sensor was chosen to allow for the main weapon to move freely at the front end of the robot.

This may change since there's a chance it'll overlook close opponents with a small physical profile, as seen below.

At first you may think that the solution is to aim the ultrasonic sensor on a larger angle...

This doesn't work well, though. It severely limits the scanning range of the sensor since it's always looking at its "feet". The solution is to move the ultrasonic sensor to a lower position if possible.

Last but not least, there's the lifting mechanism. This has been drastically changed to allow for a smaller profile, stronger lifting power, and reduced chance of self inflicted damage (such as failing under an opponents weight).

Perhaps the most obvious change is the length of the lifting mechanism. The previous model was quite lengthy to ensure an opponent was well positioned to be flipped or carried away. This does not come without disadvantages. A large distance between the load and fulcrum (turning point, i.e. the servo) will give the opponent a greater mechanical advantage. What does this mean? Think about when you're opening a door. Is it easer to push it from the outer edge, or near the hinges? Try it, and you'll soon realise that the further away you are from the fulcrum (or hinge), the easier it is to manipulate. This is also why you can lift something easier if you shove a large stick/plank/etc. under it and push down. The effects of mechanical advantage are found everywhere, but are usually associated with simple machines.

One equation of mechanical advantage is the following:

In this situation, the load is my robot, and the effort is the weight force of the opponent acting on the lift. Therefore, the longer the lifting device, the larger the application distance of the effort force. This increases the numerator value of the above equation, which as we know, means the MA value will also increase. Unfortunately, the 'advantage' is not ours, and if it's large enough, it will either flip the robot or damage the lifting mechanism. This is precisely why I've shortened it.

In addition, the gearing set up has changed. Previously we had a 8-tooth gear attached to the servo (acting as the drive gear), and a larger 24-tooth gear attached to that. This resulted in a gear ratio of 1:3. In layman's terms, this means for every rotation of the smaller gear, the larger one will move 1/3 of a rotation, or 120 degrees. Why do we want this? The sacrifice in speed of rotation gives us a larger torque value (which is inversely proportional to the speed). When we're trying to lift a heavy object, speed is not nearly as important as power, and torque gives us that power.

Since the servos are quite fast, I altered the gear ratio to the following in the current prototype build:

The drive gear is still a 8-tooth gear, and the gear directly proceeding it is also the same 24-tooth gear. This time I've added a 40-tooth gear to bring the gear ratio to 1:5. This is a 40% torque increase from the previous design.

What's next?
And that's it for this log! More to come soon, including design alterations, and a bit of logic programming!