Patent ID: 12223781

DETAILED DESCRIPTION

Before turning to the figures, which illustrate the exemplary embodiments in detail, it should be understood that the present application is not limited to the details or methodology set forth in the description or illustrated in the figures. It should also be understood that the terminology is for the purpose of description only and should not be regarded as limiting.

Overview

Referring generally to the FIGURES, a refuse vehicle (e.g., a commercial vehicle, a fire fighting vehicle, etc.) can include various systems (e.g., loading systems, compaction systems, drive systems, steering systems, etc.) and an automated check system. The automated check system can include a controller that is configured to obtain sensor data from the various systems. The controller may compare the sensor data to corresponding acceptable ranges or desired values to determine if each of the systems are operating properly or if any of the systems require manual inspection. The controller can also operate a display screen (e.g., a display screen of the refuse vehicle) to display which of the systems are identified to require manual inspection.

The sensors used by the controller of the automated check system may be pre-existing sensors or may be installed specifically for the automated check system. The sensors facilitate automatic performance of morning systems checks or system checks before the refuse vehicle performs its route. The controller can check all critical systems of the refuse vehicle, including but not limited to, air pressure, fluid levels, tire pressure, coolant levels, etc. Systems that are determined to be operating normally or within required levels may be displayed on the display screen as green (e.g., in a list or in a graphical user interface).

A system that is identified by the controller as being out of specification may be displayed on the display screen as such (e.g., in a red or yellow color, with a notification, etc.). A technician may view the display screen and perform a manual inspection of systems that may be out of specification. The technician can provide a user input indicating that a final inspection has been completed or that the systems has been put into a correct state (e.g., maintenance has been performed). Upon completion of the manual check or inspection, the technician or operator may provide a user input to the controller to re-perform the automatic check to identify if the system is operating properly.

After the automated check system has performed all systems checks and any corrections are made (e.g., by a technician), the controller may generate a complete log of actions taken, systems checked, etc. The controller can provide the log to a system database for access.

Refuse Vehicle

According to the exemplary embodiment shown inFIG.1, a vehicle, shown as refuse vehicle10(e.g., a garbage truck, a waste collection truck, a sanitation truck, a refuse collection truck, a refuse collection vehicle, etc.), is configured as a side-loading refuse truck having a first lift mechanism/system (e.g., a side-loading lift assembly, etc.), shown as lift assembly100. In other embodiments, refuse vehicle10is configured as a front-loading refuse truck or a rear-loading refuse truck. In still other embodiments, the vehicle is another type of vehicle (e.g., a skid-loader, a telehandler, a plow truck, a boom lift, etc.).

As shown inFIG.1, refuse vehicle10includes a chassis, shown as frame12; a body assembly, shown as body14, coupled to frame12(e.g., at a rear end thereof, etc.); and a cab, shown as cab16, coupled to frame12(e.g., at a front end thereof, etc.). Cab16may include various components to facilitate operation of refuse vehicle10by an operator (e.g., a seat, a steering wheel, hydraulic controls, a user interface, switches, buttons, dials, etc.). As shown inFIG.1, refuse vehicle10includes a prime mover, shown as engine18, coupled to frame12at a position beneath cab16. Engine18is configured to provide power to a plurality of tractive elements, shown as wheels19, and/or to other systems of refuse vehicle10(e.g., a pneumatic system, a hydraulic system, an electric system, etc.). Engine18may be configured to utilize one or more of a variety of fuels (e.g., gasoline, diesel, bio-diesel, ethanol, natural gas, etc.), according to various exemplary embodiments. According to an alternative embodiment, engine18additionally or alternatively includes one or more electric motors coupled to frame12(e.g., a hybrid refuse vehicle, an electric refuse vehicle, etc.). The electric motors may consume electrical power from an on-board storage device (e.g., batteries, ultra-capacitors, etc.), from an on-board generator (e.g., an internal combustion engine, etc.), and/or from an external power source (e.g., overhead power lines, etc.) and provide power to the systems of refuse vehicle10.

