Rendering device

[0002] 1. Field of the Invention

[0003] The present invention relates to rendering devices and, more specifically, to a rendering device which can be incorporated in a drive assistant device. In more detail, the rendering device generates a display image of around a vehicle based on an image captured by an image capture devices fixedly placed in the vehicle.

[0004] 2. Description of the Background Art

[0005] A conventional drive assistant system is exemplarily disclosed in Japanese Patent Laid-Open Publication No. 64-14700 (1989-14700). The drive assistant system is provided with a rudder angle sensor placed in a vehicle for detecting a rudder angle of the steering wheel; a processor for deriving, based on the rudder angle of the steering wheel, a path estimated for the vehicle to take; an image capture device in charge of an area rear, or right and left-side rear of the vehicle; and a display device for displaying a display image. In such drive assistant system, when the vehicle starts moving backward, the display device displays an image captured by the image capture device to show the driver in what state the area behind the vehicle is. When the steering wheel is turned, a path estimated for the vehicle to take is overlaid on the same image. Here, the estimated path is derived based on the rudder angle of the steering wheel. With the help of such image provided by the drive assistant device, the driver can know whether his/her current steering will fit the vehicle into the parking space.

[0006] There is another type of conventional drive assistant device exemplarily disclosed in Japanese Patent Laid-Open Publication No. 11-78692 (99-78692). The drive assistant device carries a plurality of image capture devices, and merges plural images captured thereby to generate a display image. For higher speed image merging, every pixel in each of those captured images is mapped to a road surface whereon the vehicle moves. Then, the road surface is viewed from a predetermined virtual viewpoint, and the resulting display image covers the area around the vehicle. In this case, any object observed around the vehicle is projected on the road surface without any height component.

[0007] The above conventional type drive assistant devices carry problems as follows.

[0008] First, such drive assistant devices are not helpful enough if the parking lot has no marking as white lines defining an individual parking space. The driver thus finds it difficult to exactly figure out where to park in such parking lot.

[0009] Second, especially in the conventional drive assistant device of a type merging a plurality of images and generating a display image, no concern is given to the height components of objects appearing in the captured images. As a result, objects in the resulting display image look deformed. It means, assuming that the driver wants to park his/her vehicle between two vehicles positioned behind, as shown in FIG. 7, the resulting display image shows the driver two deformed two vehicles. The driver thus has a hard time to precisely recognize a space between those two vehicle available for his/her vehicle, for example. In such case, an estimated path L is of little help. In other words, with the conventional drive assistant devices, the driver finds it difficult to decide if his/her vehicle fits in the parking space without hitting anything.

[0010] Therefore, an object of the present invention is to provide a rendering device, a display image generated thereby being supportive enough for a driver of the vehicle to figure out a parking space available for his/her vehicle. Another object of the present invention is to provide a rendering device, a display image generated thereby being indicative and helpful enough for the driver to decide whether his/her vehicle fits into the parking space without hitting anything.

[0011] The present invention has the following features to attain the objects above.

[0012] An aspect of the present invention is directed to a rendering device for generating a display image of around a vehicle for drive assistance, and the device comprises a vehicle model storage part for storing a vehicle model representing the vehicle; a path calculating part for calculating an estimated path for the vehicle based on a rudder angle of the vehicle provided by a rudder angle detecting part placed in the vehicle; a receiving part for receiving a captured image of around the vehicle from an image capturing part placed in the vehicle; and an image processing part for generating the display image based on the captured image, the estimated path, and the vehicle model. The display image generated by the image processing part is displayed by a display part placed in the vehicle, and includes the vehicle model arranged on the estimated path.

[0013] These and other objects, features, aspects and advantages of the present invention will become more apparent from the following detailed description of the present invention when taken in conjunction with the accompanying drawings.

[0014] FIG. 1 is a block diagram showing the hardware structure of a drive assistant device according to one embodiment of the present invention;

[0015] FIG. 2 is a flowchart showing the procedure for a CPU 6 of FIG. 1 to process;

[0016] FIG. 3 is a flowchart showing the procedure to calculate a display position of a vehicle model (display vehicle position) in the embodiment;

[0017] FIG. 4 is a flowchart showing the procedure to generate a vehicle overlaid image in the embodiment;

[0018] FIGS. 5aand 5bare diagrams showing one example of a display image displayed on a display device 8 of FIG. 1 without and with a vehicle model image thereon respectively.

[0019] FIG. 6 is a diagram for illustrating the display vehicle position set in step S110 in FIG. 3; and

