Omni-chassis: An Evolutionary Step in Robotics

Download this article in PDF format.

The term omni-robotics is very seldom used as part of our terminology speech. We have a tendency to classify our robots by manufacturer and number of axes, or more appropriately, degrees of freedom (DoF). Some of us still define a robot by the early concept—a robot is a machine that handles the three Ds: Dull, Dirty, and Dangerous.

The word omni is defined as “all.” This could lead to, perhaps, referring to all 6-axis arms as “omni-arms.” What this means is that all of the arms have the same type of motion and the same basic function: to move the end-effector from point A to B.

All 6-axis robots from Kuka, ABB, or Yaskawa Motoman have the same basic function. What makes them unique is the end-effector or payload. Generally, an entire factory doesn’t have the same robot model throughout. We then differentiate its job by the end-effector and the software to control it. This article will look more at the basic hardware than the complex software used to create a full functioning robot.

The omni-robotics term is not really used in the robotic arm industry. I began using it for a new type of robot called the “Omni-chassis.” This is a powered robotic chassis that can carry different payloads or functioning modules. The Omni-chassis covered in this article comes as a 6-wheel or track version. We usually explain this concept as akin to buying a garden tractor and adding the attachments you need for your yard/project. The attachments are normally called payloads because they mount onto the chassis.

Omni-chassis Sections

This article breaks down into explanations of the various sections of the chassis. Figure 1 is basic diagram for a 6-wheel Omni-chassis.

1. The 6-wheel Omni-chassis has individual motors for each wheel, and is surrounded by an array of sensors.

Powerplant

The power to be supplied will depend on chassis size, speed requirement, and types of power needed. For a moderate-sized chassis battery power is viable. If you need large amounts of hydraulic power, owing to the chassis size or the types of payloads to be carried, a diesel or propane engine is considered. When choosing a powerplant, one must remember to consider that it must be able to be controlled with electronics either remotely or via AI.

Drive system

The drive system, depending on physical robot size, can become complex. We chose to use an electric drive on either wheel or track.

Some disagree on having an electric drive on tracks, but we can’t be far off since Caterpillar Corp. is doing that in some of its large bulldozers. We found that speed and torque control was easier than engine/transmission throttling. The 6-wheel drive system has a motor per wheel in lieu of a single motor and gear/shaft or chain drive. The track drive electric motor becomes potentially large to generate the required torque; there’s one motor per track. A small hydraulic system that contains an electrically driven pump is also viable for the track system on medium and small chassis.

Basically, the designer of the robot system has to either take all of it into account or ensure that you communicate what is needed to the team.

Chassis design

Designing a chassis is one of the few times that a mechanical or systems engineer gets a chance to show off his or her ability. The chassis specifications that need to be laid out include the final size, capability, the chassis drive, and mounting or style of payload packages.

Once those are finalized, the engineers can move forward with the shape. Nowadays, a lot of small vehicles are being designed more aesthetically with nice rounded corners and edges. Again, the materials to be used depend on the specified function requirement. Composites and aluminum are becoming more prevalent because of the reduced weight. High-end steel alloys are still used in many cases.

Some material choices are based on the company’s production ability. If you’re not prepared to add new equipment and training, then you stay with what can be worked with. The only other option is to subcontract the work, which presents a new batch of issues.

Electronics

Amongst all of the design work involved, the electronics is the most complex. Yes, you can use your COTS parts if it will suit your needs; utilizing a programmable logic controller (PLC) isn’t really recommended due to the inherent latency of the unit’s scan time. First off, the type of robot chassis needs to be decided on: remote control wire, remote control radio/Wi-Fi, remote control with built in job program, or our favorite, autonomous. Autonomous electronics are used for the purposes of this article, because the other configuration types are inherently built-in, creating a complex system.

The control-systems engineer needs basic specs on everything that must be controlled and/or monitored. The system is broken down into the following groups:

• Main processor
• Guidance/navigation
• Motion
• Power management
• Safety
• Communications
• Payload control

Main processor