According to an exemplary embodiment, refuse vehicle10is configured to transport refuse from various waste receptacles within a municipality to a storage and/or processing facility (e.g., a landfill, an incineration facility, a recycling facility, etc.). As shown inFIG.1, body14includes a plurality of panels, shown as panels32, a tailgate34, and a cover36. Panels32, tailgate34, and cover36define a collection chamber (e.g., hopper, etc.), shown as refuse compartment30. Loose refuse may be placed into refuse compartment30where it may thereafter be compacted. Refuse compartment30may provide temporary storage for refuse during transport to a waste disposal site and/or a recycling facility. In some embodiments, at least a portion of body14and refuse compartment30extend in front of cab16. According to the embodiment shown inFIG.1, body14and refuse compartment30are positioned behind cab16. In some embodiments, refuse compartment30includes a hopper volume and a storage volume. Refuse may be initially loaded into the hopper volume and thereafter compacted into the storage volume. According to an exemplary embodiment, the hopper volume is positioned between the storage volume and cab16(i.e., refuse is loaded into a position of refuse compartment30behind cab16and stored in a position further toward the rear of refuse compartment30). In other embodiments, the storage volume is positioned between the hopper volume and cab16(e.g., a rear-loading refuse vehicle, etc.).

As shown inFIG.1, refuse vehicle10includes first lift mechanism/system (e.g., a front-loading lift assembly, etc.), shown as lift assembly100. Lift assembly100includes a grabber assembly, a carrier assembly, etc., shown as grabber assembly42, movably coupled to a track, shown as track20, and configured to move along an entire length of track20. According to the exemplary embodiment shown inFIG.1, track20extends along substantially an entire height of body14and is configured to cause grabber assembly42to tilt near an upper height of body14. In other embodiments, track20extends along substantially an entire height of body14on a rear side of body14. Refuse vehicle10can also include a reach system or assembly coupled with a body or frame of refuse vehicle10and lift assembly100. The reach system can include telescoping members, a scissors stack, etc., or any other configuration that can extend or retract to provide additional reach of grabber assembly42for refuse collection.

Referring still toFIG.1, grabber assembly42includes a pair of grabber arms shown as grabber arms44. Grabber arms44are configured to rotate about an axis extending through a bushing. Grabber arms44are configured to releasably secure a refuse container to grabber assembly42, according to an exemplary embodiment. Grabber arms44rotate about the axis extending through the bushing to transition between an engaged state (e.g., a fully grasped configuration, a fully grasped state, a partially grasped configuration, a partially grasped state) and a disengaged state (e.g., a fully open state/configuration, a fully released state/configuration, a partially open state/configuration, a partially released state/configuration). In the engaged state, grabber arms44are rotated towards each other such that the refuse container is grasped therebetween. In the disengaged state, grabber arms44rotate outwards (as shown inFIG.3) such that the refuse container is not grasped therebetween. By transitioning between the engaged state and the disengaged state, grabber assembly42releasably couples the refuse container with grabber assembly42. Refuse vehicle10may pull up along-side the refuse container, such that the refuse container is positioned to be grasped by the grabber assembly42therebetween. Grabber assembly42may then transition into an engaged state to grasp the refuse container. After the refuse container has been securely grasped, grabber assembly42may be transported along track20with the refuse container. When grabber assembly42reaches the end of track20, grabber assembly42may tilt and empty the contents of the refuse container in refuse compartment30. The tilting is facilitated by the path of track20. When the contents of the refuse container have been emptied into refuse compartment30, grabber assembly42may descend along track20, and return the refuse container to the ground. Once the refuse container has been placed on the ground, the grabber assembly may transition into the disengaged state, releasing the refuse container.

Automated Checks System

