Light array control

Abstract

The invention relates to light array control. A remote node for controlling a vehicle headlight array is provided. The remote node includes: a memory configured to store a plurality of mathematical functions for generating a corresponding plurality of predetermined image types, where the plurality of image types include at least a low beam image and a high beam image; a receiving interface configured to receive frame data, where the frame data includes selection data indicative of a selected one of the plurality of image types; a rendering engine configured to generate a signal usable by the vehicle headlight array to generate an output image using a mathematical function of a plurality of mathematical functions corresponding to a selected one of the plurality of image types; and an output interface configured to output the signal to the vehicle headlamp light array.

Description

[0001] Related applications

[0002] This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 569,657, filed on March 25, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The disclosure herein relates to controlling a light array. In one example, the disclosure herein relates to controlling a vehicle headlamp light array using a vehicle CPU and a remote node. Background Art

[0004] Modern vehicles are increasingly incorporating advanced technologies to enhance safety and the user experience. One area of ​​innovation is vehicle headlamp systems, which are evolving from traditional headlights to complex light arrays capable of projecting high-resolution images. These advanced headlamp systems can offer various functionalities, such as adaptive lighting that adjusts the beam pattern based on driving conditions, as well as the ability to project information onto the road surface. However, the implementation of these advanced features presents several technical challenges.

[0005] Current headlamp systems typically rely on high-bandwidth data links to transmit detailed image data from the vehicle's central processing unit (CPU) to the headlamp light array. This approach requires expensive cables and connectors, which can significantly increase the overall cost and complexity of the vehicle's electrical system. Additionally, the high data rates required to transmit image data can strain the vehicle's communications infrastructure, potentially impacting the performance of other critical systems.

[0006] Another challenge is the need to process and render dynamic images in real time, such as adaptive beam patterns and overlay information like speed alerts or hazard warnings. Existing solutions can involve transmitting large amounts of raw image data, which can be inefficient and lead to latency issues. Furthermore, the flexibility to adjust the projected image based on real-time conditions is limited by current data transmission and processing methods. These limitations highlight the need for more efficient and cost-effective solutions to support next-generation vehicle headlight systems. Summary of the Invention

[0007] According to a first aspect of the present invention, a remote node for controlling a vehicle headlight array is provided. The remote node comprises: a memory configured to store a plurality of mathematical functions for generating a corresponding plurality of predetermined image types, wherein the plurality of image types include at least a low-beam image and a high-beam image; a receiving interface configured to receive frame data, wherein the frame data includes selection data indicating a selected one of the plurality of image types; a rendering engine configured to use a mathematical function from the plurality of mathematical functions corresponding to the selected one of the plurality of image types to generate a signal that can be used by the vehicle headlight array to generate an output image; and an output interface configured to output the signal to the vehicle headlight array.

[0008] Optionally, the frame datagram contains overlay information for generating an overlay to be applied to a selected one of the plurality of image types. Optionally, the rendering engine is configured to further use the overlay information to generate a signal.

[0009] Optionally, the overlay information comprises mask information for generating at least one mask region included in the overlay.

[0010] Optionally, each at least one mask area has a defined light intensity.

[0011] Optionally, the defined light intensity is uniform within each at least one mask area, or wherein the defined light intensity varies within each at least one mask area.

[0012] Optionally, the defined light intensity has a lower or higher light intensity relative to non-shaded areas. Optionally, the defined light intensity comprises zero intensity.

[0013] Optionally, the mask information indicates at least one mask coordinate and an intensity value of each at least one mask region.

[0014] Optionally, each mask coordinate comprises at least one pair of x, y coordinate values ​​defining the size, shape and position of the mask region.

[0015] Optionally, each of the at least one pair of coordinate values ​​comprises 16 bits and the intensity value comprises 8 bits.

[0016] Optionally, the mask information is used to generate up to 25 mask regions.

[0017] Optionally, the overlay information comprises supplementary information including a supplementary image in the overlay.

[0018] Optionally, the supplemental information comprises a compressed version of the supplemental image, and the rendering engine is configured to generate the supplemental image using the supplemental information.

[0019] Optionally, the remote node receives the frame data from the processing unit via a 10BASE-T1S Ethernet link.

[0020] Optionally, the remote node is an E2B.

[0021] Optionally, a plurality of mathematical functions is received from a processing unit.

[0022] Optionally, the signal includes cyclic redundancy check (CRC) data to ensure data integrity.

[0023] Optionally, the frame data further comprises parameter changes to the mathematical function.

[0024] According to a second aspect of the present invention, there is provided a processing unit for controlling a vehicle headlight array, comprising: a processing unit configured to generate frame data, the frame data including selection data indicating a selected one of a plurality of image types, wherein the plurality of image types include at least a low beam image and a high beam image; and a transmission interface configured to send the frame data to a remote node for generating a signal at the remote node that can be used by the vehicle headlight array to generate an output image.

[0025] Optionally, the frame datagram contains overlay information for generating an overlay to be applied to a selected one of a plurality of image types.

[0026] Optionally, the overlay information comprises mask information for generating at least one mask region included in the overlay.

[0027] Optionally, each at least one mask area has a defined light intensity.

[0028] Optionally, the defined light intensity is uniform within each at least one mask area, or wherein the defined light intensity varies within each at least one mask area.

[0029] Optionally, the defined light intensity has a lower or higher light intensity relative to non-shaded areas. Optionally, the defined light intensity comprises zero intensity.

