Abstract: Example implementations described herein involve systems and methods for operation of a robot configured to work on a first process and a second process, which can involve receiving sensor data indicative of a status of one or more of the first process and the second process; for the status indicative of the first process waiting on the robot, controlling the robot to work on the first process; and for the status indicative of the first process not waiting on the robot, controlling the robot to conduct one or more of work on the second process or return to standby.

Abstract: Example implementations described herein involve systems and methods for operation of a robot configured to work on a first process and a second process, which can involve receiving sensor data indicative of a status of one or more of the first process and the second process; for the status indicative of the first process waiting on the robot, controlling the robot to work on the first process; and for the status indicative of the first process not waiting on the robot, controlling the robot to conduct one or more of work on the second process or return to standby.

Abstract: Example implementations described herein are directed to a simulation environment for a real world system involving one or more robots and one or more sensors. Scenarios are loaded into a simulation environment having one or more virtual robots corresponding to the one or more robots, and one or more virtual sensors corresponding to the one or more virtual system to train a control strategy model from reinforcement learning, which is subsequently deployed to the real world environment. In cases of failure of the real world environment, the failures are provided to the simulation environment to generate an updated control strategy model for the real world environment.

Abstract: Example implementations described herein are directed to systems and methods that include the storage of I/F communication activity during a co-execution and a repeater to reproduce such I/F communication activity. Thus in a subsequent re-execution of the simulation or applications, one or more of the simulations or applications utilized can be replaced with a repeater without requiring the full execution of the simulation or application, thereby saving license usage as well as requiring fewer hardware resources for execution.

Abstract: Example implementation described herein are directed to systems and methods for management of a factory, which can include intaking and storing streaming sensor data from a plurality of edge nodes of the factory in a database server, the database server managing historical data of the plurality of edge nodes of the factory; executing, at an edge server, a first machine learning process on the streaming sensor data from the plurality of edge nodes to determine short term analytics; controlling, at the edge server, the plurality of edge nodes according to the determined short term analytics; executing, at a cloud server, a second machine learning process on the streaming sensor data stored in the database server and the short term analytics to determine long term analytics; and instructing the edge server to control the plurality of edge nodes according to the determined long term analytics.

Abstract: The disclosure provides an aseptic sowing and raising seedling method for distant hybridization seeds of Phalaenopsis and Rhynchostylis retusa, which takes Phalaenopsis as female parent and Rhynchostylis retusa as male parent to obtain hybridization fruit pods by artificial pollination, the fruit pods are pretreated, and the seeds are aseptically sowed, germinated, protocorm proliferated and differentiated, strong seedlings rooted, acclimatized and transplanted to obtain distant hybridization offspring groups. The disclosure has the advantages of high seed germination rate, large seedling number, short seedling time and good seedling quality, which solves the problems that the seeds of Phalaenopsis distant hybridization process are difficult to succeed due to affinity, and are extremely difficult to germinate and raise seedlings under natural conditions.

Abstract: Example implementations described herein are directed to a simulation environment for a real world system involving one or more robots and one or more sensors. Scenarios are loaded into a simulation environment having one or more virtual robots corresponding to the one or more robots, and one or more virtual sensors corresponding to the one or more virtual system to train a control strategy model from reinforcement learning, which is subsequently deployed to the real world environment. In cases of failure of the real world environment, the failures are provided to the simulation environment to generate an updated control strategy model for the real world environment.

Abstract: Example implementations described herein facilitate an interactive environment for companies and personals to validate and develop autonomous driving systems. Such implementations apply to, but are not limited to, applications such as sensor data collection for deep learning model training; validation and development of various detection algorithms; sensor fusion (e.g., radar, lidar, camera) algorithm development and validation, trajectory/motion planning algorithm validation; and control algorithm validation.

Abstract: In some examples, a system may receive a plurality of parameters for a filter design, including a noise parameter. The system may determine a plurality of candidate filter configurations based on at least one of the received parameters. The system may further determine, for each candidate filter configuration of the plurality of candidate filter configurations, based on a trained machine learning model, an estimated electromagnetic interference (EMI) noise associated with each candidate filter configuration. The system may select at least one of the candidate filter configurations based on the estimated EMI noise. In some cases, the system may perform a simulation using the selected candidate filter configuration. Based on the results of the selecting and/or the simulation, the system may send information related to the at least one selected candidate filter configuration to a computing device.

Abstract: Example implementations described herein are directed to systems and methods that include the storage of I/F communication activity during a co-execution and a repeater to reproduce such I/F communication activity. Thus in a subsequent re-execution of the simulation or applications, one or more of the simulations or applications utilized can be replaced with a repeater without requiring the full execution of the simulation or application, thereby saving license usage as well as requiring fewer hardware resources for execution.

