Speed ​​monitoring

Abstract

A computer-implemented method for assisting a human operator in manually adjusting a vehicle's speed. The method includes receiving live data related to the vehicle's current speed, applying logic to input data including the live data, and sending a signal. The signal is sent to the human operator based on the logic. The signal is at least one of quantifying the vehicle's future speed and indicating that the future speed exceeds a threshold.

Description

[Technical Field]

[0001] Some aspects of the present invention relate to assisting a human operator who is responsible for manually adjusting the speed of a vehicle, while other aspects may be advantageously utilized for other purposes.

[0002] The present invention will be described solely with reference to road vehicles, and other variations of the techniques disclosed herein may be usefully applied in other environments, for example rail vehicles and / or marine environments. [Background technology]

[0003] When operating a heavy road vehicle, it is important to select the appropriate speed and appropriate operator input when initiating a descent, e.g., at the top. It is good practice to reduce speed, shift into a lower gear, and apply engine braking when approaching a descent. When performed properly, the vehicle will maintain a controlled speed without over-revving the engine or using the foot brake. The inventors have recognized that slight deviations from this ideal practice at the start of a descent can result in significant overspeeding at the bottom of the descent.

[0004] With the above in mind, the present invention aims to assist the human operator in the role of regulating the speed of the vehicle.

[0005] None of the information in this patent specification is admitted to be common general knowledge or that a person skilled in the art could reasonably be expected to ascertain or understand it, consider it relevant, or combine it in any way prior to the priority date. Summary of the Invention

[0006] One aspect of the present invention is a computer-implemented method for assisting a human operator in manually adjusting a speed of a vehicle, the method comprising: receiving live data relating to a current speed of the vehicle; applying logic to input data, including live data; Based on logic, a human operator Quantifying the future speed of the vehicle; and and indicating that the future velocity will exceed a threshold.

[0007] Preferably, the live data relates to the current acceleration of the vehicle. More preferably, the logic assumes that there are no significant changes in commands to the engine, transmission, or brakes.

[0008] Optionally, the input data characterizes the path ahead of the vehicle, for example the input data may include an elevation profile. The input data may characterize the vehicle, for example the weight of the vehicle.

[0009] Preferably, the method may include formulating logic based on the live data and the elevation profile. Preferably, the formulating includes giving relatively less weight to clear changes in the live data that are indicative of operator input. It may include giving relatively less weight to older data. Optionally, the formulating includes estimating a mass parameter.

[0010] The future velocity may be the velocity at a selected fixed point ahead of the vehicle, for example the fixed point may be at the bottom of a hill. Optionally, the future velocity may be the maximum velocity within a window of interest ahead of the vehicle.

[0011] Preferably, the live data comprises GPS data.

[0012] In an embodiment, sending the signal includes sending an on-board device signal. The computer may be a smartphone. Optionally, sending the signal includes sending a stationary device signal. The method may include one or more stationary speed detectors collecting live data.

[0013] Another aspect of the invention provides a computer configured to perform the method.

[0014] Another aspect of the present invention is a vehicle speed monitoring system comprising: one or more stationary speed detectors that collect live data related to the current speed of the vehicle; a computer configured to apply logic to input data including live data; Based on the logic, a human operator Quantifying the future speed of the vehicle; and and a stationary signaling device for signaling at least one of: indicating that the future speed will exceed a threshold.

[0015] Preferably, the live data relates to the current acceleration of the vehicle. Most preferably, one or more stationary speed detectors and stationary signalling devices are positioned before the end of the downhill section.

[0016] Another aspect of the present invention provides a method of estimating one or more vehicle parameters that includes correlating speed data with elevation profile data. [Brief explanation of the drawings]

[0017] [Figure 1] 1 is a graph showing an elevation profile. [Figure 2] FIG. 1 is a front view of a smartphone. [Figure 3] 1 shows a schematic representation of a fixed driver aid device; DETAILED DESCRIPTION OF THE INVENTION

[0018] (Description of the embodiment) Certain variations of the technology disclosed herein provide a future speed signal to a human operator, thereby increasing the likelihood that the operator will be warned in advance and take corrective action in a timely manner.

[0019] The signaling can take any convenient form, such as a warning light, a warning buzzer, or a tactile device similar to a stick shaker that alerts the pilot to an impending stall.