[0030] Optionally, the mask information indicates at least one mask coordinate and an intensity value of each at least one mask region.

[0031] Optionally, each mask coordinate comprises at least one pair of x, y coordinate values ​​defining the size, shape and position of the mask region.

[0032] Optionally, each of the at least one pair of coordinate values ​​comprises 16 bits and the intensity value comprises 8 bits.

[0033] Optionally, the mask information is used to generate up to 25 mask regions.

[0034] Optionally, the overlay information contains supplementary information included in the overlay.

[0035] Optionally, the supplemental information is compressed.

[0036] Optionally, the transmission interface is configured to send the frame data to the remote node via a 10BASE-T1S Ethernet link.

[0037] According to a third aspect of the present invention, there is provided a system for controlling a vehicle headlight array, comprising: a processing unit as described in any of the aforementioned processing units; and a remote node as described in any of the aforementioned remote nodes.

[0038] According to a fourth aspect of the present invention, a method for controlling a vehicle headlight array using a remote node is provided, comprising: receiving frame data, wherein the frame data includes selection data indicating a selected one of a plurality of image types, wherein the plurality of image types include at least a low beam image and a high beam image; using a mathematical function corresponding to the selected one of the plurality of image types to generate a signal that can be used by the vehicle headlight array to generate an output image; and outputting the signal to the vehicle headlight array.

[0039] Optionally, the frame datagram contains overlay information for generating an overlay to be applied to a selected one of the plurality of image types. Optionally, the remote note is configured to further use the overlay information to generate a signal.

[0040] Optionally, the overlay information comprises mask information for generating at least one mask region included in the overlay.

[0041] Optionally, each at least one mask area has a defined light intensity.

[0042] Optionally, the defined light intensity is uniform within each at least one mask area, or wherein the defined light intensity varies within each at least one mask area.

[0043] Optionally, the defined light intensity has a lower or higher light intensity relative to non-shaded areas. Optionally, the defined light intensity comprises zero intensity.

[0044] Optionally, the mask information indicates at least one mask coordinate and an intensity value of each at least one mask region.

[0045] Optionally, each mask coordinate comprises at least one pair of x, y coordinate values ​​defining the size, shape and position of the mask region.

[0046] Optionally, each of the at least one pair of coordinate values ​​comprises 16 bits and the intensity value comprises 8 bits.

[0047] Optionally, the mask information is used to generate up to 25 mask regions.

[0048] Optionally, the overlay information contains supplementary information included in the overlay.

[0049] Optionally, the supplemental information is compressed, and the method further comprises decompressing the supplemental information.

[0050] Optionally, the signal includes cyclic redundancy check (CRC) data to ensure data integrity.

[0051] Optionally, the frame data further comprises parameter changes to the mathematical function.

[0052] According to a fifth aspect of the present invention, there is provided a method for controlling a vehicle headlight array using a processing unit, comprising: generating frame data, the frame data including selection data indicating a selected one of a plurality of image types, wherein the plurality of image types include at least a low beam image and a high beam image; and sending the frame data to a remote node for generating a signal at the remote node that can be used by the vehicle headlight array to generate an output image.

[0053] Optionally, the frame datagram contains overlay information for generating an overlay to be applied to a selected one of a plurality of image types.

[0054] Optionally, the overlay information comprises mask information for generating at least one mask region included in the overlay.

[0055] Optionally, each at least one mask area has a defined light intensity.

[0056] Optionally, the defined light intensity is uniform within each at least one mask area, or wherein the defined light intensity varies within each at least one mask area.

[0057] Optionally, the defined light intensity has a lower or higher light intensity relative to non-shaded areas. Optionally, the defined light intensity comprises zero intensity.

[0058] Optionally, the mask information indicates at least one mask coordinate and an intensity value of each at least one mask region.

[0059] Optionally, each mask coordinate comprises at least one pair of x, y coordinate values ​​defining the size, shape and position of the mask region.

[0060] Optionally, each of the at least one pair of coordinate values ​​comprises 16 bits and the intensity value comprises 8 bits.

[0061] Optionally, the mask information is used to generate up to 25 mask regions.

[0062] Optionally, the overlay information contains supplementary information included in the overlay.

[0063] Optionally, the supplemental information is compressed.

[0064] According to a sixth aspect of the present invention, a controller / remote node for controlling a light array is provided. The controller / remote node comprises: a memory configured to store a plurality of mathematical functions for generating a corresponding plurality of predetermined image types; a receiving interface configured to receive frame data, wherein the frame data includes selection data indicating a selected one of the plurality of image types; a rendering engine configured to use a mathematical function from the plurality of mathematical functions corresponding to the selected one of the plurality of image types to generate a signal that can be used by the light array to generate an output image; and an output interface configured to output the signal to the light array.

[0065] According to a seventh aspect of the present invention, there is provided a processing unit for controlling a light array, comprising: a processing unit configured to generate frame data, the frame data including selection data indicating a selected one of a plurality of image types; and a transmission interface configured to send the frame data to a remote node for generating a signal at the remote node that can be used by the light array to generate an output image.

[0066] According to an eighth aspect of the present invention, there is provided a method for controlling a light array using a remote node, comprising: receiving frame data, wherein the frame data includes selection data indicating a selected one of a plurality of image types; using a mathematical function corresponding to the selected one of the plurality of image types to generate a signal that can be used by the light array to generate an output image; and outputting the signal to the light array.

