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.
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.
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.
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.
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.
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
- Power management
- Payload control
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: 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
- Ultrasonic range sensors
- 3-axis gyro
- 3-axis accelerometer
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.
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 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 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).
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.
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.
2. Shown is a rear view of a 6-wheel material hauler.
Figure 2 shows the rear image of a dump unit. The most basic payload is the dump body. The chassis has a dump body, allowing it to move material from one point to another. This configuration is ideal for construction sites or large landscaping projects. Open pit mining would require a large version, which has already been developed by Volvo CE (the units are named HX01 and HX02).
3. This debris remover with hauling body is used for clean up on a construction site or farm.
Figure 3 illustrates a clean-up system for debris; the unit is a hybrid combining a dump body and a 6-axis arm. The dump is 60% the length of the Omni-chassis (it could be longer, but would overhang the rear of the Omni-chassis). The other 40% is taken up with a 6-axis arm utilizing different end-effectors. For debris cleanup, a 5- or 6-finger end-effector would be used to move material to the dump. Once the dump was full, it would trundle off to a set point to dump the load. The advantage of this payload is it can function day or night and rain or shine—it doesn’t care.
Disaster SaR (Search and Rescue)
4. The Disaster Search and Rescue Omni-chassis is a multi-armed, multi-camera robot.
Figure 4 shows an earlier version of a Disaster SaR. To date, this is the most complex payload ever designed. It covers 100% of the chassis, with 50% being additional batteries. The other 50% contains two 6-axis arms working together on moving debris. The end-effectors can be change on-the-fly by the control system from a tool rack, thus allowing for holding and cutting simultaneously. Coupled with the arms are a pair of extendable boom arms—one has a color camera and the other a forward-looking infrared (FliR) camera. The FliR allows the robot to see hot spots and evaluate the potential for human life.
The concept of an Omni-chassis, autonomous or otherwise, is to give companies, agencies, and individuals the ability to take advantage of a robot with multifunction ability at a lower cost. This single chassis can handle multiple jobs, whereas the alternative is multiple robots, each built for a specific job at a higher cost.
William Lovell, CEO of c-Link Systems Inc., currently holds a BSEE and BSME attained through the Air Force education system. He has five years in satellite guidance, control and station, and spent more than 30 years in embedded/FPGA industrial controls development, 15 years in high-speed fiber-optic controls and communications, and over 35 years in developing robotic systems. He was an early proponent and developer for Intel’s MultiBus II/MIX bus structures. Lovell also has over eight years in teaching and course creation military/civilian in electronics and robotics.