[0020] FIG. 7 is a diagram showing a display image in a conventional drive assistant device.

[0021] By referring to the accompanying drawings, one embodiment of the present invention is described below.

[0022] FIG. 1 is a block diagram showing the hardware structure of a drive assistant system 100 according to the embodiment of the present invention. The drive assistant system 100 includes an input device 1, N (where N is a natural number equal to 1 or larger) cameras 2₁to 2_Na rudder angle sensor 3, a rendering device 10, and a display device 8. The rendering device 10 here includes ROM 4, RAM 5, and a CPU 6.

[0023] The input device 1 is found in a position where a driver of the vehicle is easy to operate, and composed of a remote controller, a touch panel, an operation button, and the like.

[0024] The cameras 2₁to 2_Nare fixedly placed in each different predetermined position in the vehicle, and have charge of capturing images of around the vehicle. The cameras 2₁to 2_Nare each assigned an identification value, and identified thereby. For convenience, the identification values in this embodiment are the numerical subscripts accompanying the reference numeral 2 of the cameras.

[0025] The rudder angle sensor 3 is also placed in a predetermined position in the vehicle, and detects the rudder angle of the steering wheel.

[0026] The CPU 6 runs following a program in the ROM 4, and thereby functions as path calculating means and image processing means, and generates a display image (these expressions appear in Claims). During this execution, the RAM 5 is used as a working area for the CPU 6. In the RAM 5, a region (hereinafter, referred to as a frame buffer) is reserved for each of the cameras 2₁to 2_Nfor storing a frame of the images captured thereby. In the RAM 5, frame memory is also reserved as a region wherein the display image is generated by the CPU 6.

[0027] The ROM 4 stores data representing a three-dimensional model of the vehicle. Here, the vehicle model is equivalent in size to the actual vehicle. To make sure that the vehicle does not hit any other vehicle in a close range, for example, the vehicle model may be somewhat bigger than the actual vehicle.

[0028] The display device 8 is typically a liquid crystal display, and displays the display image generated by the CPU 6.

[0029] Such structured system 100 is typically found useful by the driver when he/she moves the vehicle backward to park between other vehicles behind. When needing the assistant offerable by the present system 100, the driver operates the input device 1.

[0030] In response to the driver's operation, the input device 1 instructs the CPU 6 to execute the program. The CPU 6 then starts going through such procedure as shown in FIG. 2 in accordance with the program in the ROM 4.

[0031] To go through the procedure of FIG. 2, the CPU 6 needs any image of around the vehicle, specifically any image covering the area rear of the vehicle. Thus, the CPU 6 instructs at least one corresponding camera 2_i(where i=1, 2, . . . N) to capture an image (step S10). The camera 2_ithen responsively captures a frame of an image of around the vehicle, and then transfers the captured image to the RAM 5. Here, presumably, the N cameras 2₁to 2_Neach receive such instruction, and transfer an image captured thereby to the frame buffer reserved therefor.

[0032] After instructing the cameras as such, the CPU 6 runs as follows concurrently with the cameras' image capturing.

[0033] First, to estimate a path for the vehicle to take, the CPU 6 instructs the rudder angle sensor 3 to detect to what degree the steering wheel is now turned (step S12). The rudder angle sensor 3 accordingly detects the current rudder angle of the steering wheel, and transmits the detected result to the CPU 6.

[0034] Next, based on the result received from the rudder angle sensor 3, the CPU 6 calculates an estimated path L, which is typically traced on a road surface for the vehicle to take (step S14).

[0035] In the present embodiment, the drive assistant system 100 displays in a display image a vehicle model fully placed on the estimated path L. This is aimed to help the driver easily figure out any possible bump against vehicles and other objects if he/she keeps moving his/her vehicle with the current rudder angle on the estimated path L. In the display image, the vehicle model is displayed as if moving toward the parking space by degrees on the estimated path L (see FIG. 6). Here, the vehicle model keeps moving by a predetermined quantity (hereinafter, referred to as a movement unit). When the movement quantity of the vehicle model reaches its predetermined maximum value, the vehicle model returns to its predetermined initial position. For realization of such display, the CPU 6 carries out image processing of step S15 after step S14 is through. In the image processing, the CPU 6 first goes through such calculation procedure as shown in FIG. 3 to determine where to display the vehicle model on the estimated path L in the display image (step S16). Such position is hereinafter referred to as a display vehicle position.