[0067] According to a ninth aspect of the present invention, there is provided a method for controlling a light array using a processing unit, comprising: generating frame data containing selection data indicating a selected one of a plurality of image types; and sending the frame data to a remote node for generating a signal at the remote node that can be used by the light array to produce an output image.

[0068] According to a tenth aspect of the present invention, there is provided a controller / remote node for controlling a light array, the remote node comprising: a receiving interface configured to receive frame data comprising overlay information for generating an overlay to be applied to an output image; a rendering engine configured to generate an overlay using the overlay information; and an output interface configured to output the overlay to the light array.

[0069] According to an eleventh aspect of the present invention, there is provided a processing unit for controlling a light array, comprising: a processing unit configured to generate frame data, the frame data including overlay information for generating an overlay to be applied to an output image; and a transmission interface configured to send the frame data to a remote node for generating the overlay to be applied to the output image at the remote node.

[0070] According to a twelfth aspect of the present invention, there is provided a method for controlling a light array using a remote node, comprising: receiving frame data comprising overlay information for generating an overlay to be applied to an output image; generating an overlay using the overlay information; and outputting the overlay to the light array.

[0071] According to a thirteenth aspect of the present invention, there is provided a method for controlling a light array using a processing unit, comprising: generating frame data, the frame data including overlay information for generating an overlay to be applied to an output image; and sending the frame data to a remote node for generating the overlay to be applied to the output image at the remote node.

[0072] According to a fourteenth aspect of the present invention, there is provided a non-transitory computer readable medium comprising instructions which, when executed by a processor, cause the processor to perform a method according to any of the preceding method statements.

[0073] According to a fifteenth aspect of the present invention, there is provided a vehicle comprising the remote node and the processing unit disclosed herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0074] The present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0075] Figure 1 A vehicle according to aspects of the present invention is shown;

[0076] Figure 2 is a block diagram illustrating communications between a vehicle CPU, a remote node, and a vehicle headlight array;

[0077] Figure 3 shows an example of frame data that can be transmitted from a vehicle CPU to a remote node;

[0078] Figure 4 Shown in Figure 2 Further details of the communication between the vehicle CPU and the remote nodes and the vehicle headlight array;

[0079] Figure 5 The output image projection with the masked area is shown;

[0080] Figure 6 The output image projection with the overlaid supplementary image is shown;

[0081] Figure 7 The output image projection with the mask area and the supplemental image covered is shown;

[0082] Figure 8 is a flow chart illustrating a method performed at a remote node; and

[0083] Figure 9 is a flow chart illustrating a method performed at a processing unit. DETAILED DESCRIPTION

[0084] The present disclosure relates to a system for controlling a light array, particularly a vehicle headlamp array. Conventional vehicle headlamp systems face limitations in their ability to project images. The system disclosed herein addresses these limitations by introducing a remote node and a vehicle central processing unit (CPU) that work together to efficiently generate and transmit data defining the details of the image to be output by the light array, thereby ensuring optimal performance and efficiency.

[0085] One of the main challenges of current headlamp systems is the need for a high-bandwidth data link to transmit detailed image data from the vehicle's CPU to the headlamp light array. This is particularly true for next-generation high-resolution, high-refresh-rate light arrays (e.g., arrays of approximately 100k pixels with a 100Hz refresh rate). This approach requires expensive cables and connectors, increasing the overall cost and complexity of the vehicle's electrical system. Additionally, the high data rates required to transmit image data can strain the vehicle's communications infrastructure, potentially impacting the performance of other critical systems.

[0086] One solution to addressing the challenges of high-bandwidth data links may be to significantly compress the image data at the vehicle CPU, transmit the compressed data via the vehicle's communications infrastructure, and then decompress the image data at the image sensor. However, the inventors have discovered several drawbacks to this. For example, if lossy compression is used, image quality may be reduced, while if lossless compression is used, efficiency and latency issues may result. Additionally, ensuring that lossless compression fits within the available bandwidth may be challenging, and it may not be possible to fully compress the data while ensuring that the compression remains lossless. These challenges can result in delays in rendering dynamic images (such as adaptive beam patterns) and overlay information (such as speed alerts or hazard warnings), which may make desired high refresh rates (such as 100Hz) unfeasible.

[0087] As a solution to these problems, the inventors have discovered that certain types of images (particularly standard vehicle headlight images, such as low-beam and high-beam images) can be described and generated within mathematical functions (e.g., see Appendix A) that do not require large amounts of data storage. Consequently, those functions can be efficiently stored locally on the image array, for example, at a remote node near the light array, and subsequently used to generate the image signals that drive the light array. Consequently, the amount of data required to be transmitted from the vehicle's CPU using the vehicle's communications infrastructure can be significantly reduced, as any of those standard (or predetermined) image types can be efficiently transmitted from the CPU to the remote node simply by indicating a selection (which can be achieved using a very small number of data bits, such as one, two, or three). The system can also enhance the flexibility and functionality of the vehicle's headlight system by integrating overlay information, thereby enabling more complex images. Additional image features desired to be overlaid on the selected standard image, such as image masks and / or supplemental image information, such as speed limit signs or warning symbols (which can improve driver awareness and safety), can be transmitted from the CPU to the remote node using a relatively small amount of data. Thus, the total amount of data to be transmitted from the CPU via the vehicle's network infrastructure per frame can be significantly reduced, which enables high-resolution, high-refresh rate optical systems while utilizing relatively low-bandwidth communication systems (such as, for example, 10BaseT1S Ethernet links).