[0020] Preferably, the future speed signal quantifies the future speed. This can take the form of a series of progressively illuminating lights, an audio signal that varies in frequency and / or intensity, or similarly varying haptic feedback. Visual outputs are preferred, particularly outputs that resemble traditional analog or digital speedometers. This method provides the operator with output in a familiar format. In some variations, the operator can monitor changes in response to driving inputs.

[0021] While sophisticated warning devices that are tightly coupled with the vehicle's electronics and take into account a wide range of input parameters are possible, a simple implementation that can be deployed cheaply and provides immediate benefits to existing vehicle operators is preferred.

[0022] In a preferred embodiment, a computer in the form of a smartphone 1 (eg, an iPhone™) configured (eg, by an app) to implement the method is required.

[0023] The app acquires traditional GPS data that characterizes the vehicle's location at a specific point in time. Based on a series of these data points, the app can estimate the vehicle's speed and acceleration. Preferred smartphone variants employ these data points as their only live data source, allowing the app to provide useful feedback without connecting to the vehicle's OBD2 (on-board diagnostics) portal or other vehicle electronics.

[0024] The app may store and / or process GPS data for associated entries of latitude, longitude, and time. Entries may be taken at any convenient interval, such as at intervals of a predefined distance or at intervals of a predefined time. The intervals may be shorter at selected locations, such as at the start of a downhill slope. Other options for collecting live data exist. Some variations may process images and / or inputs from other sensors, for example, utilizing a camera and / or accelerometer built into the smartphone.

[0025] While sensors external to the smartphone may be used (and in fact variations of the system may incorporate devices other than a smartphone), preferably the live data is obtained independently of data provided by the vehicle itself. For example, even if the smartphone is connected to an external accelerometer and both are powered from the vehicle's 12-volt socket, it is preferable that the device not obtain a data signal from the vehicle. Such standalone devices are preferred because they can be easily deployed across a wider range of vehicles, including older vehicles that do not have the sophisticated electronics found in newer vehicles. In fact, older vehicles often have poorer braking capabilities, and therefore drivers of such vehicles would benefit more from a future speed signal. The app may also convey information characterizing the route ahead for the vehicle, which may be stored on the phone or downloaded via the communications system while the vehicle is in motion.

[0026] In a preferred variation of this concept, this route information takes the form of a series of data points that constitute an elevation profile, and by applying logic to the live data and route data, future speeds can be estimated and displayed to the operator. For the avoidance of doubt, "live data" and similar terms as used herein refer to data that changes while the vehicle is in motion. A typical elevation profile is not "live data," even if the profile is communicated to the vehicle via a communications system while the vehicle is in motion.

[0027] Figure 1 shows a heavy-duty hybrid vehicle approaching a downhill slope. The app can be preconfigured to display future speeds upon approaching a downhill slope (or for other reasons via operator input). For example, prior to a downhill slope, the operator may be cruising at 100 kilometers per hour (100 kph) with constant throttle input. As the prediction window moves to reflect the downhill slope, the app flashes a warning light and displays a predicted overspeed ahead, prompting the operator to modify those inputs. A similarly configured system would function similarly if the driver were traveling at 100 kph using cruise control. The future speed signal would similarly indicate an overspeed, thereby prompting a prompt response. According to a preferred variation of this technology, the logic assumes no commanded changes in engine or braking performance, such as no change in accelerator position, no change in brake pressure, and no change in engine braking state.

[0028] Thus, future speed is an estimate that is likely to be inaccurate because it assumes parameters (such as throttle position) do not change, while the estimation intends for those parameters to change. A preferred variation of the system provides continuously changing operator feedback that allows the operator to adjust their input. Continuing with the previous example, if an operator applying a constant throttle input at 100 kilometers per hour sees signs of overspeeding, the operator responds by releasing the throttle, downshifting gears, and applying engine braking, and the smartphone detects the change in speed and acceleration and adjusts its estimate of future speed accordingly.

[0029] In this example, the app is configured to display two future speeds, corresponding to a maximum downhill speed and a speed at the bottom of the downhill slope. It can be seen that the road continues downward after the "bottom." Following normal terminology in the field, the bottom of the hill simply refers to the point where the downward slope eases to the point where a coasting vehicle would slow down to a speed well below cruising speed.