[0036] Prior to describing the calculation procedure by referring to FIG. 3, terms to be mentioned below are described. First, a “display distance” denotes a distance (equivalent to a distance in the actual space) covered by the vehicle model on the estimated path L in the display image. The display distance is set to an initial distance first. Here, the “initial distance” denotes a first display position of the vehicle model. The initial distance is typically set to an appropriate value as are the movement unit and the maximum distance during when the drive assistant system 100 is manufactured. Here, the movement unit is exemplarily set to 0.5 m, and the maximum distance to 3 m. Those values are preferably resettable depending on the drivers' preferences.

[0037] When the procedure reaches step S16 of FIG. 2, the CPU 6 starts going through the calculation procedure of FIG. 3. First, the CPU 6 fetches the initial distance if this step is through for the first time, and if not, fetched is the display distance previously calculated in the same step (step S100). Thus fetched display distance is referred to as a previous display distance. Then, the previous display distance is added with the movement unit, and the resulting value is the current display distance (step S102). Then, the current display distance is determined whether or not exceeding the maximum value predetermined therefor (step S104). If exceeded, the current display distance is set to the initial distance (step S106), and then the procedure goes to step S108. If not yet exceeding, the procedure skips step S106, and goes to step S108. In step S108, the estimated path L calculated in step S14 is partially picked up for the length equivalent to the current display distance from the current position of the vehicle model. Here, such picked-up part of the estimated path L is referred to as a partial estimated path. As such, the display distance tells on which part of the estimated path L the vehicle model is now positioned (i.e., where the partial estimated path ends), and there, to which direction the estimated path L is directed (step S110) (see FIG. 6). Here, such position and direction of the vehicle model are equivalent to those in the actual space, and collectively referred to as vehicle information. Then, the current display distance is stored in the RAM 5 to be prepared for step S110 in the next calculation procedure (step S112).

[0038] After step S112 is through, the CPU 6 goes through such generation procedure as shown in FIG. 4 based on the vehicle information set in step S110 (step S18 in FIG. 2). An image generated thereby has the vehicle model overlaid thereon, and referred to as a vehicle merged image.

[0039] Specifically, the CPU 6 calculates a region to be occupied in the display image by the vehicle model, which is defined by position and direction according to the vehicle information set in step S110. Here, the region is equivalent to a region in the actual space (step S200). Then, the CPU 6 initializes to “1” a variable j specifying the identification values assigned to the cameras (step S202), and then sees if thus specified camera 2_jcatches, presumably, a sight of the vehicle model occupying the region as calculated above (step S204). If determined No, the variable j is incremented by 1, and step S204 is repeated with the newly specified camera 2_j. If the determination thereby becomes Yes, the vehicle model viewed from the camera 2_jis generated as a vehicle model image (step S206).

[0040] Next, the CPU 6 waits for the image captured by the camera 2_jto receive (step S208). By the time when the CPU 6 receives the image, the frame buffer in the RAM 5 for the camera 2_i(hereinafter, referred to as a target frame buffer) stores the same image. Thus, onto the image stored in the target frame buffer, the CPU 6 overlays the vehicle model image generated in step S206, and generates a frame of the vehicle merged image (step S210). Thereafter, the CPU 6 determines whether j>=N is satisfied, that is, whether all of the cameras 2₁to 2_Nare subjected to the processing of step S204 (step S212). If j is determined as not yet being equal to N, the variable j is incremented by 1, and the procedure returns to step S204.

[0041] The processing of step S204 is repeatedly carried out to the remaining cameras until the variable j becomes equal to N (j=N). The CPU 6 then determines that the process of generating the vehicle overlaid image is now completed, and the procedure goes to step S20 in FIG. 2.

[0042] At this point in time, the frame buffers in the RAM 5 respectively reserved for the cameras 2₁to 2_Nstore either the vehicle overlaid image or the captured image. With respect to those images, the CPU 6 performs viewpoint conversion processing on the above-described frame memory according to a predetermined mapping table (step S20). The resulting image generated thereby is a viewpoint converted image, which shows the area around the vehicle viewed from a predetermined virtual viewpoint. Here, the virtual viewpoint is so selected as to make the resulting image viewed therefrom indicative enough for the driver to figure out in what state the area around the vehicle and the parking space is. The virtual viewpoint here is different from those for the cameras 2₁to 2_N, and suitably selected to help the driver grasp the surrounding state between the vehicle and the parking space. Preferably, the virtual viewpoint is set proximal to the roof of the vehicle or up higher.