[0088] Figure 1 A vehicle 100 is shown, comprising a vehicle central processing unit (CPU) 110, a remote node 150, and a vehicle headlight array 170. The vehicle CPU 110 is connected to the remote node 150, which in turn is connected to the vehicle headlight array 170.

[0089] The connection between the vehicle CPU 110 and the remote node 150 can be established using various communication links. One example is an Ethernet link, such as a 10BASE-T1S Ethernet link. However, this is merely an example and should not be considered limiting. Other types of communication links or wireless communication protocols can also be used to connect the vehicle CPU 110 to the remote node 150. Similarly, the remote node 150 can be an E2B (Ethernet to the Edge) device.

[0090] The connection between the remote node 150 and the vehicle headlight array 170 can be of any suitable type. Examples include a direct wired connection or a wireless connection, depending on the specific system implementation, such as the design and requirements of the vehicle headlight array 170.

[0091] In one example, vehicle headlamp array 170 may include micro-LEDs, which offer several advantages. Micro-LEDs provide high brightness, excellent color accuracy, and energy efficiency, making them useful in automotive lighting applications. Additionally, micro-LEDs can be precisely controlled to produce complex lighting patterns and projections.

[0092] While micro-LEDs have many advantages, the vehicle headlight light array 170 is not limited to this technology. Other examples of light arrays that can be used include OLED (organic light emitting diode) arrays and traditional LED (light emitting diode) arrays. Each of these technologies has its own benefits and can be selected based on the specific requirements of the vehicle lighting system.

[0093] In addition to automotive applications, the system described herein can be applied to a variety of other fields. For example, the system can be adapted to control advertising displays and stage lighting in entertainment venues.

[0094] By providing a flexible and efficient solution for controlling light arrays, the system significantly improves performance, applicability, and efficiency in a wide range of applications.

[0095] Figure 2 is a block diagram showing the communication between the vehicle CPU 110, the remote node 150 and the vehicle headlight array 170. Figure 1 Same features.

[0096] Remote node 150 includes an extraction frame data function / circuitry 220 and a mathematical processing function / circuitry 230. The separation of the individual functions / circuits is intended merely to simplify the explanation of the operation of remote node 150, and in practice, the different functions / circuits may be implemented within a single function / circuitry (such as a single software program or function) or may be subdivided in any other suitable manner (e.g., as two or more interconnected software programs or functions / routines).

[0097] The remote node 150 receives frame data from the vehicle CPU 110. The frame data is typically received at the refresh rate of the vehicle's headlight array 170. For example, if the vehicle's headlight array 170 operates at a refresh rate of 100 Hz, frame data is received 100 times per second at the remote node 150. However, the remote node 150 can be designed to be flexible and adapt to higher or lower frequency frame data regardless of the refresh rate of the vehicle's headlight array 170, such as 60 Hz for less demanding applications or 140 Hz for high-performance scenarios. For example, frame data can be received to control low beam or high beam projection at a lower frequency (such as 50 Hz) compared to the 100 Hz refresh rate of the light array 170 without noticeably impacting the user experience. If the frame data is received at 140 Hz (which may be higher than the 100 Hz refresh rate of the vehicle headlight array), the remote node 150 can still process the frame data 140 times per second, but the vehicle headlight array 170 will only be updated at its maximum refresh rate of 100 Hz. This means that although the remote node 150 can handle and process data at 140 Hz, the actual output to the vehicle headlight array 170 will be limited to a 100 Hz refresh rate.

[0098] The frame data includes selection data indicating a selected one of multiple image types. Examples of multiple image types include low beam and high beam projection. The indication of the selected image type may take any suitable form, such as a selection value within header information of the frame data, whose value indicates the selection. In the simplest example, a selection value of 0 may indicate a low beam selection, and a selection value of 1 may indicate a high beam selection. Extract frame data function / circuitry 220 extracts the indication of the selected one of the multiple image types from the frame data. The frame data may also include overlay information for generating an overlay to be applied to the selected one of the multiple image types, as explained in more detail later.