This would be the master or only processor. Again, depending on the overall needs, this could be a large-scale CPU or MCU. In some cases, a distributive processor system will better fit overall control. For those that don’t understand, a distributive system has processors that handle specific jobs, i.e. motor control, guidance/navigation, power management, and so forth. All of the sub-processors report to the master.

Guidance/navigation

Guidance: The directing of the motion or position of something. The term is usually used in reference to a missile.

Navigation: The process or activity of accurately ascertaining one's position and planning and following a route.

For autonomous vehicles, a combination of both is typically used. The navigation process can have many components. The following combination is currently in use:

• Dual GPS receivers
• Wheel/track RPM/position indicators
• LiDAR
• Radar
• Ultrasonic range sensors
• 3-axis gyro
• 3-axis accelerometer
• Cameras

The data from all of these components is combined to give, in this case, a position accuracy of ±1 cm. The guidance section takes the position information and compares it to the last navigation set and adjusts the drive motors accordingly. Basic navigation is a math-intensive action, hence the need for a dedicated processor. The data field or point cloud generated by either the LiDAR or radar also requires a dedicated processor. This whole guidance/navigation system requires a minimum of two and preferably three processors. It’s a complex undertaking, and as such, isn’t covered in this article.

Motion

This basically constitutes control of the drive motors. I’ve found that an MCU per motor is the most effective. This allows for control and monitoring of a motor up close, and reduces MCU cost. There are MCUs designed for the specific purpose of motor control. Mounting the controller on or next to the motor reduces line loss or electrical noise interference.

Some of what’s monitored includes motor RPM, motor current, motor temperature, and motor voltage. Thus, the master processor or guidance processor communicates the chassis speed to the motor MCUs, which allows each motor to self-adjust the actual motor drive. The information gathered maintains the motor’s health and overall performance of the chassis. For example, an MCU sees a large drop in motor current with constant RPM, which means the wheel is slipping. Another example is the track drive sprocket has constant RPM with a drop in motor current, which means a track break.

Power management

Power management is primarily used on the battery system, with a minor application for fuel-powered engines.

For battery systems, you’re looking at the current draw per battery bank. By utilizing relays, you can isolate a bank that appears to be drained or having issues. It would also handle the recharge of each bank of batteries. Furthermore, it will notify the master of length of time left so that the master can notify a human for service. For fuel engines, it would maintain constant output RPM and monitor fuel consumption, once again notifying for service when needed.

Safety

Safety is forgotten in a lot of cases. It involves protecting the robot from humans and other dangers. For an autonomous chassis, I found that a ring of short-range ultrasonic sensors worked well. They notified the master processor of the approach of humans, and in turn suspended payload and chassis motion.

Another set of sensors are called end-of-world units. These look down at an angle so as to prevent the chassis from falling into a hole or going off a cliff. Also included are flashing lights, data extraction from the cameras, and kill switches (both physically on the robot and via RF).

Communications

Basically, communications is the ability to move data between two points. While a fully autonomous robot doesn’t need human interaction, monitoring the system for issues is still important. Communications is accomplished with one of several different methods: copper cable (tethered), fiber-optic cable, RF, or Wi-Fi.

Wi-Fi is the preferred method among educational institutes, due to high availability and low cost. Field industry leans more toward RF having better range and security. The communications link can be used to monitor the health and status of the chassis/payload, see what the cameras are seeing, and even command change in action. With added security, the software could be updated on-the-fly.

Payload control

The payload control can be implemented in a number of ways. For some, putting the controls on the payload is the easiest. This would require a single data cable to communicate with the master processor, and a power cable.

I developed a different approach—I use a reconfigurable FPGA that knows what payload is attached, and then configures itself accordingly. Because the FPGA has a built-in processor, it also knows what software to load for all of the controls. This approach saves rebuild or redesign of circuit cards that are mounted on the payload. There’s also less chance of control electronics being damaged while the payload is functioning.

Usage Examples—Chassis with Payload

All of the following examples are designed to fit the same Omni-chassis.

Dump body