Graphical programming environment

Abstract

A method for using a graphical programming environment (120) to control an external hardware (102). Receiving, by the graphical programming environment (120), input data from the external hardware (10

Description

Technical Field of the Invention The present disclosure relates to a method for using a graphical programming environment. More specifically, but without limitation, the disclosure relates to a method for using a graphical programming environment to control an external hardware. Background to the Invention Traditional programming environments have limitations in creating real-time applications that require high safety integrity and scalability. Conventional approaches often lack flexibility and efficiency, leading to complex code structures and difficult software maintenance. For example, established methods for generating computer programs to control autonomous vehicles are marred by inefficiencies and limitations. Typically, these methods involve the laborious process of programming in an office or laboratory environment, followed by the task of transferring the program onto a computer-readable medium. Subsequently, the computer-readable medium must be connected to the autonomous vehicle for testing. During testing, data is collected in real-world scenarios. The data is subsequently transferred back to the office or laboratory for analysis, where problems may only become apparent after significant delay. This lack of real-time visibility into the code's relationship with the real-world environment hampers the ability to detect, isolate, and address any software issues. In turn, this lack of immediacy in detecting and addressing problems can lead to costly delays and errors in the development and deployment of the autonomous vehicle software, posing significant challenges to ensuring safety, reliability, and efficiency in autonomous transportation systems. In addition, conventional compiled code for autonomous vehicles faces disadvantages in terms of adaptability, as it is often inflexible and time-consuming to modify or update to meet the evolving vehicle requirements. This limits the rapid development and deployment required in the autonomous vehicle industry. The need for a robust, easily understandable, and scalable programming environment for real-time processing is needed. Summary of the Invention The present invention provides a method for using a graphical programming environment that addresses the above-mentioned limitations. According to a first aspect of the invention, there is provided a method for using a graphical programming environment to control an external hardware. The method may comprise receiving, by the graphical programming environment, input data from the external hardware. The method may further comprise entering the input data into one or more of a plurality of distinct modules within the graphical programming environment. Each module may comprise an executable portion of code. The method may further comprise executing, by a single interpreter in the graphical programming environment, each portion of code contained within the plurality of distinct modules to generate output data. The method may further comprise transmitting, by the graphical programming environment, the generated output data from the graphical programming environment to the external hardware. The use of a plurality of distinct modules and a single interpreter within the graphical programming environment has a synergistic effect of improving the programming scalability, computational efficiency, ease of debugging, programming flexibility as well as the software safety integrity. The single interpreter acts as a central hub that seamlessly integrates all of the distinct code modules within the graphical programming environment. As a result, developers can combine various modules effortlessly, leading to the creation of a highly scalable and easily understandable object-oriented development environment. Additionally, any data, variables and definitions are shared between the distinct code modules within the single graphical programming environment. In this manner, the developers do not need to continuously re-define or specify any data, variables and / or definitions between each individual code module. This significantly improves the programming efficiency, leading to a more rapid code development. In order to share any data, variables and / or definitions, the distinct modules do not require any data flow between each other and may be placed anywhere within the graphical programming environment. The removal of the need to transfer data between the distinct modules substantially improves the computational efficiency of the program generated within the graphical programming environment. Additionally, the implementation of a single interpreter architecture in the graphical programming environment presents a crucial advantage for developers, particularly in the realm of real-time applications. For example, using the single code interpreter in the autonomous vehicle space offers several significant advantages. Firstly, it enables real-time code modification processing, allowing developers to make on-the-fly adjustments to the vehicle's behaviour and algorithms without the need for the time-consuming recompilation. This capability is invaluable when dealing with rapidly evolving technology and dynamic environments, as it promotes quick adaptation to changing conditions. Additionally, the code interpreter simplifies the debugging process in the field, making it easier to identify and rectify issues during the testing and deployment phases. This streamlined debugging process not only saves time but also enhances safety and reliability of the autonomous vehicles. Ultimately, the use of a single code interpreter with a plurality of distinct code modules facilitates seamless code modification and debugging which may be executed and directly tested in the field, ultimately reducing development time. The use of a plurality of distinct code modules within the graphical programming environment also ensures that safety-critical software practices are strictly adhered to. Breaking down complex software into smaller, self-contained modules makes it easier to understand, test, and modify individual components without affecting the entire system. This modularity simplifies the process of identifying and fixing bugs or vulnerabilities, which is paramount in safety-critical applications where even minor errors can have catastrophic consequences. Furthermore, when using distinct modules, it's easier to perform thorough testing and validation on each component in isolation, ensuring that they meet safety standards and requirements independently before integration. If any changes are implemented to the code within an individual module, the remaining unaffected modules in the graphical programming environment do not need to be re-certified. Moreover, in safety-critical contexts, distinct modules provide a clear boundary between different functionalities, enforcing a clear separation that can prevent unintended interactions or dependencies between critical and non-critical parts of the software. This isolation minimizes the potential for cascading failures and makes it more straightforward to implement fault tolerance and redundancy strategies, further enhancing system safety and reliability. The implementation of the distinct code modules is especially important in the autonomous vehicle space, where code safety concerns are critical. The present invention offers several advantages over traditional programming software. Firstly, it simplifies the coding process by representing programming elements visually. This makes it more accessible to individuals with limited coding experience, enabling a broader range of people to participate in software development. Secondly, graphical programming environments provide real-time visual feedback, allowing developers to see the immediate effects of their code changes, which aids in faster prototyping and debugging. The plurality of distinct modules within the graphical programming environment may comprise at least a first code module and a second code module. Although only the first code module and the second code module are explicitly mentioned, the graphical programming environment may comprise any number of distinct code modules. For example, the graphical programming environment may comprise two, three, four or five code modules. The graphical programming environment may comprise more than 10, more than 20, more than 50 or more than 100 distinct code modules. Entering the input data may comprise entering the input data into the first code module. Executing the code contained within the plurality of distinct modules may comprise executing a code contained within the first code module to generate a first intermediate data output. Executing the code contained within the plurality of distinct modules may further comprise entering the first intermediate data output into the second code module. Executing the code contained within the plurality of distinct modules may further comprise executing a code contained within the second code module based on the first intermediate data output to generate the output data. In this manner a plurality of code modules may be linked together. More specifically, data output of the first code module may serve as data input in the second code module or vice versa. In some embodiments, the first intermediate data output may serve as input into a plurality of other code modules within the graphical programming environment. For example, the first intermediate data output may serve as input into the second code module and a third code module. The graphical programming environment may further comprise an event management system. The event management system may be configured to schedule the entering of the input data into one or more of the plurality of distinct modules. For example, the event management system may be configured to schedule the entering of the input data into the first code module. Additionally, or alternatively the event management system may be configured to schedule the entering of the first intermediate data output into the second code module. The event management system may be configured to schedule the entering of the input data into all of the distinct modules within the graphical programming environment. Additionally, or alternatively, the event management system may be configured to schedule the transmitting of the generated output data to the external hardware. Scheduling the entering of the input data into one or more of the plurality of distinct modules may comprise entering the input data into one or more of the plurality of distinct modules at distinct time intervals. For example, the event management system may be configured to enter the input data into one or more of the plurality of distinct modules every 1 millisecond, 1 second, 5 seconds, 10 seconds or 30 seconds. The distinct time intervals may be shorter or longer depending on the hardware requirements. Alternatively, scheduling the entering of the input data into one or more of the plurality of distinct modules may comprise entering the input data into one or more of the plurality of distinct modules continuously. For example, the event management system may be configured to enter the input data into one or more of the plurality of distinct modules as soon as the input data is received from the external hardware (i.e. the delay in scheduling the entering of the input data is 0 seconds). Scheduling the entering of the first intermediate data output into the second code module may comprise entering the first intermediate data output into the second code module at distinct time intervals. For example, the event management system may be configured to enter the first intermediate data output into the second code module every 1 millisecond, 1 second, 5 seconds, 10 seconds or 30 seconds. The distinct time intervals may be shorter or longer depending on the hardware requirements. Alternatively, scheduling the entering of the first intermediate data output into the second code module may comprise entering the first intermediate data output into the second code module continuously. For example, the event management system may be configured to enter first intermediate data output into the second code module as soon as the first intermediate data output is generated, (i.e. the delay in scheduling the entering of the first intermediate data output is 0 seconds). Scheduling the transmitting of the generated output data to the external hardware may comprise transmitting the generated output data to the external hardware at distinct time intervals. For example, the event management system may be configured to transmit the generated output data to the external hardware every 1 second, 5 seconds, 10 seconds or 30 seconds. The distinct time intervals may be shorter or longer depending on the hardware requirements. Alternatively, scheduling the transmitting of the generated output data to the external hardware may comprise transmitting the generated output data to the external hardware continuously. For example, the event management system may be configured to transmit the generated output data to the external hardware as soon as the output data is generated by the single interpreter. The event management system offers significant advantages in terms of efficiency, reliability and safety of the generated software. By scheduling the data input and output events, developers can ensure that data is fed into the code modules at precisely the right time, optimizing the software's performance. Furthermore, this approach minimizes the risk of data bottlenecks or delays, crucial in real-time or timesensitive applications such as autonomous vehicles. Additionally, scheduling the transmission of output data to external hardware allows for better synchronization with other systems or devices, improving overall system coordination and reliability. The event management system also plays a vital role in ensuring the continuous operation of the external hardware. By scheduling the input and output data flows with precision, the event management system minimizes the likelihood of the external hardware going offline. This proactive approach helps maintain the hardware’s connectivity and functionality, even in challenging conditions or when dealing with intermittent network disruptions. Consequently, the event management system enhances the hardware’s overall reliability and safety by reducing the potential for unexpected downtime. This feature is especially important in the autonomous vehicle space where safety and reliability are of paramount concern. In some embodiments, scheduling the entering of the input data may comprise receiving a first input data portion of the input data from the external device. Scheduling the entering of the input data may further comprise assigning a first timestamp to the first input data portion. Scheduling the entering of the input data may further comprise entering the first input data portion into one or more of the plurality of distinct modules during a first transmission period. The first transmission period may be determined based on the first timestamp. In some embodiments, scheduling the entering of the input data may further comprise receiving a second input data portion of the input data from the external device. Scheduling the entering of the input data may further comprise assigning a second timestamp to the second input data portion. Scheduling the entering of the input data may further comprise entering the second input data portion into one or more of the plurality of distinct modules during a second transmission period determined based on the second timestamp. The second transmission period may take place immediately after the first transmission period. In some embodiments, the first transmission period may at least partially overlap the second transmission period. In some embodiments, the first transmission period may fully overlap with the second transmission period. Alternatively, the event management system may be configured to separate the first transmission period from the second transmission period by a predetermined amount of time. The event management system may be configured to place the first input data portion and / or the second input data portion in a queue. The event management system may subsequently enter the first input data portion and / or the second input data portion into one or more of the plurality of distinct modules in chronological order based on the position of the first input data portion and / or the second input data portion in the queue. In some embodiments, scheduling the transmitting of the generated output data may comprise receiving a first output data portion of the generated output data from the one or more of the plurality of distinct modules. Scheduling the transmitting of the generated output data may further comprise assigning a third timestamp to the first output data portion. Scheduling the transmitting of the generated output data may further comprise transmitting, the first output data portion from the graphical programming environment to the external hardware during a third transmission period determined based on the third timestamp. In some embodiments, scheduling the transmitting of the generated output data may further comprise receiving a second output data portion of the generated output data from the one or more of the plurality of distinct modules. Scheduling the transmitting of the generated output data may further comprise assigning a fourth timestamp to the second output data portion. Scheduling the transmitting of the generated output data may further comprise transmitting, the second output data portion from the graphical programming environment to the external hardware during a fourth transmission period determined based on the fourth timestamp. The fourth transmission period may take place immediately after the third transmission period. In some embodiments, the third transmission period may at least partially overlap the fourth transmission period. In some embodiments, the third transmission period may fully overlap with the fourth transmission period. Alternatively, the event management system may be configured to separate the third transmission period from the fourth transmission period by a predetermined amount of time. The event management system may be configured to place the first output data portion and / or the second output data portion in a queue. The event management system may subsequently transmit the first output data portion and / or the second output data portion to the external hardware in chronological order based on the position of the first output data portion and / or the second output data portion in the queue. Although only the first output data portion and the second output data portion are explicitly mentioned, the skilled person would recognise that any number of output data portions may be transmitted from the graphical programming environment to the external hardware. Similarly, although only the first input data portion and the second input data portion are explicitly mentioned, the skilled person would recognise that any number of input data portions may be entered into one or more of the plurality of distinct modules. The external hardware may comprise a robot. The external hardware may comprise a motorized vehicle. In some embodiments, the external hardware may comprise an autonomous vehicle. In some embodiments, the external hardware may comprise a semi-autonomous vehicle. In some embodiments, the external hardware may comprise an autonomous airport dolly. The autonomous airport dolly may comprise a ground-handling equipment configured to move baggage and cargo to and from aircraft. Existing airport dollies may be retrofitted with a computer-readable medium comprising instructions that, when executed by one or more processors, cause the airport dolly comprising the one or more processors to perform any of the methods described herein. Autonomous airport dollies offer multiple advantages in modern aviation logistics. They significantly enhance efficiency by: operating around the clock, optimizing routes, and reducing manual labour requirements. Additionally, safety is improved by incorporating advanced sensors which ensure that the airport dollies avoid any encountered obstacles. The input data may comprise sensor data from the external hardware. The input data my comprise sensor data from the robot or the autonomous vehicle. The input data may comprise sensor data from the autonomous airport dolly. The input data may comprise one or more of: LiDAR sensor data, RADAR data, GPS data, visual data from one or more cameras, vehicle acceleration data, vehicle orientation data, angular velocity data, ultrasonic sensor data, vehicle steering data, vehicle breaking data, odometry data, weather sensor data, infrared sensor data, barometric pressure sensor data, ground penetrating radar (GPR) sensor data and / or microphone or sound sensor data. Advantageously, the GPR sensor data may be used by a navigation system of the vehicle if the GPS systems are unable to determine the vehicle’s position. For example, if the vehicle is going through a tunnel, where the GPS signal is lost, the navigation system may be able to use the GPR sensor data together with the last known location of the vehicle to estimate the current location of the vehicle. The output data may comprise control signals for controlling the external hardware. The output data may comprise control signals for controlling the robot or the autonomous vehicle. The output data may comprise control signals for controlling the autonomous airport dolly. The output data may comprise one or more of: steering control signals, throttle control signals, brake control signals, gear or transmission control signals, turn or indicator signals, horn signals, emergency brake signals, cruise control signals, parking or docking signals, adaptive driving mode signals and / or climate control signals. While a limited number of examples have been provided in this disclosure for the input sensor data and the output control signals in the context of autonomous vehicles, it should be understood that numerous other sensor data inputs and control signals are conceivable and would be readily recognized by a person skilled in the art. Various sensors and control mechanisms may be adapted, integrated, or substituted as necessary to meet specific design requirements, functional objectives, or evolving technological advancements. The disclosed examples are intended to be illustrative rather than exhaustive. The single interpreter may be configured to execute the code within the plurality of distinct modules concurrently. For example, the single interpreter may be configured to execute the code within the first code module and the second code module concurrently. In some embodiments, the single interpreter may be configured to execute the code within all of the distinct module located in the graphical programming environment concurrently. Advantageously, the concurrent execution of the code using inter-process communication enables the distinct code modules to run in parallel, harnessing the power of multi-core processors, which can significantly improve overall performance and reduce execution time. Additionally, any impact on the program as a whole due to code changes within a given code module can be monitored. For applications requiring real-time processing, such as autonomous vehicles or industrial automation, concurrent execution ensures rapid response to inputs and can prevent delays or bottlenecks in data processing. One or more of the plurality of distinct modules within the graphical programming environment may comprise an inspection window. The inspection window may allow a user to continuously monitor one or more code parameters as each portion of the code is executed by the single interpreter. For example, the first code module may comprise a first inspection window. The first inspection window may allow the user or developer to monitor one or more code parameters as a portion of code within the first code module is executed. Additionally or alternatively, the second code module may comprise a second inspection window. The second inspection window may allow the user or developer to monitor one or more code parameters as a portion of code within the second code module is executed. Using the one or more inspection windows within code, which allow real-time monitoring of code parameters as each portion of the code is executed by the interpreter, offers valuable benefits. It provides developers with immediate visibility into the internal state of the program, making it easier to track variables, identify issues, and verify the accuracy of computations during runtime. This real-time feedback streamlines the debugging process, reducing the time required to pinpoint and resolve errors, thus accelerating development and improving code quality. The graphical programming environment may comprise a user interface. The user interface may provide a visual representation of one or more of the plurality of distinct modules. For example, the user interface may provide a visual representation of the first module and the second module. The user interface may provide a visual representation of all of the distinct modules within the graphical programming environment. The user interface may provide a visual representation of the external hardware. For example, the user interface may provide a visual representation of the robot or the autonomous vehicle. In some embodiments, the user interface may provide a visual representation of the autonomous airport dolly. In some embodiments the user interface may provide a visual representation of each of the subsystems within the external hardware. The user interface may provide a visual representation of any flow of data between the plurality of distinct modules. For example, the user interface may provide a visual representation of the input data into the first code module and / or the first intermediate data output into the second module. The user interface may provide a visual representation of any flow of data between one or more distinct modules and the external hardware. For example, the user interface may provide a visual representation of the output data from the graphical programming environment to the external hardware. The user interface may provide a visual representation of the event management system. The user interface may provide a visual representation of any data flow in or out of the event management system. The user interface may include, but is not limited to, a graphical user interface (GUIs) presented on computer screens, mobile device displays, or other electronic devices. The user interface may also encompass a voice-activated interface, one or more touchscreens, virtual reality (VR) or augmented reality (AR) displays, a gesture recognition interface, and / or a tactile feedback interface. A graphical programming environment offers several significant advantages over conventional text-based programming environments. More specifically, the visual representation of all of the elements within the graphical programming environment provides real-time visual feedback, allowing users to see the immediate results of code changes, enhancing the debugging process and fostering a more intuitive development experience. The one or more of the plurality of distinct modules within the graphical programming environment may comprise one or more layers. Each layer may comprise a fragment of code which forms a part of the executable portion of code in each distinct module. In some embodiments, the first code module may comprise a plurality of layers. For example, the first code module may comprise two or more, three or more, five or more or ten or more layers. Additionally or alternatively, the second code module may comprise a plurality of layers. For example, the second code module may comprise two or more, three or more, five or more or ten or more layers. Upon opening the graphical programming environment, the one or more layers may remain hidden from view. However, access to these layers may be readily available through a user-initiated drop-down action, allowing users to seamlessly navigate and interact with different layers of the software environment as needed. This architecture provides a more organized and efficient way to manage and manipulate the graphical programming elements. The plurality of distinct modules may each serve a specific function or task within the software application. For example, in the context of autonomous vehicles, the first module may be dedicated to steering control, while a second module may be responsible for throttle control. Each of the plurality of distinct modules may be designed to operate independently, each handling a unique aspect of the overall system's functionality. This modular structure may allow for the efficient development, management, and customization of the software. A further aspect of the disclosure provides a method executed by an external hardware interacting with a graphical programming environment. The method may comprise sending, by the external hardware, input data to the graphical programming environment. The method may further comprise receiving, by the external hardware, a generated output data from the graphical programming environment. A single inteipreter in the graphical programming environment may be configured to execute each portion of code contained within a plurality of distinct modules within the graphical programming environment to obtain the generated output data. The generated output data may comprise control signals for controlling the external hardware. The method may further comprise implementing, by the external hardware, one or more instructions conveyed by the control signals. The external hardware may comprise a robot. In some embodiments, the external hardware may comprise a motorized vehicle. In some embodiments, the external hardware may comprise an autonomous airport dolly. The output data may comprise control signals for controlling the robot or the autonomous vehicle. The output data may comprise control signals for controlling the autonomous airport dolly. In some embodiments, the one or more instructions conveyed by the control signals may comprise one or more of: steering control instructions, throttle control instructions, brake control instructions, gear or transmission control instructions, turn or indicator signal instructions, horn activation instructions, emergency brake instructions, cruise control instructions, parking or docking instructions, adaptive driving mode instructions and / or climate control instructions. The input data may comprise sensor data from the external hardware. The input data my comprise sensor data from the robot or the autonomous vehicle. The input data may comprise sensor data from the autonomous airport dolly. The input data may comprise one or more of: LiDAR sensor data, RADAR data, GPS data, visual data from one or more cameras, vehicle acceleration data, vehicle orientation data, angular velocity data, ultrasonic sensor data, vehicle steering data, vehicle breaking data, odometry data, weather sensor data, infrared sensor data, barometric pressure sensor data, and / or microphone or sound sensor data. A further aspect of the disclosure provides a computer program comprising instructions which, when the program is executed by a computer, cause the computer to perform any of the methods disclosed herein. A further aspect of the disclosure provides a computer-readable medium comprising instructions that, when executed by one or more processors, cause an apparatus comprising the one or more processors to perform any of the methods disclosed herein. Detailed Description of the Invention Embodiments will now be described, purely by way of example, with reference to the accompanying drawings, in which: Figure 1 is a schematic diagram of a system for using a graphical programming environment to control a vehicle. Figure 2 is a schematic diagram of the vehicle shown in Figure 1. Figure 3 is a schematic diagram of the computer shown in Figure 1. Figures 4a is a schematic diagram of the graphical programming environment shown in Figure 1. Figure 4b is an enlarged section of the graphical programming environment shown in Figure 4a. Figure 5 is a schematic diagram of a module within the graphical programming environment of Figure 1. Figure 6 is a schematic diagram of a plurality of modules within a second embodiment of a graphical programming environment. Figure 7 is a flow diagram depicting a function of an event management system. Figure 8 is a flow diagram of a method of controlling a vehicle using a graphical programming environment in accordance with the present disclosure. Figure 9 is a flow diagram of a method executed by a vehicle interacting with a graphical programming environment in accordance with the present disclosure. Figure 1 is a schematic diagram of an example of a system 100 for using a graphical programming environment 120 to control an autonomous vehicle 102 in accordance with the present disclosure. As shown in Figure 1, the system 100 includes the autonomous vehicle 102 itself, a computer 106 and optionally a network 104. In some embodiments, the autonomous vehicle 102 may be configured to communicate with the computer 106 using the network 104. More specifically, the autonomous vehicle 102 may be configured to send input data to the computer 106 using a first input communication link 108 and a second input communication link 110. Additionally, the autonomous vehicle 102 may be configured to receive output data from the computer 106 using a first output communication link 114 and a second output communication link 112. The first input communication link 108, the second input communication link 110, the first output communication link 114 and the second output communication link 112 are managed by the network 104. The first input communication link 108, the second input communication link 110, the first output communication link 114 and the second output communication link 112 together form a wireless connection between autonomous vehicle 102 and the computer 106. The network 104 may comprise any form of wireless communication network. For example, the network 104 may comprise a wide-area network communication link. The wide-area network communication link may comprise a cellular telephone network, a Wi-Fi network or a combination thereof. Additionally, or alternatively, the network 104 may comprise a short-range wireless communication link. The short-range wireless communication link may comprise a radio frequency communication link and / or a Bluetooth™ communication link. Additionally or alternatively, the autonomous vehicle 102 may be configured to communicate with the computer 106 using a wired connection 105. The wired connection comprises a third input communication link 116 and a third output communication link 118. The wired connection 105 may comprise a physical cable or wire. For example, the wired connection 105 may comprise coaxial cables or fibre-optic cables. The wired connection offers a reliable and secure data transfer connection. The autonomous vehicle 102 comprises a storage area 138 for receiving baggage or cargo, a steering control system 130, a wheel and suspension system 132 and a plurality of sensors. The plurality of sensors may include a camera system 124, a LiDAR sensor 122, a RADAR sensor 128, a GPS receiver 126, an ultrasound sensor 134 and an infrared sensor 136. In some embodiments some of the above-mentioned sensors may be omitted or additional sensors may be added as needed. The input data transmitted through the first input communication link 108, the second input communication link 110 and / or the third input communication link 116 comprises sensor data from the autonomous vehicle 102. For example, the input data may comprise one or more of: LiDAR sensor data, RADAR data, GPS data, visual data from one or more cameras, vehicle acceleration data, vehicle orientation data, angular velocity data, ultrasonic sensor data, vehicle steering data, vehicle breaking data, odometry data, and / or infrared sensor data. Although certain aspects of the invention are particularly useful in connection with specific types of vehicles (i.e., an autonomous airport dolly vehicle), autonomous vehicle 102 may be any type of vehicle. Possible vehicles include, by way of example only, cars, trucks, motorcycles, busses, boats, airplanes, helicopters, lawnmowers, recreational vehicles, amusement park vehicles, trams, golf carts, trains and trolleys. In this specific embodiment, the autonomous vehicle 102 is visually represented as an autonomous airport dolly. Other forms of external hardware may be controlled using the graphical programming environment 120 in accordance with the methods disclosed herein. For example, in some alternative embodiments, the system 100 may comprise a robot, a smart appliance and / or industrial machinery. The computer 106 comprises a graphical programming environment 120. The graphical programming environment 120 comprises a plurality of distinct modules 150, 152. More specifically, the graphical programming environment 120 comprises a first code module 150 and a second code module 152. Each module comprises an executable portion of code as will be described in more detail with reference to Figures 4b, 5 and 6. The graphical programming environment 120 further comprises a single interpreter 154. The single interpreter 154 is configured to execute each portion of code contained within the plurality of distinct modules 150, 152 to generate output data. Advantageously, the single interpreter 154 acts as a central hub that seamlessly integrates all of the distinct code modules 150, 152 within the graphical programming environment 120. As a result, developers can combine various modules effortlessly, leading to the creation of a highly scalable and easily understandable object-oriented development environment. Additionally, the implementation of interpreted code (within the plurality of distinct code modules 150, 152) in the graphical programming environment 120 presents a crucial advantage for developers, particularly in the realm of real-time applications. Interpreted code allows for on-the-fly coding without the need for traditional compilation, leading to significant benefits during development, testing, and deployment phases. This capability facilitates seamless code modification and debugging in the field, ultimately reducing development time. The output data may be transmitted through the first output communication link 114, the second output communication link 112 and / or the third output communication link 118. The output data may comprise control signals for controlling the autonomous vehicle 102. For example, the output data may comprise one or more of: steering control signals, throttle control signals, brake control signals, gear or transmission control signals, turn or indicator signals, horn signals, emergency brake signals, cruise control signals, parking or docking signals, adaptive driving mode signals and / or climate control signals. As such, a developer may develop code within the graphical programming environment 120, which is configured to: receive input data from the autonomous vehicle 102, enter the input data into one or more of the plurality of distinct code modules 150, 152, execute each portion of code contained within the plurality of distinct modules 150,152 to generate output data using the single interpreter 154 and transmit the output data to the autonomous vehicle 102. This process will be described in more detail with reference to Figures 8 and 9. Although portrayed as a desktop computer in Figure 1 for the sake of simplicity, the computer 106 may be any suitable type of computing device, such as a smartphone, a tablet, laptop computer, or a wearable device (e.g., a VR headset). The computer 106 may be portable or stationary. In some embodiments, the computer 106 may be integrated into (e.g., form a pail of) the autonomous vehicle 102. The operation and functionality of the autonomous vehicle 102, the computer 106 having the graphical programming environment 120 will be further described with reference to the following Figures. Figure 2 shows a schematic diagram of the internal components of the autonomous vehicle 102 shown in Figure 1. The autonomous vehicle 102 may include an autonomous vehicle computer system 200 that is in communication with sensors 214 and vehicle control systems 230. The vehicle computer system 200 may comprise a computer containing a processor 210, a memory 202, a communication system 212 and other components (not shown for the sake of simplicity) typically present in general purpose computers. The memory 202 may comprise an operating system (OS) 204, a sensor data memory module 206 and a database 208. The operating system (OS) 204 serves as the core software that manages and controls the computer's 200 hardware and software resources. It facilitates various tasks such as process management, memory allocation, file system operations, and device management. The sensor data memory module 206 may be configured to store information related to historical sensor data. The historical sensor data may be used for future vehicle training or for testing and evaluation purposes. The database 208 may comprise any other data which is stored in the memory 202 of the autonomous vehicle 102. The memory 202 stores information accessible by processor 210, including instructions and data that may be executed or otherwise used by the processor 210. The memory 202 includes processor-executable instructions that, when executed by the processor 210, cause the computer vehicle computer 200 to perform, or assist in performing, any of the methods described with reference to Figure 9. The memory 202 may be of any type capable of storing information accessible by the processor, including a computer-readable medium, or other medium that stores data that may be read with the aid of an electronic device, such as a hard-drive, memory card, ROM, RAM, DVD or other optical disks, as well as other write-capable and readonly memories. Systems and methods may include different combinations of the foregoing, whereby different portions of the instructions and data are stored on different types of media. The processor 210 may be any conventional processor, such as a microprocessor or a microcontroller. Alternatively, the processor may be a dedicated device such as an ASIC. Although Figure 2 functionally illustrates the processor, memory, and the communication system 212 as being within the same block, it will be understood by the person skilled in the art that the processor and memory may actually comprise multiple processors and memories that may or may not be stored within the same physical housing. For example, rather than being stored in the same computer, processor 210 and memory 202 may be stored in separate devices. Although there may be advantages to locating the processor 210 and memory 202 within the autonomous vehicle 201, various processes may be performed external to the autonomous vehicle 102 and various data may be stored outside of the autonomous vehicle 102. For example, if a processor or memory used or required by the vehicle 102 occurs in an external device, vehicle 102 may obtain the information it requires wirelessly. Accordingly, although references to a processor or memory herein will assume that the processor and memory are affixed to vehicle 102, such references will be understood to include references to a collection of processors or computers or memories that may or may not operate in parallel and may or may not be located within or affixed to the vehicle 102. The communication system 212 may comprise one or more wireless transmitters and receivers, to communicate with the computer 106 over various types of networks (e.g., network 104). Additionally or alternatively, the communication system 212 may be configured to control the exchange of data over the wired connection 105. In some embodiments, the data from the sensors 214 may be provided directly to the communication system 212. As previously mentioned with reference to Figure I, the autonomous vehicle 102 comprises a variety of internal and external sensors 214 that provide data to the autonomous vehicle computer 200. The sensors 214 comprise the previously-mentioned camera system 124, LiDAR sensor 122, RADAR sensor 128, GPS receiver 126, ultrasound sensor 134 and the infrared sensor 136. The sensors allow the vehicle 102 to understand and respond to its environment in order navigate and to maximize safety. The GPS 126 may be used to determine the vehicle's 102 latitude, longitude and / or altitude. Although not explicitly shown, the sensors 214 may also comprise an accelerometer and gyroscope. The gyroscope may determine the current orientation of the vehicle 102 and changes of speed in any direction. For example, the gyroscope may detect when the vehicle is turning. The processor 210 can identify the geographic location of the vehicle. For example, the system may triangulate its location based on cell phone tower transmissions or the presence of smaller wireless networks. The processor 210 may combine the information from the various components and sensors 214 (e.g., including the GPS 126 sensor and the accelerometer and gyroscope), or select the most accurate source, and determine the geographic location of the vehicle 102 accordingly. The camera system 124, the LiDAR sensor 122, the RADAR sensor 128, the ultrasound sensor 134 and the infrared sensor 136 may be used for detecting objects external to the vehicle 102 such as other vehicles, obstacles in the roadway, traffic signals, signs, trees, etc. The LiDAR sensor 122 may be 221 mounted on the roof of the vehicle 102 or other convenient location. In some embodiments, the LiDAR sensor 122 may measure the distance between the vehicle 102 and object surfaces facing the vehicle by spinning on its axis and changing its pitch. The LiDAR sensor 122 may also be used to identify changes in surface texture or reflectivity. The RADAR sensor 128 may be used to determine the relative location of external objects, speed of the vehicle 102 and / or condition of the road surface. The camera system 124 may include one or more cameras. If multiple cameras are used and the distances from each other are known, the parallax from the different images may be used to compute the distance to various objects which are captured by the cameras. One or more of the sensors 214 may be configured to determine environmental aspects that do not specifically relate to external object detection, such as surrounding air temperature, humidity etc. The vehicle control systems 230 comprises the steering control system 130, a brake control system 232, a throttle control system 234, a parking control system 236 and a climate control system 238. Additional control systems, which have not been explicitly mentioned, may also be present. The steering control system 130 is configured to change direction of the vehicle 102. The brake control system 232 is configured to cause the vehicle 102 to decelerate. The throttle control system 234 is configured to cause the vehicle 102 to accelerate. The parking control system 236 is configured to cause the vehicle 102 to park in a designated area. The climate control system 238 is configured to regulate the temperature and humidity within the vehicle. The vehicle computer 200 is configured to communicate with the vehicle control systems 230. More specifically, the vehicle computer 200 is configured to receive the output data comprising one or more control signals from the computer 106. The vehicle computer 200 is subsequently configured to forward these one or more control signals to the vehicle control systems 230. This process will be described in more detail with reference to Figures 8 and 9. Figure 3 shows a schematic diagram of the computer 106 shown in Figure 1. The computer 106 comprises a communication interface 300, a display 302, a processor 304 and a memory 310. The processor 304 can be any suitable type of data processing device, such as a microprocessor, microcontroller or ASIC. The memory 310 comprises the graphical programming environment 120 and a computer operating system 308. The memory 310 can include a volatile memory, a non-volatile memory, or both volatile and non-volatile memories. The graphical programming environment 120 includes processor-executable instructions that, when executed by the processor 304, cause the computer 106 to perform, or assist in performing, any of the methods described with reference to Figure 8. The communication interface 300 can include any suitable type of interface that enables the computer 106 to communicate with the communication system 212 of the vehicle computer 200. The display 302 can be any suitable type of output device. For example, the display 302 may include a liquid crystal display (LCD) screen or an organic lightemitting diode (OLED) screen. The display 302 may be a touchscreen to enable data input. The display 302 may be configured to display a graphical programming interface of the graphical programming environment 120 to a user. Figures 4a shows a schematic diagram of the graphical programming environment 120 depicted in Figure 1. The graphical programming environment 120 comprises a graphical programming interface which is presented to a user upon opening of the application. As previously mentioned, the graphical programming environment 120 comprises the first code module 150, the second code module 152 and the single interpreter 154. In this embodiment, the graphical programming environment 120 further comprises a third code module 408 as well as a data and definitions module 404. Additionally, the graphical programming environment 120 comprises a toolbar 410. The graphical programming interface provides a visual representation of all the elements 150, 152, 154, 408, 404, 410 within the graphical programming environment 120. Each module 150, 152, 408 comprises an executable portion of code. More specifically, the first code module 150, the second code module 152 and the third code module 408 each comprise an executable portion of code. During operation, the portions of code within each of the code modules 150, 152, 408 are executed by the single interpreter 154. In some embodiments, the single interpreter 154 is configured to execute the portions of code within each of the code modules 150, 152, 408 concurrently. The portions of code can be seen in more detail in Figures 4b, 5 and 6. The graphical programming interface of the graphical programming environment 120 comprises a visual representation of data flow 400 between the first code module 150, the second code module 152 and the third code module 408. In this embodiment, output data from the first code module 150 serves as input data into the second code module 152. In turn, the output data from the second code module 152 serves as input data into both the third code module 408 and the first code module 150. In this manner, the first code module 150, the second code module 152 and the third code module 408 are linked together. During operation, code contained within the first code module 150 is executed by the single interpreter 154 to generate a first intermediate data output. The first intermediate data output is entered into the second module 152. In some embodiments, some or all of the first intermediate data output may comprise the generated output data which is sent to the autonomous vehicle 102. The code contained within the second code module 152 is executed by the single interpreter 154 to generate a second intermediate data output which is based on the first intermediate data output. The second intermediate data output is entered into the third module 408 and the first code module 150. In some embodiments, some or all of the second intermediate data output may comprise the generated output data which is sent to the autonomous vehicle 102. The code contained within the third code module 408 is executed by the single interpreter 154 to generate a third intermediate data output which is based on the second intermediate data output. In some embodiments, some or all of the third intermediate data output may comprise the generated output data which is sent to the autonomous vehicle 102. In this specific embodiment, the graphical programming environment 120 comprises the above-mentioned data flow 400 between the first code module 150, the second code module 152 and the third code module 408. However, a skilled person will recognise that the graphical programming environment 120 may comprise any number of distinct code modules with any arrangement of data flow between these modules. The number of distinct modules and the associated data flow between them will largely depend on the specific requirements of the external hardware which is being controlled by the code created within the graphical programming environment 120. The toolbar 410 provides quick and convenient access to commonly used functions and tools, often represented by icons or buttons. These functions can include actions like saving, opening files, copying and pasting elements within the graphical programming environment 120, and running code. The toolbar can be used to create new distinct code modules 150, 152, 408 and to edit or modify the content within the distinct code modules 150, 152, 408. The data and definitions module 404 stores data, variables and definitions which are shared between the plurality of distinct code modules 150, 152, 408 within the single graphical programming environment 154. More specifically, the data and definitions module 404 essentially serves as a shared memory bank where all relevant data is kept. The distinct code modules 150, 152,408 within the graphical programming environment 120 can easily access and utilize these variables and definitions by referencing the data and definitions module 404. This efficient and structured approach simplifies code management, promotes consistency in data usage, and allows for seamless collaboration among various modules, ensuring that the entire system functions smoothly and cohesively. As can be seen in Figure 4a, the data and definitions module 404 does not need to be explicitly linked to any one of the distinct code modules 150, 152, 408. More specifically, due to the use of the single interpreter 154, the distinct code modules 150, 152, 408 can reference the data, variables and definitions within the data and definitions module 404 without need of any data flow between the code modules 150, 152, 408 and the data and definitions module 404. Additionally, the data and definitions module 404 may be placed anywhere within the graphical programming environment 120. The removal of the need to transfer data between the distinct modules 150, 152, 408 substantially improves the computational efficiency of the program generated within the graphical programming environment 120. Figure 4b shows a more detailed view of section A of the graphical programming environment shown in Figure 4a. More specifically, Figure 4b shows a more detailed view of the first code module 150. The first code module 150 comprises a first layer 412 and a second layer 414. Each layer 412, 414 comprises a fragment of code which forms a part of the executable portion of code in the first code module 150. Section A shows the first code module 150 in a collapsed view. In the collapsed view the fragments of code within the first layer 412 and the second layer 414 remain obscured from view. Section B shows an expanded view of the first layer 412 and the second layer 414. In the expanded view the fragments of code within the first layer 412 and the second layer 414 are visible. The user can transition between the collapsed view and the expanded view by clicking on the first code module 150. This feature is particularly useful for managing and navigating through large code files, improving readability and reducing clutter. Although only the first layer 412 and the second layer 414 of the first code module 150 are shown, one or more of the plurality of distinct modules 150, 152, 408 within the graphical programming environment 120 may comprise one or more layers. More specifically, each of the distinct modules 150, 152, 408 can have any number of layers. Each of the distinct code modules 150,152,408 serve a specific function or task within the software application. In this embodiment, the first code module 150 is dedicated to the autonomous driving system, the second code module 152 is dedicated to the vehicle hardware interface and the third code module 408 is dedicated to the user interface. Each of the plurality of distinct modules may be designed to operate independently, each handling a unique aspect of the overall system's functionality. This modular structure may allow for the efficient development, management, and customization of the software. In this specific embodiment, the first code module 150 is configured to determine the vehicle’s current and target locations. The first code module 150 is also configured to determine the target speed and target direction needed for the vehicle to move from the current to the target location. Once the target speed and the target direction of the vehicle is determined, the first code module 150 transmits this data to the second code module 152. The second code module 152 is configured to implement any requested changes to the vehicle’s hardware. For example, the second code module 152 may receive instructions to increase the speed of the vehicle. Subsequently the second code module 152 is configured to implement the received instructions to increase the vehicle speed. Once implemented, the second code module collects the current sensor data (i.e. location data, speed data etc.) and sends this feedback data back to the first code module 150. This process repeats continuously during the vehicle’s journey. The third code module 408 is configured to display the vehicle data to the user. For example, the third code module 408, may be configured to display the current and target vehicle speed, direction, position etc. In some embodiments, the user may be able to manually change vehicle parameters (speed, direction of travel etc.) using the third code module 408. The user interface, implemented by the third code module 408, may be displayed on the vehicle’s onboard computer. In other implementations, the user interface may be displayed on a remote device e.g., a user’s phone, tablet or desktop computer. In some embodiments, the user interface may be configured to monitor vehicle data from multiple vehicles. In this manner, the user may be able to monitor multiple vehicles at the same time. Advantageously, this implementation would allow the user to monitor a fleet of autonomous vehicle, allowing the user to quickly and efficiently resolve errors arising in any one of the vehicles within the fleet. Figure 5 shows a more detailed view of the second layer 414 of the first code module 150 within the graphical programming environment 120. The second layer 414 comprises a first fragment of code 500. The first fragment of code 500 forms a part of the executable portion of code in the first code module 150. The first fragment of code 500 comprises a function 514. The first fragment of code 500 can be edited by a developer by simply clicking on the second layer 414. Additionally, the first fragment of code 500 can be written and edited live, while the code in the graphical programming environment 120 is running. This allows the developers to immediately see the effects of the code changes on the function of the autonomous vehicle 102. Advantageously, this immediate feedback allows the developers to quickly modify and address any errors in the code. During operation, input data 504 is entered into the second layer 414. More specifically, the input data 504 is entered into the function 514 of the first fragment of code 500. In this embodiment, the input data 504 comprises: index (i), data (v) and time (t). The data (v) comprises an array of values. Among other parameters, the array of values comprises the speed of the autonomous vehicle 102. Subsequently, the single interpreter 154 executes the function 514 to generate output data 506. The output data is subsequently transmitted to the second code module 152. In other words, the output data 506 acts as input data into the second code module 152. In other embodiments (not shown), the output data 506 may be transmitted to the autonomous vehicle 102. The second layer 414 of the first code module 150 further comprises an inspection window 502. The inspection window allows a user to continuously monitor one or more code parameters as the first fragment of code 500 is executed by the single interpreter 154. More specifically, the inspection window 502 shows the speed (v) 508 and position 510 of the autonomous vehicle 102 as the first fragment of code 500 is executed by the single interpreter 154. The first fragment of code 500 comprises an “on” button 512 which can be used to switch the first fragment of code 500 on and off as required by the developer. This button 512 is especially useful if the code needs to be reset, for example in instances where an infinite loop is formed. Each of the code modules 150,152,408 and their corresponding layers 412,414 can comprise a similar inspection window. Inspection windows can be added or removed from the code modules 150, 152, 408 as needed by the developers. The inspection window 502 is beneficial since it provides developers with immediate visibility into the internal state of the program, making it easier to track variables, identify issues, and verify the accuracy of computations during runtime. This real-time feedback streamlines the debugging process, reducing the time required to pinpoint and resolve errors, thus accelerating development and improving code quality. Figure 6 shows a schematic diagram of a plurality of modules within the graphical programming environment 120. More specifically, Figure 6 shows a second embodiment of the graphical programming environment 120 having the data and definitions module 404, a fourth code module 606 and a fifth code module 608. The data and definitions module comprises a first portion 602 and a second portion 600. The first portion 602 and the second portion 600 each define different data and variables. The first portion 602 comprises a second inspection window 604 which can be used to monitor the variables defined in the first portion 602. In this embodiment, the data and definitions module 404, the fourth code module 606 and the fifth code module 608 are not linked together and no data flows between them. Nevertheless, due to the use of the single interpreter 154 (not shown), any data or variables which are defined in a given module 404, 606, 608 are automatically shared with the remaining modules 404, 606, 608. In other words, the developer does not have to re-define any data or variable in the fragments of code within each of the modules 404, 606, 608. The graphical programming environment 120 may further include an event management system. Figure 7 shows a schematic diagram of the function of the event management system 700. The event management system 700 is configured to: schedule the entering of the input data (or the intermediate data output) into one or more of the plurality of distinct modules 150, 152, 408, 606, 608, 404 and schedule the transmitting of the generated output data to the autonomous vehicle 102. The process of scheduling the entering of the input data (or the intermediate data output) into one or more of the plurality of distinct modules 150, 152, 408, 606, 608, 404 will now be described with reference to Figure 7. At step 710, input data is received at the event management system 700 from the autonomous vehicle 102. For example, at step 710 a first input data portion and a second input data portion may be received at the event management system 700 from the autonomous vehicle 102. The first input data portion and the second input data portion may form a part of the input data received from the autonomous vehicle 102. The second input data portion may be received by the event management system 700 after the first input data portion. At step 702, the event management system 700 assigns a timestamp to each of the received data portions. For example, the event management system 700 may assign a first timestamp to the first input data portion and a second timestamp to the second input data portion. At step 704, the event management system 700 enters each of the input data portions into a queue based on the assigned timestamp. For example, the event management system may enter the first input data portion and the second input data portion into a queue. The second input data portion may be placed behind the first input data portion in the queue, since the second input data portion has been received by the event management system 700 after the first input data portion and thus the second input data portion has a later timestamp than the first input data portion. At step 706, the event management system 700 checks an event clock. The event clock may dictate the time intervals (or transmission periods) at which the data portions may be entered into one or more of the plurality of distinct modules 150, 152,408, 606, 608, 404. For example, the event clock may dictate that data portions may be entered into one or more of the plurality of distinct modules 150, 152, 408, 606, 608, 404 only at discrete time intervals. In other embodiments, the event clock may allow data portions to be entered into one or more of the plurality of distinct modules 150, 152, 408, 606, 608, 404 at any time (i.e, continuously). At step 708, the event management system 700 selects an input data portion from the queue based on the position of the input data portion in the queue. For example, the event management system 700 selects the first input data portion, since the first input data portion is placed ahead of the second input data portion in the queue. At step 714, the event management system 700 enters the selected input data portion into one or more of the plurality of distinct modules 150, 152, 408, 606, 608, 404. For example, the event management system 700 enters the first input data portion into one or more of the plurality of distinct modules 150, 152, 408, 606, 608, 404. Steps 706, 708 and 714 are repeated until all input data portions are entered into one or more of the plurality of distinct modules 150, 152, 408, 606, 608, 404. For example, steps 706, 708 and 714 repeated until the second input data portion is entered into one or more of the plurality of distinct modules 150, 152, 408, 606, 608, 404. Similar steps 710, 700, 702, 704, 706, 708 and 714 can be implemented to schedule the entering of one or more portions of the intermediate data output from one of the code modules 150, 152, 408, 606, 608, 404 into another one of the code modules 150, 152, 408, 606, 608, 404. The process of scheduling the transmitting of the generated output data to the autonomous vehicle 102 will now be described with reference to Figure 7. At step 712, generated output data is received at the event management system 700 from the one or more of the plurality of distinct modules 150, 152, 408, 606, 608, 404. For example, at step 712 a first output data portion and a second output data portion may be received at the event management system 700 from the one or more of the plurality of distinct modules 150, 152, 408, 606, 608,404. The first output data portion and the second output data portion may form a part of the generated output data received from the one or more of the plurality of distinct modules 150, 152, 408, 606, 608, 404. The second output data portion may be received by the event management system 700 after the first output data portion. At step 702, the event management system 700 assigns a timestamp to each of the received data portions. For example, the event management system 700 may assign a third timestamp to the first output data portion and a fourth timestamp to the second output data portion. At step 704, the event management system 700 enters each of the output data portions into a queue based on the assigned timestamp. For example, the event management system 700 may enter the first output data portion and the second output data portion into a queue. The second output data portion may be placed behind the first output data portion in the queue, since the second output data portion has been received by the event management system 700 after the first output data portion and thus the second output data portion has a later timestamp than the first output data portion. At step 706, the event management system 700 checks an event clock. The event clock may dictate the time intervals (or transmission periods) at which the data portions may be transmitted to the autonomous vehicle 102. For example, the event clock may dictate that data portions may be transmitted to the autonomous vehicle 102 only at discrete time intervals. In other embodiments, the event clock may allow data portions to be transmitted to the autonomous vehicle 102 at any time (i.e, continuously). At step 708, the event management system 700 selects an output data portion from the queue based on the position of the output data portion in the queue. For example, the event management system 700 selects the first output data portion, since the first output data portion is placed ahead of the second output data portion in the queue. At step 716, the event management system 700 transmits the selected output data portion to the autonomous vehicle 102. For example, the event management system 700 transmits the first output data portion to the autonomous vehicle 102. Steps 706,708 and 716 are repeated until all output data portions are transmitted to the autonomous vehicle 102. For example, steps 706, 708 and 716 repeated until the second output data portion is transmitted to the autonomous vehicle 102. The event management system 700 offers significant advantages in terms of efficiency, reliability and safety of the software generated within the graphical programming environment 120. By scheduling the data input and output events, developers can ensure that data is fed into the code modules 150, 152, 408, 606, 608, 404 at precisely the right time, optimizing the software's performance. Furthermore, this approach minimizes the risk of data bottlenecks or delays, crucial in real-time or time-sensitive applications such as autonomous vehicles. Additionally, scheduling the transmission of output data to the autonomous vehicle 102 allows for better synchronization with other systems or devices, improving overall system coordination and reliability. Figure 8 shows a flow diagram of a method 800 of controlling the autonomous vehicle 102 in accordance with the present disclosure. The method 800 is executed by the graphical programming environment 120. At step 802, the graphical programming environment 120 receives input data from the autonomous vehicle 102. At step 804, the graphical programming environment 120 enters the input data into one or more of a plurality of distinct modules 150, 152, 408, 606, 608, 404 within the graphical programming environment 120. In some embodiments, the event management system 700 is used to schedule the entering of the input data into one or more of a plurality of distinct modules 150, 152, 408, 606, 608, 404 as described with reference to Figure 7. At step 806, the single interpreter 154 executes each portion of code contained within the plurality of distinct modules 150, 152, 408, 606, 608, 404 to generate output data. At step 808, the graphical programming environment 120 transmits the generated output data from the graphical programming environment 120 to the autonomous vehicle 102. In some embodiments, the event management system 700 is used to schedule the transmitting of the output data to the autonomous vehicle 102 as described with reference to Figure 7. Figure 9 is a flow diagram of a method executed by the autonomous vehicle 102 interacting with the graphical programming environment 120. At step 902, the autonomous vehicle 102 sends the input data to the graphical programming environment 120. At step 904, the autonomous vehicle 102 receives the generated output data from the graphical programming environment 120. At step 906, the autonomous vehicle 102 may implement one or more instructions conveyed by control signals contained within the received output data. For example, the autonomous vehicle 102 may implement one or more of the steering control signals, throttle control signals, brake control signals, gear or transmission control signals, turn or indicator signals, horn signals, emergency brake signals, cruise control signals, parking or docking signals, adaptive driving mode signals and / or climate control signals. The implemented control signals may change direction or speed of the autonomous vehicle 102. The implemented control signals may turn on the indicators, change gear, sound the horn, implement the cruise control, initiate the parking sequence, change the driving mode of, or change the temperature within the autonomous vehicle 102. It will be understood that the invention has been described above purely by way of example, and that modifications of detail can be made within the scope of the claims. Although the graphical programming environment has been described with reference to specific applications in the autonomous vehicle industry, it should be appreciated that the graphical programming environment can be used in other contexts and industries. For example, the graphical programming environment disclosed herein can be used in the robotics industry. The methods shown in Figures 7, 8 and 9 can be performed by instructions stored on a processor-readable medium. The processor-readable medium may be: a read-only memory (including a PROM, EPROM or EEPROM); random access memory; a flash memory; an electrical, electromagnetic or optical signal; a magnetic, optical or magneto-optical storage medium; one or more registers of a processor; or any other type of processor-readable medium. In alternative embodiments, the present disclosure can be implemented as control logic in hardware, firmware, software or any combination thereof. Additionally, the sequence of operations shown in Figures 7, 8 and 9 are merely exemplary. Any of the operations shown in the methods 800 and 900 may be performed in a different order that achieves substantially the same result.

Claims

1. A method for using a graphical programming environment to control an external hardware, the method comprising:receiving, by the graphical programming environment, input data from the external hardware;entering the input data into one or more of a plurality of distinct modules within the graphical programming environment, wherein each module comprises an executable portion of code;executing, by a single interpreter in the graphical programming environment, each portion of code contained within the plurality of distinct modules to generate output data; andtransmitting, by the graphical programming environment, the generated output data from the graphical programming environment to the external hardware.

2. A method according to claim 1, wherein the plurality of distinct modules within the graphical programming environment comprise at least a first code module and a second code module.

3. A method according to claim 2, wherein entering the input data comprises entering the input data into the first code module and wherein executing the code contained within the plurality of distinct modules comprises:executing a code contained within the first code module to generate a first intermediate data output;entering the first intermediate data output into the second code module;executing a code contained within the second code module based on the first intermediate data output to generate the output data.

4. A method according to any one of the preceding claims, wherein the graphical programming environment further comprises an event management system, the event management system being configured to:schedule the entering of the input data into one or more of the plurality of distinct modules; and / orschedule the transmitting of the generated output data to the external hardware.

5. A method according to claim 4 as dependent on claim 3, wherein the event management system is configured to schedule entering the input data into the first code module and / or schedule entering the first intermediate data output into the second code module.

6. A method according to claim 4 or claim 5, wherein scheduling the entering of the input data comprises:receiving a first input data portion of the input data from the external device;assigning a first timestamp to the first input data portion; andentering the first input data portion into one or more of the plurality of distinct modules during a first transmission period determined based on the first timestamp.

7. A method according to claim 6, wherein scheduling the entering of the input data further comprises:receiving a second input data portion of the input data from the external device;assigning a second timestamp to the second input data portion; andentering the second input data portion into one or more of the plurality of distinct modules during a second transmission period determined based on the second timestamp.

8. A method according to claim 6 and claim 7, wherein the event management system is configured to place the first input data portion and / or the second input data portion in a queue, and subsequently enter the first input data portion and / or the second input data portion into one or more of the plurality of distinct modules in chronological order based on the position of the first input data portion and / or the second input data portion in the queue.

9. A method according to any one of claims 4 to 8, wherein scheduling the transmitting of the generated output data comprises:receiving a first output data portion of the generated output data from the one or more of the plurality of distinct modules;assigning a third timestamp to the first output data portion; andtransmitting, the first output data portion from the graphical programming environment to the external hardware during a third transmission period determined based on the third timestamp.

10. A method according to claim 9, wherein scheduling the transmitting of the generated output data further comprises:receiving a second output data portion of the generated output data from the one or more of the plurality of distinct modules;assigning a fourth timestamp to the second output data portion; andtransmitting, the second output data portion from the graphical programming environment to the external hardware during a fourth transmission period determined based on the fourth timestamp.

11. A method according to claim 9 and claim 10, wherein the event management system is configured to place the first output data portion and / or the second outputdata portion in a queue, and subsequently transmit the first output data portion and / or the second output data portion to the external hardware in chronological order based on the position of the first output data portion and / or the second output data portion in the queue.

12. A method according to any one of the preceding claims, wherein the external hardware comprises a robot or a motorized vehicle.

13. A method according to any one of the preceding claims, wherein the input data comprises sensor data from the external hardware.

14. A method according to any one of the preceding claims, wherein the output data comprises control signals for controlling the external hardware.

15. A method according to any one of the preceding claims, wherein the single interpreter is configured to execute the code within the plurality of distinct modules concurrently.

16. A method according to any one of the preceding claims, wherein one or more of the plurality of distinct modules within the graphical programming environment comprises an inspection window, the inspection window allowing a user to continuously monitor one or more code parameters as each portion of the code is executed by the single interpreter.

17. A method according to any one of the preceding claims, wherein the graphical programming environment comprises a user interface, the user interface providing a visual representation of the plurality of distinct modules, the external hardware, and any flow of data between the plurality of distinct modules and the external hardware.

18. A method according to any one of the preceding claims, wherein one or more of the plurality of distinct modules within the graphical programming environment comprise one or more layers, each layer having a fragment of code which forms a part of the executable portion of code in each distinct module.

19. A method executed by an external hardware interacting with a graphical programming environment, the method comprising:sending, by the external hardware, input data to the graphical programming environment;receiving, by the external hardware, a generated output data from the graphical programming environment, wherein a single interpreter in the graphical programming environment is configured to execute each portion of code contained within a plurality of distinct modules within the graphical programming environment to obtain the generated output data.

20. A method according to claim 19, wherein the generated output data comprises control signals for controlling the external hardware, and the method further comprises:implementing, by the external hardware, one or more instructions conveyed by the control signals.

21. A method according to claim 19 or 20, wherein the external hardw are comprises a robot or a motorized vehicle.

22. A method according to any one of claims 19 to 21, wherein the input data comprises sensor data from the external hardware.

23. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to perform a method in accordance with any of claims 1 to 18 or claims 19 to 22.5 24. A computer-readable medium comprising instructions that, when executed byone or more processors, cause an apparatus comprising the one or more processors to perform a method in accordance with any of claims 1 to 18 or claims 19 to 22.

Images