[0099] Mathematical processing functionality / circuitry 230 may include, for example, a plurality of mathematical functions stored in memory (e.g., see Appendix A) for generating a corresponding plurality of image types. As explained above, in one example, the plurality of image types may include at least a low-beam image and a high-beam image. Remote node 150 uses a mathematical function from the plurality of mathematical functions corresponding to a selected one of the plurality of image types, as indicated by the selection data, to generate a signal. The signal describes or defines the image in such a manner that it can be used to drive vehicle headlamp light array 170 to generate an output image. Those skilled in the art will readily understand the details of such signals, such as serial or parallel data signals describing a two-dimensional image, and how they can be used to drive the light array (either directly driving the array's pixels or instructing the light array controller to drive the pixels in a manner that results in the generation of the selected image type), and therefore will not be further described herein. By performing this local processing at the remote node, the need for high-bandwidth data transmission associated with transmitting large amounts of raw image data is reduced, thereby addressing the issue of expensive cables and connectors. Furthermore, very high refresh rates and very high-resolution images can be achieved, thereby addressing the issues associated with transmitting compressed image data from the CPU via the vehicle's communication infrastructure.

[0100] Figure 3 An example of frame data 320 that can be transmitted from the vehicle CPU 110 to the remote node 150 is shown. The frame data 320 includes compressed data 324, which is a compressed version of the original image data 310. In this example, the original image data 310 consists of 160 rows, each row containing 640 bytes. This data is compressed at a ratio of 10:1, compressing each 640-byte row to 64 bytes. However, any other size and compression ratio of the original data 310 can be used. The frame data 320 in this example also includes header data 322 and CRC data 326.

[0101] Selection data indicating the selected one of the plurality of image types may be included in the header data 322. The header data 322 may also optionally include mask information for overlay information.

[0102] Raw image data 310 may be a supplemental image to be overlaid onto the image projected by light array 170, such that compressed data 324 is a compressed version of the supplemental image. Examples of supplemental images include speed warnings, road signs, or other symbols that may be projected in the foreground, such as onto the road surface in front of the vehicle, so that the driver can see the supplemental image. In this example, the supplemental image is compressed, but depending on the size of raw data 310, the refresh rate of the system, and / or the bandwidth of the communication infrastructure, the supplemental image may not always need to be compressed. Even if the supplemental information is not compressed, the present invention is still advantageous because the projection of supplemental information is typically less frequent or less critical than the projection of low-beam and high-beam images. Furthermore, the size of the supplemental image raw data 310 is typically much smaller than the data required to describe the entire image to be projected by light array 170, so even without compression, there should be significant data transmission efficiencies. Furthermore, because raw data 310 is relatively small, a moderate compression ratio can be used, and even with lossless compression, the latency associated with compression and decompression can still be low enough for use in high-refresh-rate systems. Furthermore, since it generally defines non-critical image information, a fast lossy compression process can be used without any safety-critical risks.

[0103] The frame data 320 may optionally include CRC (cyclic redundancy check) data 326, which is used to ensure the integrity of the data transmitted from the vehicle CPU 110 to the remote node 150. As will be understood by those skilled in the art, the CRC data 326 allows the remote node 150 to verify that the data has been correctly received and has not been corrupted during transmission. This can improve the reliability and accuracy of the image projection of the vehicle headlight array 170, but is not required.

[0104] In some embodiments, the selection data indicating whether to project low beam or high beam is not always included in the frame data 320. Instead, the remote node 150 may sometimes receive only the overlay information without the selection data. This approach may allow the remote node 150 to update specific aspects of the projected image, such as a masked area or a supplemental image, without requiring each instance of the frame data to include all the information.

[0105] For example, in a scenario where frame data 320 is received at a frequency of 100 Hz, selection data may be included only in every other instance of frame data 320, causing it to be updated at a frequency of 50 Hz. In this case, remote node 150 would receive and apply the selection data at the first frame and then continue to use that data until new selection data is received. Alternative instances of frame data that do not include selection data may include overlay information, such as a mask region, so that the overlay information can also be updated at a frequency of 50 Hz. In this way, the total amount of information transmitted can be reduced while still achieving an acceptable refresh rate for both the selected predetermined image and the overlay image. By decoupling the reception frequency of different portions of frame data 320, the amount of data that needs to be transmitted can be reduced, thereby minimizing bandwidth usage and potential latency issues.

[0106] For example, if the vehicle's CPU 110 detects a new hazard on the road, it can send supplemental information to the remote node 150 without resending the low-beam or high-beam selection data. The remote node 150 can then apply the supplemental information to the projected high-beam or low-beam image, ensuring that the driver is alerted to the hazard without any significant delay. This approach allows the system to maintain a high refresh rate and responsiveness.

[0107] Figure 4 is a block diagram showing in more detail the communication between the vehicle CPU 110, the remote node 150, and the vehicle headlight array 170. Figure 1 and Figure 2 Same features.

[0108] In this example, the extract frame data function / circuit 220 can be understood as comprising a series of sub-functions / circuits: an extract header data function 420, a mask information function 440, a decompressed data function 450, and a supplemental information function 460. Again, it should be understood that the separation of functions / circuits is merely to simplify the explanation of the operation of the remote node 150, and that in practice, the different functions / circuits may be implemented within a single function / circuit, or may be subdivided in any other suitable manner (e.g., as two or more interconnected software programs or functions / routines).

[0109] The remote node 150 receives the frame data 320 from the vehicle CPU 110. The extract header data function / circuitry 420 is configured to extract header data 322 from the frame data 320. In this example, the header data 322 includes selection data and, optionally, mask information (described in more detail later). The selection data is processed by the math processing function / circuitry 230. The math processing function / circuitry 230 may be configured to use the selection data to select an appropriate mathematical function for the selected image type (e.g., each mathematical function may be stored in association with a particular selection data value, such that the math processing function / circuitry 230 can use the extracted selection data to retrieve the appropriate mathematical function) and use it to generate a signal describing the selected image type.

[0110] If the extracted header data also includes mask information, this can be processed by masking functionality / circuitry 440 to generate at least one mask region to be overlaid on the output image generated by the light array. A mask region is an area of ​​defined light intensity. In some examples, the defined light intensity has a different light intensity relative to the area of ​​the image it overlays. For example, a mask region can be an area of ​​no light intensity (e.g., an area where no light is to be emitted), or an area of ​​higher or lower light intensity compared to the area of ​​the image surrounding the mask region. This can be used, for example, to reduce or eliminate light projected toward oncoming vehicles and / or pedestrians, thereby achieving a relatively bright light output without endangering other road users.

[0111] The mask information may indicate mask coordinates and intensity values ​​for each of at least one mask area. The intensity value indicates the light intensity of the mask area, and may indicate a single uniform intensity level for the entire mask area, or may indicate a non-uniform light intensity, such as a gradient across the mask area. The mask coordinates of each mask area may indicate the size, shape and / or position of the mask area. In one example, each mask coordinate may include at least one pair of x, y coordinate values ​​for defining the size, shape and position of the mask area. For example, the mask coordinates of the mask area may include three pairs of x, y coordinates defining a triangular shape, or four pairs of x, y coordinates defining a rectangular shape, or five pairs of x, y coordinates defining a pentagonal shape, and so on. In some other examples, the mask coordinates of the mask area may include a single pair of x, y coordinates for defining the positions of the vertices of the mask area, and the remote node may be configured to generate a mask area of ​​a predetermined size and shape, with one of its vertices at the indicated x, y coordinates. Likewise, in some other examples, the mask coordinates of the mask region may include two pairs of x, y coordinates defining the positions of two vertices of the mask region, and the remote node may be configured to use those coordinates to generate the mask region. For example, the two pairs of coordinates may define two vertices at opposite corners of a rectangular mask region.

[0112] In one example, each pair of coordinate values ​​may contain 16 bits, and each intensity value may contain 8 bits. However, any other suitable number of bits may be used, depending on, for example, the size of the light array and / or the desired resolution of the mask region and / or the desired variety of light intensities in the mask region. The mask information may define any number of mask regions, for example, 1, 2, 10, 20, 25, 30, etc.

[0113] At the decompress data function 450, the compressed data 324 is decompressed before being processed by the supplemental information function / circuitry 460. If the supplemental information in the frame data 320 is not compressed (e.g., the original data 310 is transmitted in the frame data 320), then the decompress data function 450 is not required, and the supplemental information can be processed directly by the supplemental information function / circuitry 460 to generate a supplemental image for overlaying on the output image. The supplemental image can be customized by the CPU 110 to include information that may be useful to the driver of the vehicle or other drivers on the road, such as speed alerts or hazard warnings.

[0114] As a result of these processes, a signal may be output from the remote node 150 to the vehicle headlight array 170 to generate an output image. This signal will describe an output image corresponding to the selected predetermined image (e.g., low beam or high beam) with an overlay (e.g., mask region and / or supplemental image) applied on top.

[0115] It should be noted that, in general, the mask information and / or supplemental information may not be included in the frame data 320. Therefore, the output image may be generated solely based on the mathematical function indicated by the selection data, with or without the mask region and / or supplemental image. Similarly, the frame data 320 may sometimes include only the mask information and / or supplemental information without the selection data. In this case, the output image may be generated based on the mask information and / or supplemental information, with or without the selected predetermined image.

[0116] Figure 5 is a block diagram showing the projection of an output image with a masked area. Figure 5 A predetermined image type 510 is shown, which may be, for example, a low-beam image or a high-beam image generated using a mathematical function selected based on selection data received from the vehicle CPU 110 at the remote node 150. The predetermined image type 510 is overlaid with a mask region 520 (defined by mask information included in the frame data and generated by the mask function / circuit 440) to produce an output image 550. As can be seen, the output image 550 thus has a plurality of regions having defined intensities that may differ from the intensities of the regions in the predetermined image type 510 that it overlays.

[0117] Figure 6is a block diagram showing the projection of an output image with an overlaid supplemental image in the form of velocity information. Figure 5 Same features. Figure 6 In the example of FIG6 , speed information 630 as described by compressed data 324 is overlaid on the predetermined image type 510 to produce output image 650. Other types of information may be overlaid on the predetermined image type 510 instead of speed information, such as hazard warnings.

[0118] Figure 7 is a block diagram showing the projection of an output image with an overlay mask area and a supplemental image in the form of velocity information. Figure 5 and Figure 6 Same features. Figure 7 , the mask area 520 and the speed information 630 are overlaid on the predetermined image type 510 to generate an output image 750 including the predetermined image type 510 , the mask area 520 , and the speed information 630 .

[0119] Note that in the absence of mask information and supplementary information, the output image will be the same as the predetermined image type 510 .

[0120] Frame data 320 can be transmitted from CPU 110 to remote node 150 at the system's desired refresh rate. For example, new frame data 320 may be transmitted every 0.02 seconds in a 50 Hz system, or every 0.01 seconds in a 100 Hz system. Thus, the light projected from vehicle light array 170 can respond very quickly with minimal delay to changes, such as a driver- or vehicle-initiated change in the selected image type (such as from low beam to high beam, or vice versa), a change in obscuration information due to a newly detected moving vehicle, or a change in the supplemental information to be displayed. In one embodiment, each transmitted frame may include all required data. Alternatively, the system may be configured such that if no changes have been made to the supplemental image and / or mask region previously transmitted to remote node 150, data associated with the supplemental image and / or mask region is not retransmitted until a desired change occurs. For example, CPU 110 may transmit the same mask information and / or compressed data 324 only once, or only a predetermined number of times, after which it may omit the information from frame data 320. Subsequently, it may only begin to include mask information and / or compressed data 324 again when there is a change in the mask area and / or the supplemental image to be projected. In this case, the remote node 150 may be configured to cache the most recently received mask information and / or generated mask overlay information and / or compressed data 324 and / or generated overlay image, and continue to use the cached information until the mask information and / or compressed data 324 is again included in the frame data 320. Optionally, a similar operation may also be used for selection data indicating a selected one of a plurality of image types.

[0121] Figure 8 8 is a flow chart illustrating a method that may be performed by a processing unit, such as remote node 150. At step 810, the method includes receiving frame data, wherein the frame data includes selection data indicating a selected one of a plurality of image types. At step 820, the method includes using a mathematical function corresponding to the selected one of the plurality of image types to generate a signal that can be used by a light array to generate an output image. At step 830, the method includes outputting the signal to the light array.

[0122] Figure 9 is a flow chart illustrating a method executed at a processing unit, such as vehicle CPU 110. At step 910, the method includes generating frame data including selection data indicating a selected one of a plurality of image types. At step 920, the method includes sending the frame data to a remote node for generating a signal at the remote node that can be used by a light array to generate an output image.

[0123] The above-described functionality of the vehicle CPU 110 and the remote node 150 can each be implemented using any suitable hardware and / or software configuration to meet the specific requirements of the system. Each of the vehicle CPU 110 and the remote node 150 can typically include a microcontroller and / or microprocessor that can provide the necessary processing power to handle tasks such as generating frame data at the vehicle CPU 110 and processing the frame data at the remote node 150. Although the above-described system uses the vehicle CPU 110, the vehicle CPU 110 can alternatively be any other suitable type of processor / unit, such as a regional electronic control unit (ECU) responsible for controlling the operation of the vehicle headlight array 170.

[0124] The functionality of the vehicle CPU 110 and remote node 150 disclosed herein can be implemented in any suitable manner, for example using any suitable hardware and / or software. For example, it can be implemented using a computer program / software (such as on a computer-readable medium, which can be temporary or non-transitory) that contains instructions that, when executed on a processor, cause the processor to perform the processes described above. The computer program for performing the methods disclosed herein can be stored on any suitable temporary or non-transitory computer-readable medium. Thus, each of the vehicle CPU 110 and remote node 150 can include memory, such as volatile and / or non-volatile memory, to store the computer program, and a processor on which the computer program can be executed. Additionally or alternatively, the functions and circuits disclosed herein can be implemented using any suitable programmable logic or dedicated hardware circuits / components, such as an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA).