Referring still toFIG.1, refuse vehicle10includes an automated check system200and various systems300. Automated check system200includes a controller202that is configured to communicate with various systems, sensors, apparatuses, etc., of refuse vehicle10. In some embodiments, controller202is communicably coupled with various sensors, systems, actuators, electric motors, etc., and is configured to obtain input data from the communicably coupled devices to determine if refuse vehicle10is ready for deployment along a route. In some embodiments, automated check system200is configured to perform its functionality at a start-up of refuse vehicle10or in response to receiving a request to perform its functionality to determine if refuse vehicle10is ready for deployment. Other systems require a technician to manually inspect various systems, sub-systems, etc., of refuse vehicle10to determine if refuse vehicle10is ready for deployment. Automated check system200obtains sensor data and can automatically determine if refuse vehicle10is ready for deployment or if various systems, sub-systems, etc., require manual inspection, repair, etc.

The various systems300can be or include engine systems, transmission systems, grabber apparatuses, loading systems, compaction systems, an air system, a tire pressure system, a pneumatic system, a fluid system, an electrical system, etc., or various sub-systems, sensors, actuators, devices, etc., thereof. The input or sensor data obtained from the various systems300can include air pressure, fluid levels, tire pressure, coolant levels, etc. In some embodiments, controller202is configured to compare values of the input or the sensor data obtained from the various systems300to corresponding values (e.g., specification values) or ranges of values (e.g., specification ranges) to determine if the systems300are operating properly. If controller202determines that the systems300are operating properly, controller202may determine that refuse vehicle10can be deployed on its route. If controller202determines that one or more of the systems300are not operating properly, based on the comparison between the input data and the corresponding values or ranges of values, controller202may provide a notification to an operator or technician to prompt the technician to manually inspect particular systems300.

Referring particularly toFIG.2, automated check system200is shown in greater detail, according to an exemplary embodiment. Automated check system200includes controller202, a database312, a user interface306, a personal computer device218(e.g., a tablet, a smartphone, etc.) and n number of systems300. For example, refuse vehicle10can include a first system300a, a second system300b, a third system300c, etc., and an nth system300n. It should be understood that refuse vehicle10can include any number of systems, sub-systems, etc. Each system300can include any number of sensors (e.g., temperature sensors, fluid sensors, pressure sensors, etc.), shown as sensor304, and any number of actuators (e.g., electric motors, hydraulic cylinders, pneumatic cylinders, internal combustion engines, electric linear actuators, etc.), shown as actuator302.

The sensors304are configured to provide sensor data and/or input data (e.g., their corresponding readings) to controller202. Controller202includes a processing circuit204, a processor206, and memory208. Processing circuit204can be communicably connected to a communications interface such that processing circuit204and the various components thereof can send and receive data via the communications interface. Processor206can be implemented as a general purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components.

Memory208(e.g., memory, memory unit, storage device, etc.) can include one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage, etc.) for storing data and/or computer code for completing or facilitating the various processes, layers and modules described in the present application. Memory208can be or include volatile memory or non-volatile memory. Memory208can include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present application. According to some embodiments, memory208is communicably connected to processor206via processing circuit204and includes computer code for executing (e.g., by processing circuit204and/or processor206) one or more processes described herein.

Controller202is configured to obtain the sensor or input data from systems300and identify if systems300are operating properly based on the sensor data. For example, controller202may compare the sensor data obtained from systems300to predetermined, predefined, desired, or specific values to identity if systems300are operating properly or to determine if refuse vehicle10is ready for deployment along its route. In some embodiments, controller202is configured to identify if systems300are operating properly by comparing a value of the sensor data to a desired value of the sensor data and determining if the value is within a predetermined range of the desired value. In some embodiments, controller202uses predetermined or acceptable ranges for values obtained from sensors304. If the values obtained from sensors304are outside of the acceptable ranges, controller202may determine that the system300from which the sensor data is obtained is not operating properly. Controller202can operate user interface306to notify the technician that the system300should be manually inspected. If the technician determines that the system300is operating properly, the technician can provide a user input310to controller202through user interface306to clear a checklist item for the system.