Abstract: Example implementations described herein facilitate an interactive environment for companies and personals to validate and develop autonomous driving systems. Such implementations apply to, but are not limited to, applications such as sensor data collection for deep learning model training; validation and development of various detection algorithms; sensor fusion (e.g., radar, lidar, camera) algorithm development and validation, trajectory/motion planning algorithm validation; and control algorithm validation.

Abstract: In some examples, a system may receive a plurality of parameters for a filter design, including a noise parameter. The system may determine a plurality of candidate filter configurations based on at least one of the received parameters. The system may further determine, for each candidate filter configuration of the plurality of candidate filter configurations, based on a trained machine learning model, an estimated electromagnetic interference (EMI) noise associated with each candidate filter configuration. The system may select at least one of the candidate filter configurations based on the estimated EMI noise. In some cases, the system may perform a simulation using the selected candidate filter configuration. Based on the results of the selecting and/or the simulation, the system may send information related to the at least one selected candidate filter configuration to a computing device.

Abstract: In some examples, a system may receive, over a network from a vehicle computing device onboard a vehicle, sensor data for at least one sensed parameter of a vehicle component. The system may determine, based on the sensor data, a damage result indicative of fatigue damage to the vehicle component. Based at least partially on the damage result, the system may send a communication to at least one of the vehicle computing device onboard the vehicle, or a computing device associated with an account associated with the vehicle. In some cases, the damage result may be determined from at least one of accessing a lookup table using the sensor data, or executing a fatigue simulation using sensor data.

Abstract: In some examples, a processor on a vehicle may determine, based at least partially on information obtained from a sensor, that a fuel level of the vehicle is increasing. Further, the processor may determine that the fuel level has stabilized for a threshold time. In addition, the processor may determine an amount of fuel added to the vehicle, and may send, over a wireless network to a computing device, a communication indicating the amount of fuel added. In some cases, the computing device may compare the amount of fuel indicated in the communication from the processor with an amount of fuel indicated in information received from a point-of-sale device for determining a difference.

Abstract: The driver's driving behavior will be recorded and a signature will be created either on vehicle or on a cloud data center. The driver signature can be accessed using secure authentication by any vehicle he will be driving. The data collection is a continuous process monitoring driving behavior of the driver. The guidelines from OEM are used to compare driver signature with ideal driving characteristics. Changes are pushed to the vehicle controller to modify controls of individual automotive components to adjust the efficiency of vehicle and improve the ride comfort for the driver. The changes to be made can be decided on a remote cloud system or on the vehicle.

Abstract: Apparatus for providing real-time data to a hardware-in-the-loop simulator for an automotive vehicle. The apparatus includes a test vehicle having at least one sensor which generates an output signal representative of a condition of the vehicle. A wireless transmitter such as a cellular phone on the motor vehicle receives the sensor output signal as an input signal and transmits that output signal to a computer network. A simulator data server receives the data from the computer network and provides that data to the hardware-in-the-loop simulator.

Abstract: The driver's driving behavior will be recorded and a signature will be created either on vehicle or on a cloud data center. The driver signature can be accessed using secure authentication by any vehicle he will be driving. The data collection is a continuous process monitoring driving behavior of the driver. The guidelines from OEM are used to compare driver signature with ideal driving characteristics. Changes are pushed to the vehicle controller to modify controls of individual automotive components to adjust the efficiency of vehicle and improve the ride comfort for the driver. The changes to be made can be decided on a remote cloud system or on the vehicle.

Abstract: In some examples, a system may receive, over a network from a vehicle computing device onboard a vehicle, sensor data for at least one sensed parameter of a vehicle component. The system may determine, based on the sensor data, a damage result indicative of fatigue damage to the vehicle component. Based at least partially on the damage result, the system may send a communication to at least one of the vehicle computing device onboard the vehicle, or a computing device associated with an account associated with the vehicle. In some cases, the damage result may be determined from at least one of accessing a lookup table using the sensor data, or executing a fatigue simulation using sensor data.

Abstract: In some examples, one or more computing devices on a network may receive, from a client computing device, one or more inputs for configuring a simulation, the simulation including at least a first simulator and a second simulator. The one or more computing devices may allocate computing resources including at least a first virtual machine for executing at least one of the first simulator or the second simulator. The one or more computing devices may configure a first simulation controller executable on the first virtual machine for controlling execution of the at least one of the first simulator or the second simulator. The first simulation controller may initiate execution of at least one of the first simulator or the second simulator as part of execution of the co-simulation. In some examples, a result of the co-simulation may be sent to the client computing device.

Abstract: In some examples, a processor on a vehicle may determine, based at least partially on information obtained from a sensor, that a fuel level of the vehicle is increasing. Further, the processor may determine that the fuel level has stabilized for a threshold time. In addition, the processor may determine an amount of fuel added to the vehicle, and may send, over a wireless network to a computing device, a communication indicating the amount of fuel added. In some cases, the computing device may compare the amount of fuel indicated in the communication from the processor with an amount of fuel indicated in information received from a point-of-sale device for determining a difference.