[0125] The present disclosure is not limited to the generation of vehicle headlight or low-beam and high-beam images. The technology disclosed herein can be applied to a wide range of lighting applications beyond the automotive sector. For example, the present invention can be used for stage lighting in theaters and concerts, or for advertising displays. In this case, the multiple predetermined image types can be any type of image that can be generated at remote node 150 using a mathematical function, and the overlay information can be used to generate any type of overlay image to be applied to the selected predetermined image.

[0126] The above embodiments are to be understood as illustrative examples. Further embodiments are contemplated. It will be understood that any feature described with respect to any aspect may be used alone or in combination with other described features, and may also be used in combination with one or more features of any other aspect or any combination of any other aspects. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the appended claims.

[0127] Appendix A: Example scripts for generating high-beam or low-beam image types

[0128] The following script is an example of a mathematical function that can be used to generate predetermined high-beam and low-beam images. The disclosed parameters are divided into two groups: one group, named 'Example High Beam,' is used to generate high-beam images, and the other group, named 'Example Low Beam,' is used to generate low-beam images. The mathematical function uses parameters from the parameter array of the selected image type to generate the corresponding image.

[0129]

[0130]

[0131] This sample script generates two images: one representing a high-beam headlight with the light source positioned high on the canvas, and another representing a low-beam headlight with the light source positioned low. The high-beam image displays a more concentrated and intense light pattern, suitable for illuminating long distances, while the low-beam image provides a wider and softer light pattern, ideal for close-range visibility without causing glare.