[0030] This advance warning allows the operator of the heavy vehicle hybrid vehicle to adjust their inputs early, such as potentially downshifting gears. In this example, the operator can adjust the V Max and V Bottom can downshift to 105 km / h and 97 km / h respectively.

[0031] Preferably, the future speed signal quantifies the future speed, although in other variations, the signal may be conveyed as an instruction to the operator. As an example, a basic form of the system may provide a binary future speed signal (e.g., a simple warning light or warning buzzer) that indicates that the future speed exceeds a threshold and also constitutes an instruction for more net delay (e.g., reduce the throttle and / or brake harder and / or downshift further). An indication of future speeding and an instruction to avoid future speeding are different ways of saying the same thing; in other words, they are two sides of the same coin. A preferred variation provides an indication of the magnitude of deviation from a target or threshold speed; in this context, the magnitude of the excess speed is equivalent to an indication that significant additional braking (or other delay) is required.

[0032] Another advantageous version of the future speed signal would provide an indication of the amount of delay required or how to achieve it (such as suggesting gear selection and engine braking status), or indicate the magnitude of change in delay input required to avoid exceeding a threshold speed. An advantageous implementation would include a smartphone displaying an analog dial indicating the amount of delay required, with the dial including a needle that can sweep from one end indicating a high amount of additional delay is required, through an "on target" center mark, to a sweeping end indicating a much lesser amount of delay.

[0033] In this way, the driver can downshift gears until the needle indicates the required degree of retardation has been achieved. When the needle of such a device is on the "more retardation" side of the "on target" mark, it indicates that the future speed will exceed the threshold. When the needle swings hard into the "less retardation" end of the sweep, the operator knows it is safe to shift up a gear or disengage engine braking.

[0034] Other route information besides elevation profiles can also be useful. For example, the app can calculate V as a function of speed, position, and acceleration. Bottom A transfer function (e.g., a polynomial transfer function) that provides an estimate of may be stored. The form and parameters of this transfer function determine the characteristics of the route. The transfer function may be updated after repeated trips. In a networked variant of the system, general transfer functions for different road lengths may be determined algorithmically from different users, and each user (or vehicle) may have their own transfer function that modifies the general transfer function.