User interface306can include a display screen308and a user input310. Display screen308may be configured to provide display data as obtained from controller202to an operator, a technician, a user, etc. In some embodiments, controller202is configured to operate display screen308to notify the technician regarding which systems300require manual inspection. In some embodiments, controller202is configured to operate display screen308to provide checklist items and may provide an indication regarding which of the checklist items (e.g., corresponding systems300) require manual inspection or additional inspection. After the technician has manually inspected the systems300, the technician can provide a system clear command to the controller202to indicate that the system300has been manually inspected and that refuse vehicle10can be deployed along its route.

Controller202can be provided to generate log data regarding any of its functionality or its automated system check functionality and output the log data to database312. In some embodiments, database312is a local database that is stored in memory208of controller202. In some embodiments, database312is a remote database that is positioned remotely from controller202and controller202can provide the log data to database312. In some embodiments, controller202includes a local database312to store log data locally in memory208and also provides log data to database312to store log data remotely.

Controller202may also be configured to generate control signals for system300. For example, controller202can use a predetermined set of instructions, a control program, feedback data from sensors304, etc., or any combination thereof to generate control signals for actuators302so that actuators302operate to perform the respective functions of systems300. In some embodiments, controller202generates control signals for actuators302of refuse vehicle10in response to receiving a user input or a request to perform a requested function of systems300. For example, if one of systems300is a grabber apparatus or a lift assembly, controller202can generate control signals for electric motors, electric linear actuators, pneumatic cylinders, hydraulic cylinders, etc., in response to receiving a user request to perform such functions from user interface306(e.g., to lift and empty a refuse bin).

In some embodiments, any of the functionality of controller202or processing circuitry204can be performed on personal computer device218which is communicably coupled with controller202or the vehicle10or systems, sensors, etc., of vehicle10thereof. In some embodiments, controller202is configured to provide the display data and/or instructions to the personal computer device218. In some embodiments, personal computer device218is configured to perform any of the functionality of user interface306, or vice versa. In some embodiments, controller202(or a cloud computing system) is configured to provide instructions to the personal computer device218to instruct a technician how to perform one or more system checks. For example, the controller202can provide unique instructions to perform a specific system check, sensor check, diagnostic process, troubleshooting process, etc., to the personal computer device218for display on a display screen of the personal computer device218. The instructions can be provided to the personal computer device218in response to a request from the technician provided via the personal computer device218. In some embodiments, the instructions include a checklist, step-by-step video instructions, a demonstration video, step-by-step images, etc., to instruct the technician how to perform a specific system check that is required by any of the systems300.

Referring particularly toFIG.3, controller202is shown in greater detail, according to some embodiments. Memory208of controller includes a checklist database210, a check manager212, a verification manager216, and a log manager214. In some embodiments, checklist database210is configured to provide a system checklist to check manager212. The system checklist can include various of systems300that should be checked or verified to be operating properly. The system checklist can include items or different systems300to be checked in an order or concurrently by check manager212. In some embodiments, the system checklist includes a corresponding value or set of values for the sensors304of the various systems300. For example, the system checklist can include a desired value Adesiredor an acceptable range of values such as Aacceptable,minand Aacceptable,max.

Check manager212may obtain the system checklist from checklist database210and any of the desired value Adesired, and/or the acceptable range of values Aacceptable,minand Aacceptable,max. It should be understood that the system checklist can include a corresponding desired value Adesiredand/or acceptable range values Aacceptable,minand Aacceptable,maxfor each item or system300of the system checklist. In some embodiments, the system checklist includes a corresponding desired value Adesiredand/or acceptable range values Aacceptable,minand Aacceptable,maxfor each sensor304of each system300.

Check manager212is configured to obtain sensor data from each of sensors304of the systems300and compare the sensor data to the corresponding desired value Adesiredand/or to the corresponding acceptable range values Aacceptable,minand Aacceptable,max. For example, check manager212may obtain a sensor value Asensorfrom a corresponding sensor304and compare the sensor value Asensorto the corresponding desired value Adesiredand/or acceptable range values Aacceptable,minand Aacceptable,max. Values of the sensor value Asensorbeing substantially equal to the desired value Adesiredor within the corresponding acceptable range values Aacceptable,minand Aacceptable,maxmay indicate that the system300which the sensor304is a component of is operating properly.