[0132] The mathematical functions used to generate a high-beam image or a low-beam image are encapsulated in a 'create_light_source' function. This function calculates the light intensity using an exponential decay formula based on the distance from the light source. Selection data provided by the vehicle CPU to the remote node may indicate which predetermined parameters to use. For example, the selection data may specify whether to use high-beam parameters (as shown in the parameter array under the heading 'Example High Beam') or low-beam parameters (as shown in the parameter array under the heading 'Example Low Beam'). Both sets of parameters may be stored in a memory accessible to the remote node (e.g., which may be stored as part of the remote node computer program), and the selected parameters may then be used in the 'create_light_source' function to generate the corresponding high-beam or low-beam light pattern.

[0133] In this example, the parameters in each of the high beam parameter array and the low beam parameter array begin by defining the canvas size and the position of the light source. These initial parameters set the environment in which the light pattern will be generated.

[0134] The canvas size defines the dimensions of the image frame. This size can be adjusted based on the desired resolution of the light pattern. For example, a larger canvas size (such as '[1280,320]') can be used for a higher-resolution image, providing more detail and smoother gradients in the light pattern.

[0135] Light Position specifies the x and y coordinates of the light source. In the script, the high-beam light source is positioned higher on the canvas at '[480,40]', while the low-beam light source is positioned lower at '[480,120]'. This variation on the y-axis simulates the different beam patterns used for high and low beams. High beams are designed to illuminate farther ahead and are therefore positioned higher, while low beams are aimed lower to avoid dazzling oncoming drivers.