[0035] In some variations of the app, other input data may also be considered. As an example, the app may provide an interface screen where the operator can input vehicle parameters such as vehicle weight, drag, and / or rolling resistance. Wind speed may be obtained from an external database. In one implementation, the app may be configured for semi-trailer combinations and allow the driver to provide resistance information simply by selecting from a series of icons representing tow vehicles without trailers and tow vehicles with various trailer types (e.g., empty flattops, flattops loaded to the prime mover's roof, or enclosed trailers of a specific height). The app may store a database associating selected combinations with predetermined drag and / or rolling resistance parameters.

[0036] A preferred variation of the app applies a transfer function to estimate future speed based on current speed, acceleration, and elevation profile. Vehicle parameters entered by a human operator can help refine this transfer function. However, the inventors recognized that this leaves room for human error. Therefore, some variations validate and / or update the transfer function based on live data.

[0037] In one implementation, the app may prompt the operator to provide specific inputs to provide calibration data. As an example, the operator may be prompted to coast in neutral for one or more periods. Coasting in neutral on different grades (e.g., two different grades, each for a 5-second period) informs the transfer function, allowing weight, drag, and rolling resistance to be estimated separately.

[0038] The logic may include a predetermined model that includes mass, drag, and rolling resistance parameters.

[0039] The wording used here is as follows: -The parameter that relates the acceleration correlated with the gradient is the mass parameter. -The parameter that relates the deceleration correlated with the square of the velocity to the square of the velocity is the drag parameter. - The parameter that corresponds to deceleration, independent of speed, is the rolling resistance parameter.

[0040] Other models may ignore rolling resistance. Machine learning algorithms are also possible that select the model autonomously.

[0041] Optionally, when the app is first launched, it may simply say that calibration has not yet occurred, and may prompt to calibrate, for example by displaying a "not ready" message on the screen. Optionally, the calibration prompt may be displayed based on details of the road ahead, for example uphill sections and separate downhill sections may be selected to allow for more accurate / faster calibration, for example the app may select calibration criteria based on the elevation profile (and / or other characteristics) of the route ahead.

[0042] The inventors recognized that such a calibration procedure also presents a potential source of human error, and that it is possible to create and update estimates of the transfer function (and vehicle parameters therein) based solely on live data and an elevation profile. In a preferred implementation, the live data and elevation profile are observed, and inferences are made regarding the transfer function. The inventors recognized that clear changes in acceleration that are not correlated with clear grade changes may be associated with operator input and can be ignored (or weighted less). On the other hand, smooth changes in speed (and / or its derivatives) are unlikely to be associated with driver input and should be weighted more, especially if those changes are correlated with the elevation profile.

[0043] Inferences may also be informed by other data, such as speed limit changes and / or operator behavior (observed operator behavior or typical operator behavior). For example, when speed limits are reduced on level ground, drivers typically coast. A smooth deceleration curve, combined with the vehicle taking longer than expected to slow down, strongly suggests that the vehicle is heavier than expected. Similarly, a section of the smooth speed profile that correlates with the elevation profile predicted by the transfer function suggests that the transfer function is accurate.

[0044] Preferably, the transfer function is updated over time based on these inferences, resulting in the logic formulation being reformulated over time. This may include checking and re-checking fit with the model and updating parameters over time; for example, when using a model based on mass, drag, and rolling resistance parameters, the mass parameters may be adjusted upward after a slower-than-expected smooth deceleration. The formulation may include giving less weight to older data.

[0045] Margins, such as confidence intervals or error bands, for the transfer function (and / or its parameters, such as weights) may also be calculated. Based on these inferences, for example, if the confidence interval extends beyond a threshold, an error signal, such as "calibration required," may be displayed on the screen.

[0046] In a preferred embodiment, the driver does not input vehicle weight, and most preferably any other vehicle parameters. This eliminates potential sources of human error. Optionally, the system provides a null signal (e.g., a blank screen or a "not ready" message) until the transfer function estimate reaches an accuracy criterion, e.g., until data indicates that there is a 95% chance that the vehicle weight is within 5% of the estimated weight inherent in the transfer function. Preferably, the logic is based on a safe estimate; for example, the displayed future speed can be based on an estimated weight that is 95% likely to be higher than the actual weight. In some implementations, the system initializes to a transfer function corresponding to one or more of: (a) a higher-than-expected initial weight, (b) a lower-than-expected drag, and (c) a lower-than-expected rolling resistance, and provides a safe estimate until the transfer function is refined over time. Weight is typically the more critical parameter.

[0047] In this way, a smartphone mounted on the vehicle's dashboard can be used to estimate the vehicle's mass. In the described implementation, the mass is tied to future speed calculations. In other implementations, it may be used for other purposes, such as providing farmers with an indication of the weight of their crops before they arrive at the weigh station. Similarly, other vehicle parameters can be estimated and may be useful on an individual basis. For example, long-haul drivers carrying loads of various shapes and sizes could be informed about the aerodynamic effects of different load configurations, allowing for optimization over time and resulting fuel savings.

[0048] In certain implementations, for a particular downhill slope, the app estimates acceleration / deceleration forces due to gravity, drag, rolling resistance, and engine braking, and predicts how each of these parameters will change over the predicted route portion to more accurately estimate future speed(s). In a variation of FIG. 1, the app displays the (predicted) future speed at the bottom of the hill and the maximum possible speed within the prediction window to the bottom of the hill. Other variations of the system may instead (e.g., for an alternate user-selected mode) provide a continuously updated future speed within a predefined window, such as within a predefined window in terms of distance and / or travel time. One variation of the system simply displays the predicted speed 300 meters ahead of the vehicle, while another variation may display the maximum speed within 300 meters ahead of the vehicle.

[0049] FIG. 3 shows an alternative implementation of the concept, including a stationary speed detector 2 and a display 3 in the form of a vehicle-activated sign. The speed detector may include two different detectors at spaced locations to provide an indication of acceleration. Any convenient form of speed detection may be used, for example, a radar detector or even a simple speedometer. The display 3 may take the form of an electronic sign. The elements 2, 3 may be mounted in any convenient manner, such as on the side of the road, an overhead gantry, or on a bridge. A preferred variation of the equipment 2, 3 is installed at the beginning of a descent and is configured to provide a future speed signal in the form of a numerical display on the electronic sign 3, corresponding to the vehicle's expected speed at the bottom of the descent.

[0050] In preferred variations of the system, other sensors are incorporated to collect other input data. Weighbridges can be installed on the road. Cameras with object recognition capabilities can classify the vehicle type, and in other variations, databases can be consulted. For example, the system can read license plates to obtain data characterizing the vehicle's expected weight and drag. Other sensing devices can use light curtains to detect vehicle size. Multiple installations 2, 3 can be installed and networked along a single downhill slope to improve the accuracy of estimating the vehicle's future speed as it traverses the slope. Installing such installations on notoriously bad downhill slopes can immediately improve road safety.

[0051] Along the extended trucking route, separate facilities at separate downhill (or other target forecast windows) can be networked to further refine future speeds.

[0052] Speed ​​reductions are not the only situations in which it is useful to provide road vehicle operators with predictions of future speeds. For example, future speeds can be any point along a route where it is useful to know the speed; for example, if a sign indicates a reduced speed limit, providing an estimate of the future speed at the sign reduces the cognitive burden on the driver and allows them to judge their input so they can coast down to the new speed limit at the appropriate time without wasting fuel, using brake pads, or generating noise from engine braking. The start of mixed-use, road construction, or school zones is of particular note; speed limits in these areas protect the lives of road workers and other road users.

[0053] The end of the queue, or a selected point before the end of the queue, is another point of potential interest; to this end, variations of the equipment may incorporate sensors that sense the end of the queue. These sensors may take any convenient form, such as one or more cameras with object recognition capabilities, or a series of current meters with associated logic for detecting a series of slow-moving vehicles. For example, if roadworks are expected to cause congestion, a series of equipment 2, 3 may be placed in front of the expected congestion. Optionally, equipment may also be installed in front of blind spots near the expected congestion (or other hazard).

[0054] Some variations of the system may provide useful feedback without estimating the velocity itself. For example, a scheme that iteratively calculates the velocity gradually towards the front of the vehicle, where the series of calculations is V Max Before reaching the point, the vehicle may simply stop and issue a speed alarm. Such a speed alarm is an example of a future speed signal.

[0055] The present invention is not limited to the examples described herein. Rather, the invention is defined by the claims. For example, while described above for road vehicles, some variations of this concept may be particularly advantageous when attempting to drive a boat over a partially submerged trailer. While various variations generate future speed signals assuming no changes in operator input, other variations of the concept may anticipate changes in operator input (e.g., predict changes indicated by the system). Other variations may provide advance warning of indicated changes in operator input. In a boating variant of the system, the user may select the speed at which they wish to hit the trailer, and the app may provide a countdown to the appropriate time to throttle off the boat. The end of the countdown indicates that the trailer's future speed will exceed a threshold.

[0056] For road vehicles, it may be advantageous to issue a "coast" command before a descent. For example, if the vehicle is using cruise control and approaching a crest, before reaching the crest, the device may instruct the operator to disable the cruise control so that the vehicle slows down as it coasts toward the crest, and once at the crest, is at an appropriate speed for the subsequent descent. This approach may reduce fuel consumption and wear on the vehicle.

[0057] Exemplary Implementation One implementation of the method disclosed herein includes four main parts: Route database - RouteDB, Raw Database - RawDB, DownModel, and · Calculation Database - CalcedDB.

[0058] These key elements are briefly summarized and then explained in more detail below.

[0059] RouteDB - Overview RouteDB is hosted in the cloud and contains latitude, longitude, and altitude data points between two locations (e.g., Sydney and Melbourne, 25 meters apart).

[0060] PhoneApp - Overview This database records location data (latitude and longitude) at least once per second and immediately shares this time-stamped information with DownModel.

[0061] The phone app is cross-platform, has very low memory and power consumption, and has credential-based user login.

[0062] When logging in, the user declares the type of vehicle she / he drives (motorcycle, car, truck, or bus, etc.).

[0063] If the declared vehicle is a car or motorbike: To continue with the phone app, the user or their driver must declare how many people are in the vehicle.

[0064] If the declared vehicle is a truck or bus: To continue with the phone app, users must estimate / declare their total connected mass. Bus drivers must declare the weight of each passenger plus 100kg.

[0065] A declaration must be made every time.

[0066] The caches of claims are assumed to be identical in mass or vehicle type.

[0067] Caching of login data by users is not permitted.

[0068] The user can log off the phone app at any time. If the user does not log off, the phone app will automatically log off by itself after two hours if its GPS location changes by less than one kilometer in five minutes.

[0069] RawDB - Overview A database called "RawDB" is hosted in the cloud, which stores all the latitude and longitude coordinates shared by phone app users, with a date stamp for each coordinate.

[0070] DownModel - Overview A model named "DownModel" is hosted in the cloud. The DownModel calculates the predicted speed of the vehicle based on the vehicle's mass, speed, incline, and delay.

[0071] It uses position data, constants, and physics to derive predicted speeds.

[0072] Location data is retrieved from RouteDB and the phone app.

[0073] Constants like mass are obtained from a phone app.

[0074] Fuel use affects the declared mass values ​​and is reflected in model improvements over time.

[0075] DownModel generates predictions based on assumptions about delay. In an ideal world, OBD2 data defining foot brake use, exhaust brake use, gear selection, and RPM ranges would help predict future delay and accurate maximum exit speed. Where this is not possible, the algorithm uses analysis of phone app data to split delay into four components (inherent, foot, exhaust, and gearbox). This can be aided by data collection from other phone app uses with similar mass values ​​in the same location.

[0076] CalcedDB - Overview CalcedDB is hosted in the cloud and records all segment predictions made by DownModel, including all variables and constants. [Table 1]

[0077] A "location" is simply a number assigned to each latitude / longitude / altitude triplet.

[0078] The data in bold is a downhill slope (called a "hill" here). The data in italics is called a "HillFamily" here. It is predefined in RouteDB as starting 2 lat / lon degrees before the peak, and predefined in RouteDB as ending 20 lat / lon degrees from the next ascent (i.e., beyond its bottom). At 25m per data point, the "end" of the hill family is 50m from the first ascent of the next hill.

[0079] In this example, the first climb point is shown in italics.

[0080] In this description, each movement between two latitudes and longitudes is called a "segment." A segment is defined by a latitude and longitude. For example, one segment is: Starting at an altitude of 500m (top bold cell), · Ends at an altitude of 497m (second bold cell).

[0081] RawDB Explained The phone app works over an internet connection, and the user allows the phone app to share its location information with its mother database in the cloud, preferably at least once per second.

[0082] This shared data is stored in RawDB in the cloud. [Table 2] [Table 3]

[0083] DownModel Description Once the phone's location is optimally matched with RouteDB, the exit speed from the slope can be calculated, which requires data from RouteDB and RawDB.

[0084] From RouteDB: ·Inherit the hill family data from RouteDB.

[0085] From RawDB: - Inherits speed calculated over the last 5 segments. - Inherit vehicle mass (declared by the user when logging in). The vehicle's potential energy is calculated for each segment of the focal hill family, i.e., for each lat.long.alt (latitude.longitude.altitude) within the hill family, the exit velocity is calculated assuming no friction.

[0086] The formula for measuring potential energy from the start is: v=(G*H / 1.8) 0.5 During the ceremony, v=exit velocity(km / h) G = Gravity (9.81m / sec 2 ) H = descent altitude (meters)

[0087] By adding this to the inlet velocity, the exit velocity in a frictionless environment can be achieved.

[0088] A delay net for this potential energy is used to derive the estimated exit speed of the vehicle from the segment.

[0089] Delay is estimated based on the acceleration pattern (e.g., deceleration) in the previous segment. Some components of delay do not change enough to change the speed calculation by more than 0.1 km / h. For example, rotational inertia is fairly constant. Delay varies depending on what the vehicle driver is doing or not doing to slow the vehicle. Is she / he using the foot brake, engine brake, and / or low gear to slow the vehicle's momentum? Using the foot brake will appear as an uneven negative surge across multiple segments. Using engine brake will appear more stable across the segment. Using low gear may be enough to stop the momentum the vehicle has gained. Anything that characterizes a surge is considered non-repeatable and will not be considered for drag in subsequent segment predictions.

[0090] Once the delay is estimated, it can be counterbalanced with the potential energy to derive the estimated exit velocity of the vehicle.

[0091] This maximum score across all lat.lon.altitude points within the hill family is displayed to the user.

[0092] Users must be in the same lane to match exactly. The GPS log from the phone app must match the exact time the RouteDB log was taken, down to the millisecond. Therefore, the first hill family segment can handle the log discrepancy by calculating the entrance and exit speeds for the subsegments. [Table 4]

[0093] In CalcedDB, all factors that affect the calculation of exit velocity are logged, including mass. The results of all calculations are also logged. Predictions for each segment are logged in CalcedDB. As data accumulates in CalcedDB, it becomes possible to understand what typically happens in a particular segment. This understanding is used to define and predict each delay element, ultimately leading to more accurate predictions of exit velocity for the segment.

[0094] Explanation of the physics used Haversine formula Estimating the distance between two latitude,longitude data points is handled by the Haversine formula.

[0095] The formula (using radians for all latitudes and longitudes) is: d=(3963*acos((sin(lat1)*sin(lat2))+cos(lat1)*cos(lat2)*cos(long2-long1)))*(1.609344*1000)

[0096] In this invention: d = distance in meters lat1 = latitude of the data point in RouteDB lat2 = latitude of the data point sent by the phone app long1 = longitude of the data point in RouteDB long2 = longitude of the data point sent by the phone app

[0097] Potential Energy Formula Estimated speed (km / h) downhill with zero drag (60*60 / 1000)*0.5*M*v 2 =M*G*H Solve it as follows: v=(G*H / 1.8) 0.5 During the ceremony, v=exit velocity(km / h) G = Gravity (9.81m / sec 2 ) H = descent altitude (meters)

[0098] delay As noted above, in this example, the delay (calculated based on the velocity and acceleration over the previous five segments) is subtracted from the potential energy calculation.

[0099] The term "comprises" and its grammatical variations have a meaning determined by the context in which it appears. Therefore, this term should not be interpreted as exhaustive unless the context indicates otherwise. Similarly, the article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements unless the context indicates otherwise.

Claims

1. 1. A computer-implemented method for assisting a human operator in manually adjusting a speed of a vehicle, comprising: receiving live data relating to a current speed and acceleration of the vehicle; applying logic to input data including the live data; Based on the logic, the human operator: Quantifying a future velocity of the vehicle; and and indicating that the future velocity will exceed a threshold; the input data includes an elevation profile characterizing a path ahead of the vehicle; The future velocity is at the foot of the hill, and a maximum speed within a window of interest ahead of the vehicle; The method wherein the future velocity varies depending on the current velocity and acceleration of the vehicle.

2. The method of claim 1 , wherein the logic assumes no significant changes in commands to the engine, transmission, and brakes.

3. The method of claim 1 or 2, comprising formulating the logic based on the live data and the elevation profile.

4. The method of claim 3 , wherein said formulating comprises giving a relatively small weight to clear changes in the live data that are indicative of operator input based on a smoothness of the changes in the live data.

5. 5. A method according to claim 3 or 4, including giving relatively less weight to older data.

6. The method of claim 3, 4 or 5, wherein said formulating comprises estimating a mass parameter based on said live data and said elevation profile.

7. The method of any one of claims 1 to 6, wherein the live data comprises GPS data.

8. The method of any one of claims 1 to 7, wherein sending the signal comprises sending an on-board device signal.

9. The method according to any one of claims 1 to 8, wherein the computer is a smartphone.

10. Sending the signal includes sending a stationary device signal. The method according to any one of claims 1 to 6.

11. The method of claim 10 including one or more stationary speed detectors that collect the live data.

12. The method of claim 11 , wherein the stationary device and one or more stationary speed detectors are positioned before the end of a downhill slope.

13. The method of any one of claims 1 to 12, wherein the future velocity is at the foot of the hill.

14. The method of any preceding claim, wherein the future speed is the maximum speed in the window of interest ahead of the vehicle.

15. The method of any one of claims 1 to 14, wherein the live data comprises data acquired independently of the vehicle.

16. A computer configured to carry out the method of any one of claims 1 to 15.

17. one or more stationary speed detectors for collecting live data relating to the vehicle's current speed and acceleration; a computer configured to apply logic to input data including the live data; Based on the logic, a human operator Quantifying a future velocity of the vehicle; and and a stationary signaling device for sending at least one of the following signals: The future velocity is at the foot of the hill, and a maximum speed within a window of interest ahead of the vehicle; The system wherein the future velocity varies depending on the current velocity and acceleration of the vehicle.

18. 18. The system of claim 17, wherein the one or more stationary speed detectors and the stationary signaling device are located before the end of a downhill grade.

19. 19. A system according to claim 17 or 18, comprising a weight bridge for collecting input data.

Images