[0043] Here, as mentioned in the above, at least one frame buffer includes the vehicle overlaid image. Thus, the viewpoint converted image includes the vehicle model image viewed from the virtual viewpoint. In the present embodiment, as is conventionally done, every pixel in each of the images in the frame buffers (vehicle overlaid image and captured image) is mapped to a road surface whereon the vehicle moves, and the road surface is viewed from the virtual viewpoint to generate an image. Thus, any object observed in the resulting viewpoint converted image is neglected with its height component, and resultantly looks deformed. Here, the object includes other vehicle in a close range, the vehicle model itself, obstacle, and the like.

[0044] Then, the CPU 6 overlays the estimated path L calculated in step S14 onto the viewpoint converted image, and the display image is generated (step S22). The CPU 6 then transfers thus generated display image to the display device 8 for display thereon (step S24). As shown in FIG. 5B, the display image includes a vehicle model Imd located on the estimated path L. The vehicle model Imd moves backward on the estimated path L by the movement unit by repeating the processing in FIG. 2, and when the display distance reaches its predetermined value, returns to the initial distance.

[0045] As described in the foregoing, according to the present embodiment, a display image shows a vehicle model on a path estimated for the vehicle together with an area rear of the vehicle. With the help of such display image, a driver of the vehicle can exactly aim at a parking space available for his/her vehicle on estimated path. Also, the driver can precisely figure out if his/her vehicle can fit in the parking space. Here, in the display image, the vehicle model Imd is displayed as if moving backward on the estimated path L. Therefore, the driver can easily figure out only by seeing the display image whether or not the vehicle model Imd moving on the estimated path L hits any obstacle typified by other vehicle in a close range.

[0046] As described in the foregoing, if a viewpoint converted image is generated in the conventional manner, any object observed therein looks deformed as its height component is neglected. On the other hand, according to the present embodiment, even if any object such as other vehicle and obstacle appearing in the display image is deformed due to a merging map, the vehicle model also looks deformed. This is because, with the procedure of FIG. 4, a viewpoint converted image is generated based on a vehicle overlaid image which is generated by overlaying an image of the vehicle model viewed from the specified camera. As every object in the display image including the vehicle model itself is deformed, the driver can correctly figure out any possible bump against obstacles therearound. If the vehicle model is not deformed as other objects in the display image, the driver finds it difficult to measure an exact space between the vehicle model and the deformed obstacle.

[0047] Further, there is no more need for marking such as white lines defining an individual parking space. This is because, with the help of the display image showing the vehicle model moving on the estimated path L, the driver now can figure out whether his/her vehicle hits anything before fitting in the parking space.

[0048] Note that, in the above embodiment, the display image shows the vehicle model for the purpose of helping the driver to park. In some parking lots, however, an individual parking space is defined in a specific pattern (usually in a rectangular pattern) by white lines, for example. If so, the white lines are sufficient for the driver to recognize any available parking space, and thus the vehicle model is not considered essential in the display image, and only the estimated path will do. In such case, the CPU 6 may detect whether the specific pattern as above is observed in an area for where the vehicle is heading, and if detected, the vehicle model may not be displayed. Here, the detection technique as such is well known in this field. Also, not to display the vehicle model in the display image, step S210 of FIG. 4 may be skipped.

[0049] As described in the foregoing, to make sure that the vehicle does not hit any other vehicle in a close range, for example, the vehicle model may be set somewhat bigger than the actual vehicle.

[0050] Further, in the above, the vehicle is presumed to move backward to park. This is not restrictive, and the assistant device of the present invention is surely applicable to a case where the vehicle moves forward to park.

[0051] In the above embodiment, the program is stored in the ROM 5. This is not restrictive, and the program may be distributed in a recording medium typified by CD-ROM, or over a communications network such as the Internet.

[0052] Further, if the vehicle model is simply overlaid as in step S210, the vehicle model may partially hide the area ahead or rear of the vehicle in the display image. Therefore, the vehicle model may be translucent or wire-framed. In this manner, the display image generated by the rendering device 10 has no blind spot, and the drive thus can check the area front or rear of the vehicle to a greater degree. Especially in the case that the vehicle model is wire-framed, computation load can be reduced compared with the case where the vehicle image is simply rendered.

[0053] While the invention has been described in detail, the foregoing description is in all aspects illustrative and not restrictive. It is understood that numerous other modifications and variations can be devised without departing from the scope of the invention.