For example, check manager212can compare the sensor value Asensorto the corresponding desired value Adesiredto determine if the sensor value Asensoris substantially equal to the corresponding desired value Adesired. Check manager212can obtain sensor values Asensorfrom different sensors304of each system300and determine if each of the sensor values Asensorare substantially equal to their corresponding desired value Adesired. If check manager212determines that all of the sensors304are substantially equal to their corresponding desired values Adesiredfor a particular system300(e.g., system300a), check manager212can determine that the particular system300(e.g., system300a) is operating properly and can output results regarding the determination to log manager214and/or verification manager216. If one or more of the sensor values Asensoris not substantially equal to the desired value Adesired(e.g., if the sensor value Asensordeviates from the desired value Adesiredby some amount), controller202can determine that the particular system300(e.g., system300a) is not operating properly and can output such a determination for the particular system300to log manager214and/or verification manager216as the result.

Check manager212can similarly compare the sensor value Asensorfor each of multiple sensors304to the minimum acceptable value Aacceptable,minand the maximum acceptable value Aacceptable,max. If the sensor value Asensoris between the minimum acceptable value Aacceptable,minand the maximum acceptable value Aacceptable,max, check manager212may identify that the sensor304from which the sensor value Asensoris obtained is giving an accurate or expected reading. Check manager212can compare the sensor values Asensorfrom multiple different sensors304of a particular system300(e.g., system300a) to determine if system300ais operating properly. If all of the sensor values Asensoras obtained from different sensors304of the particular system300(e.g., system300a) are within their corresponding ranges (e.g., Aacceptable,min≤Asensor≤Aacceptable,maxfor each sensor304of the particular system300), check manager212may determine that the particular system300is operating properly (e.g., system300a) and can output an indication that the particular system300is operating properly to log manager214and/or verification manager216as the result. If check manager212determines that one or more of the sensor values Asensorof the particular system300are outside of the corresponding range (e.g., Asensor>Aacceptable,maxor Asensor<Aacceptable,min), check manager212may determine that the particular system300is not operating properly or requires manual inspection and can output results to log manager214and/or verification manager216regarding the particular system300.

Check manager212can perform its functionality for each system300included on the system checklist. For example, check manager212may check the sensor values Asensorobtained from system300a, system300b, system300c, etc., of refuse vehicle10to determine if each of the systems300are operating properly. In some embodiments, check manager212is configured to output a list of results indicating which of systems300are determined (based on the sensor values Asensor) to be operating properly and which system300are determined to require manual inspection. Check manager212may output the results to verification manager216and/or log manager214.

Log manager214is configured to receive the results from check manager212and generate log data for the particular refuse vehicle10. The log data may include a list of system300that are present on refuse vehicle10, which of the systems300are determined to be operating properly, which of systems300may be operating improperly, which of system300may require manual inspection, which of systems300have been manually inspected and manually checked as operating properly, etc., in addition to corresponding sensor values (e.g., the sensor data) of each system300. For example, if the system300ais determined to require manual inspection, the log data may include the sensor value Asensorthat is determined to be outside of the corresponding acceptable range or that is determined to deviate significantly from the desired sensor value. Log manager214may provide the log data to database312for storage (e.g., locally in memory208and/or remotely). In some embodiments, the log data can be retrieved from database312by a user device314(e.g., a technician user device). User device314can be communicably coupled with database312through a network (e.g., the Internet) to facilitate retrieval of the log data from database312. In some embodiments, database312is communicably coupled with controllers202of a fleet of refuse vehicles10and can include log data from each refuse vehicle10of the fleet. In this way, a technician may track, view, or otherwise analyze fleet data by retrieving the log data from database312.