[0136] It should be noted that in this coordinate system, the origin (0,0) is at the top-left corner of the canvas. This means that moving the canvas downward increases the y-coordinate value, making it positive. Thus, a y-coordinate of '40' places the light source closer to the top of the canvas, simulating high beams, while a y-coordinate of '120' places the light source closer to the bottom, simulating low beams.

[0137] The light position is typically off-center to ensure the light pattern doesn't dazzle oncoming drivers. The x-axis variation in the light source's positioning toward the right simulates the typical alignment of vehicle headlights, which are typically tilted slightly to the right (in countries with right-hand-drive traffic) to avoid dazzling oncoming traffic. The exact positioning and angle may vary depending on the laws and regulations of different countries. For example, in countries with left-hand-drive traffic, the light source might be positioned toward the left to achieve the same effect.

[0138] The horizontal and vertical falloff parameters control how quickly the light intensity decreases horizontally and vertically. These values ​​can be modified to achieve different light diffusion effects. For example, a horizontal falloff of 0.001 and a vertical falloff of 0.01 produce a wider, less intense light spread. The falloff parameter determines how the light decays with distance from the light source. An exponential falloff function results in a smooth decrease in light intensity, creating a natural-looking light pattern. By adjusting these parameters, the system can simulate a variety of lighting conditions and beam patterns.

[0139] The script uses nested loops to iterate over each pixel in the canvas, calculating the distance from the light source and applying an exponential decay to determine the pixel's brightness. This method results in a smooth decrease in light intensity, creating a natural-looking light pattern. Using an exponential decay function is particularly effective for simulating light that gradually dims as it moves away from its source.

[0140] This script is provided as an example only, and different parameters can be used to achieve a variety of light patterns. Additionally or alternatively, different mathematical functions can be used to generate low-beam or high-beam images, depending on the specific requirements and design of the vehicle's headlight system. Furthermore, different functions and / or parameters can be used to generate predetermined image types other than low-beam and high-beam images, such as when the disclosed technology is used in non-automotive applications, such as stage lighting.

Claims

1. A remote node for controlling a vehicle headlight array, the remote node comprising: a memory configured to store a plurality of mathematical functions for generating a corresponding plurality of predetermined image types, wherein the plurality of image types includes at least a low-beam image and a high-beam image; a receiving interface configured to receive frame data, wherein the frame data includes selection data indicating a selected one of the plurality of image types; a rendering engine configured to use a mathematical function of the plurality of mathematical functions corresponding to the selected one of the plurality of image types to generate a signal usable by the vehicle headlamp light array to generate an output image; as well as An output interface is configured to output the signal to the vehicle headlamp array.

2. The remote node of claim 1 , wherein the frame datagram includes overlay information for generating an overlay to be applied to the selected one of the plurality of image types, wherein the rendering engine is configured to further use the overlay information to generate the signal.

3. The remote node of claim 2, wherein the overlay information includes mask information for generating at least one mask area included in the overlay.

4. The remote node of claim 3, wherein each at least one mask area has a defined light intensity. 5 . The remote node of claim 3 , wherein the mask information indicates at least one mask coordinate and an intensity value of each at least one mask region.

6. The remote node of claim 2, wherein the overlay information comprises supplemental information including a supplemental image in the overlay.

7. The remote node of claim 6, wherein the supplemental information comprises a compressed version of the supplemental image, and the rendering engine is configured to generate the supplemental image using the supplemental information.

8. The remote node of claim 1, wherein the plurality of mathematical functions are received from a processing unit.

9. The remote node of claim 1, wherein the frame data further comprises parameter changes to the mathematical function.

10. A processing unit for controlling a vehicle headlamp array, comprising: a processing unit configured to generate frame data including selection data indicating a selected one of a plurality of image types, wherein the plurality of image types include at least a low-beam image and a high-beam image; and A transmission interface is configured to send the frame data to a remote node for generating a signal at the remote node that can be used by the vehicle headlamp array to generate an output image.

11. The processing unit of claim 10, wherein the frame datagram contains overlay information for generating an overlay to be applied to the selected one of the plurality of image types.

12. The processing unit of claim 11, wherein the overlay information includes mask information for generating at least one mask region included in the overlay.

13. The processing unit of claim 12, wherein each at least one mask region has a defined light intensity. The processing unit of claim 12 , wherein the mask information indicates at least one mask coordinate and an intensity value of each at least one mask region.

15. The processing unit of claim 11, wherein the overlay information comprises supplemental information included in the overlay. The processing unit of claim 15 , wherein the supplemental information is compressed.

17. A method for controlling a vehicle headlamp array using a remote node, comprising: receiving frame data, wherein the frame data includes selection data indicating a selected one of a plurality of image types, wherein the plurality of image types include at least a low beam image and a high beam image; using a mathematical function corresponding to the selected one of the plurality of image types to generate a signal usable by the vehicle headlamp light array to generate an output image; and The signal is output to the vehicle headlamp array.

18. The method of claim 17, wherein the frame datagram includes overlay information for generating an overlay to be applied to the selected one of the plurality of image types, wherein the remote note is configured to further use the overlay information to generate the signal.

19. The method of claim 18, wherein the overlay information includes mask information for generating at least one mask region included in the overlay.

20. The method of claim 17, wherein the overlay information comprises supplemental information included in the overlay.

Images