Verification manager216is configured to receive the results from check manager212and generate inspection prompts or a checklist for presentation to an operator or technician on user interface306. For example, verification manager216may generate a checklist that is a subset of the system checklist based on which of system300may require manual inspection. If check manager212determines that system300aand system300crequire manual inspection to verify that these systems are operating properly, but that system300bis operating properly, verification manager216can generate inspection prompts or a checklist that includes system300aand system300c. Verification manager216can then provide the checklist or the inspection prompts for system300aand system300cto any of display screen308, a cloud computing system316, a maintenance system318(e.g., a customer's maintenance system), or a virtual refuse truck320. The virtual refuse truck320can be included in a cloud computing system (e.g., cloud computing system316) and can be configured to perform any of the functionality of the systems and methods described in greater detail with reference to U.S. application Ser. No. 16/789,962, filed Feb. 13, 2020, the entire disclosure of which is incorporated by reference herein. Display screen308may operate to display the inspection prompts or the checklist so that a technician or operator or user is notified to manually inspect certain systems300.

Verification manager216is also configured to receive user input310indicating manual inspection results or whether a system should be cleared from the checklist as provided by display screen308. For example, after the technician manually inspects the potentially faulty systems300, the technician may provide a result of the manual inspection to verification manager216through the user interface306. The result of the manual inspection may be either an indication that the system is operating properly, or that the system requires maintenance. For example, if the checklist includes system300aand system300c, the technician may view the checklist on display screen308and then perform manual inspections of system300aand system300c. If the technician determines that system300aand system300care operating properly, the technician can provide a user input to verification manager216(e.g., via the user interface306) so that system300aand system300care marked as manually verified to be operating properly. If the technician determines that, for example, system300ais operating properly but that system300cis not operating properly, the technician can provide a user input to verification manager216via user interface306indicating that system300ashould be marked as operating properly, but that system300crequires additional maintenance. If the technician performs maintenance on system300c, the technician can provide a user input to verification manager216indicating that maintenance has been performed on system300cand that system300cis now operating properly.

In some embodiments, log manager214is also configured to receive any of the system clears, manual inspection results, or other user inputs from the technician indicating the results of the manual inspection. Log manager214can record any of the user inputs provided by the technician and include such user inputs for the corresponding system300in the log data that is generated and provided to database312. Log manager214can also provide any the log data to any of the virtual refuse truck320, the maintenance system318, or the cloud computing system316. In some embodiments, log manager214provides the log data to the database312and/or any of the virtual refuse truck320, the maintenance system318, or the cloud computing system316through a telematics system322of the vehicle10. Verification manager216can similarly be configured to provide any of the inspection prompts or the checklist(s) to the virtual refuse truck320, the maintenance system318, or the cloud computing system316via telematics system322of the vehicle10. Telematics system322can include any wireless transceiver, cellular dongle, radio transceivers, etc., for performing wireless communication. In some embodiments, log manager214and verification manager216are configured to operate in real-time so that display screen308changes a status of particular systems300or provides an indication that particular systems300have been manually checked and verified to be operating properly. For example, verification manager216may present a list of the systems300of refuse vehicle10and color-code systems300based on the results of check manager212. Systems300that are automatically determined to be operating properly may be provided on the list (e.g., as provided by display screen308) as a first color (e.g., green) while systems that are determined to require manual inspection may be provided with a second color (e.g., red or yellow). In some embodiments, verification manager216is configured to change colors of systems300on the list provided by display screen308in response to receiving the user input310that indicates the results of the manual inspection. For example, if system300cis initially determined by check manager212to require manual inspection or maintenance, display screen308can provide a notification (e.g., in a red or yellow color) for system300cto prompt the technician to manually inspect system300c. After the technician has performed maintenance on system300c(if required) or determined that system300cis operating properly, the technician may provide manual inspection results to verification manager216as a user input (e.g., via user interface306) and verification manager216may change a color of the indication of system300con display screen308(e.g., from red or yellow to green or blue).

In some embodiments, verification manager216is configured to prompt check manager212to re-perform its functionality to determine if systems300that are initially identified as faulty or requiring manual inspection or maintenance are operating properly. For example, after the technician marks potentially faulty systems300as operating properly (e.g., by providing a user input to verification manager216and/or log manager214), check manager212may re-perform its functionality by obtaining sensor data from the potentially faulty systems300and re-assessing whether or not systems300are operating properly. In some embodiments, check manager212re-performs its functionality for all systems300. In some embodiments, check manager212re-performs its functionality only for systems300that were previously identified as requiring manual inspection.

Controller202can prevent or restrict operation of systems300that are not identified by check manager212as operating properly. For example, if check manager212determines that system300ais not operating properly or requires manual inspection, controller202can prevent, restrict, or otherwise limit operation of actuator302aof system300a. In some embodiments, controller202prevents, limits, or restricts operation of potentially faulty systems300until check manager212determines that the systems300are operating properly or until receiving an override command (e.g., from a technician or operator via user interface306). Override commands may be provided to log manager214and included in the log data stored in database312. In some embodiments, check manager212re-performs its functionality to check systems300in response to receiving a request or a command from the technician (e.g., via user interface306) to re-perform its functionality and re-check systems300.

Advantageously, automated check system200facilitates automatically checking systems300of refuse vehicle10to identify which systems300require additional inspection. Automated check system200can also facilitate automatically identifying faulty systems300and notifying the technician to perform maintenance on faulty systems300. Automated check system200may use sensor data from sensors304of systems300of refuse vehicle10. Sensors304may be pre-existing sensors, or may be installed for use with controller202.

Process

Referring particularly toFIG.4, a process400for performing an automatic check or diagnostics of various systems of a refuse vehicle is shown, according to some embodiments. Process400can be performed by automated check system200. Process400can include steps402-416.

Process400includes obtaining sensor data from multiple systems of a refuse vehicle, the sensor data including various sensor values (step402), according to some embodiments. Step402may be performed by check manager212of controller202and sensors304of systems300. In some embodiments, controller202is communicably (e.g., wiredly and/or wirelessly) coupled with various sensors of the refuse vehicle to facilitate obtaining the sensor data. Each system may include multiple sensors, which each provide a sensor value.

Process400includes comparing each of the sensor values to a corresponding range or a desired value to determine if the system of the sensor values is operating properly (step404), according to some embodiments. Step404can be performed by check manager212. In some embodiments, check manager212uses a system checklist obtained from a database (e.g., checklist database210) that includes the corresponding range or a corresponding desired value for each of the sensors of the systems. Step404can include determining that a system is operating properly if the sensor values obtained from the system are within the corresponding range. If one or more of the sensor values obtained from the system are outside the corresponding range (e.g., above a maximum threshold value or below a minimum threshold value), process400can include determining that the system may be operating improperly or inoperational.

Process400includes operating a display screen to notify a technician regarding systems that require manual inspection and prompt the technician to perform manual inspection (step406), according to some embodiments. Step406can be performed by verification manager216and display screen308based on results of check manager212(e.g., based on the results of step404). Step406can include operating the display screen to provide a checklist of systems that should be manually inspected based on the results of step404.

Process400includes obtaining a user input indicating a result of the manual inspection, the user input indicating whether maintenance is performed or if the system is operating properly (step408), according to some embodiments. In some embodiments, step408is performed by log manager214and/or verification manager216.

Process400includes obtaining new sensor data from the multiple systems of the refuse vehicle, the new sensor data including new sensor values (step410), according to some embodiments. In some embodiments, the new sensor data is obtained in response to receiving a user input or a request (e.g., from a technician) to re-perform step402. In some embodiments, step410is the same as or similar to step402but is performed after receiving a user input from a technician to re-check the various systems of the refuse vehicle (e.g., after the technician has performed the maintenance).

Process400includes comparing each of the new sensor values to the corresponding range or the desired value to determine if the system is operating properly (step412), according to some embodiments. In some embodiments, step412is performed by check manager212. Step412can be the same as or similar to step404.

Process400includes generating log data including at least which of the systems are operating properly and which of the systems require manual inspection (step414), according to some embodiments. Step414can be performed by log manager214. The log data may include a list of the various systems that are checked by performing process400and can include any of the sensor data obtained during performing process400.

Process400includes storing the log data in a database for retrieval (step416), according to some embodiments. In some embodiments, step416is performed by log manager214and database312. Step416can include providing the log data to database312(e.g., a remote database or in local memory of a controller that performs process400). In some embodiments, step416includes aggregating log data across a fleet of refuse vehicles. The log data can be retrieved and used for fleet analysis.

The present disclosure contemplates methods, systems, and program products on any machine-readable media for accomplishing various operations. The embodiments of the present disclosure may be implemented using existing computer processors, or by a special purpose computer processor for an appropriate system, incorporated for this or another purpose, or by a hardwired system. Embodiments within the scope of the present disclosure include program products comprising machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a machine, the machine properly views the connection as a machine-readable medium. Thus, any such connection is properly termed a machine-readable medium. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.

As utilized herein, the terms “approximately”, “about”, “substantially”, and similar terms are intended to have a broad meaning in harmony with the common and accepted usage by those of ordinary skill in the art to which the subject matter of this disclosure pertains. It should be understood by those of skill in the art who review this disclosure that these terms are intended to allow a description of certain features described and claimed without restricting the scope of these features to the precise numerical ranges provided. Accordingly, these terms should be interpreted as indicating that insubstantial or inconsequential modifications or alterations of the subject matter described and claimed are considered to be within the scope of the invention as recited in the appended claims.

It should be noted that the terms “exemplary” and “example” as used herein to describe various embodiments is intended to indicate that such embodiments are possible examples, representations, and/or illustrations of possible embodiments (and such term is not intended to connote that such embodiments are necessarily extraordinary or superlative examples).

The terms “coupled,” “connected,” and the like, as used herein, mean the joining of two members directly or indirectly to one another. Such joining may be stationary (e.g., permanent, etc.) or moveable (e.g., removable, releasable, etc.). Such joining may be achieved with the two members or the two members and any additional intermediate members being integrally formed as a single unitary body with one another or with the two members or the two members and any additional intermediate members being attached to one another.

References herein to the positions of elements (e.g., “top,” “bottom,” “above,” “below,” “between,” etc.) are merely used to describe the orientation of various elements in the figures. It should be noted that the orientation of various elements may differ according to other exemplary embodiments, and that such variations are intended to be encompassed by the present disclosure.

Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list. Conjunctive language such as the phrase “at least one of X, Y, and Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to convey that an item, term, etc. may be either X, Y, Z, X and Y, X and Z, Y and Z, or X, Y, and Z (i.e., any combination of X, Y, and Z). Thus, such conjunctive language is not generally intended to imply that certain embodiments require at least one of X, at least one of Y, and at least one of Z to each be present, unless otherwise indicated.

It is important to note that the construction and arrangement of the systems as shown in the exemplary embodiments is illustrative only. Although only a few embodiments of the present disclosure have been described in detail, those skilled in the art who review this disclosure will readily appreciate that many modifications are possible (e.g., variations in sizes, dimensions, structures, shapes and proportions of the various elements, values of parameters, mounting arrangements, use of materials, colors, orientations, etc.) without materially departing from the novel teachings and advantages of the subject matter recited. For example, elements shown as integrally formed may be constructed of multiple parts or elements. It should be noted that the elements and/or assemblies of the components described herein may be constructed from any of a wide variety of materials that provide sufficient strength or durability, in any of a wide variety of colors, textures, and combinations. Accordingly, all such modifications are intended to be included within the scope of the present inventions. Other substitutions, modifications, changes, and omissions may be made in the design, operating conditions, and arrangement of the preferred and other exemplary embodiments without departing from scope of the present disclosure or from the spirit of the appended claim.