v1.9.1

v1.9.1

Minor update to the map build scripts to ensure there's overlap data available at the borders of 20x20 blocks. Note that there is no change in this release to the mapd binary itself.

What's Changed

• extract a larger area from the planet file by @pfeiferj in #51

Full Changelog: v1.9.0...v1.9.1

v1.9.0

V1.9.0

Download progress improvements

Previously countries with large areas without roads would show up as having more files to download than were actually uploaded to the server. This resulted in the download progress never finishing as it would fail to download some fails and not see the total possible files all be downloaded. To resolve this blank files were added for empty tiles, this means that there will be a file on the server for every possible area of the world.

Next Way Detection Improvements

Tile Overlap

One area in which there's been issues detecting the correct continuation of the current road is near the borders of the map data tiles. If the current road segment ends just past the tile border then the current tile would either have partial or no map data for continuing the road. Previously we just ignored checking for continuations past the tile border to resolve the issue with partial matches, however this still meant that when we crossed over the bounds we would have to recalculate which road we are on which could sometimes fail. To improve this situation the map data tiles have a slight amount of overlap in their data. This means we can always find continuations up to the current 1000 meter lookahead distance. This leads to curves near tile borders being properly detected as well as keeping mapd better locked onto the current road.

Partial Ref Matches

When looking for the next section of the road we preferred segments that matched the current road name, then segments that matched the current ref. However, a segment can reference multiple highway systems at once. This means we could run into a situation where one highway system ends but another one continues. To account for this we now have a third preference for when any one part of the refs matches the segment. This however leads to a new problem where we could have multiple preferred matches, so for these multiple preferred matches we select the one with the least amount of curvature.

Ignore Preferred Segment With High Curvature

In some cases when a highway goes from being split to a single road this results in the osm data going from two one way roads to a single two way road. Often times when this happens the name and/or refs for a road would change and lead to doing a uturn being the "preferred" segment for continuing on. To combat this a check was added to the preferred segments for very high curvatures. If the curvature is too high we skip that segment from being "preferred" which leads to the only way for it to be selected is by the fail safe smallest curvature detection.

Wrong Way Detection

Another problem when a road splits and goes from two ways to one way is that we now have two choices for which segment to follow. To help aid with selecting the right one the one way flag from osm was added to the map data. This allows us to only select a segment as the "next way" if the direction of travel for that segment is in the correct direction. This one way check was also added to deciding if we are currently on a segment, this aids in initially finding which road segment we are on as sometimes there are multiple candidates with different directions of travel that we could choose from.

False Positive Improvements for Merges and Splits

Whenever a road merges or splits there ends up being sharp curvatures detected. This is due to how roads are represented on osm. Roads are a series of points along the centerline. However, when a road splits or merges this changes where the center line is, so you have a sudden shift in the position of the points that looks like a sharp curve to mapd. To correct for this mapd now tries to determine if a road merge or split is happening and then fudges the curvatures to look more like a straight line for a small distance around the split or merge. This results in mapd not triggering a slow down for these areas, and in the event that there still is a lot of curvature then the surrounding points should still reflect that. mapd could "lose" track of the curve for a short period during the merge/split but this is mitigated by logic already in openpilot to prevent large acceleration or deceleration while in a curve.

What's Changed

• Overlap areas to improve transitions between files by @pfeiferj in #43
• add a flag for generating empty offline files by @pfeiferj in #44
• add overlap field so old map files don't cause issues by @pfeiferj in #45
• check if going wrong way by @pfeiferj in #46
• Next way detection improvements by @pfeiferj in #47
• change from angle to curvature check, better partial refs match, fudge road merge curvatures by @pfeiferj in #48
• fudge road splits, tune fudged curvatures, more one way detection by @pfeiferj in #49

Full Changelog: v1.8.1...v1.9.0

v1.9.0-beta5

What's Changed

• fudge road splits, tune fudged curvatures, more one way detection by @pfeiferj in #49

Full Changelog: v1.9.0-beta4...v1.9.0-beta5

v1.9.0-beta4

What's Changed

• change from angle to curvature check, better partial refs match, fudge road merge curvatures by @pfeiferj in #48

Full Changelog: v1.9.0-beta3...v1.9.0-beta4

v1.9.0-beta3

What's Changed

• Next way detection improvements by @pfeiferj in #47

Full Changelog: v1.9.0-beta2...v1.9.0-beta3

v1.9.0-beta2

What's Changed

• check if going wrong way by @pfeiferj in #46

Full Changelog: v1.9.0-beta1...v1.9.0-beta2

v1.9.0-beta1

What's Changed

• Overlap areas to improve transitions between files by @pfeiferj in #43
• add a flag for generating empty offline files by @pfeiferj in #44
• add overlap field so old map files don't cause issues by @pfeiferj in #45

Full Changelog: v1.8.1...v1.9.0-beta1

v1.8.1

What's Changed

• use cache for earthly install by @pfeiferj in #39
• get multiple next ways based on a minimum distance by @pfeiferj in #41
• Update README.md by @Emalton in #40
• fix the check used to determine the node for calculating the bearing by @pfeiferj in #42

New Contributors

• @Emalton made their first contribution in #40

Full Changelog: v1.8.0...v1.8.1

v1.8.1-beta1

What's Changed

• use cache for earthly install by @pfeiferj in #39
• get multiple next ways based on a minimum distance by @pfeiferj in #41

Full Changelog: v1.8.0...v1.8.1-beta1

v1.8.0

Configurable Target Lateral Acceleration

When first introduced mtsc used a constant of 2.0 m/s^2 with the expectation that if you wanted to use other values it should be done with the curvature outputs. V1.8.0 introduces a configuration param to set a desired target lateral acceleration so that you can continue reading the target velocity outputs. View the documentation for configuring this value here.

Logging Levels

Up to now mapd has had a reputation for having "noisy" logs. v1.8.0 introduces improved logging that allows for configurable logging levels. The default level also significantly cuts down on the amount of log output from mapd. Other improvements are a move towards structured logging to enable easier searching of data when looking for bugs. Finally, the logs also include stack traces with the errors to make finding the location in the code that is erroring significantly easier. The documentation for configuring the logs can be viewed here.

Improved Next Way Detection

In OSM roads are split into multiple sections called "ways". In some cases when trying to find the next way mapd would incorrectly choose a way that was merging into the current one. The reason for this is that the method of detecting which way resulted in the straightest path didn't take into account the direction of the road, this means that a 180 degree change in direction was treated the same as a 0 degree change in direction, thus being considered "straight". The detection process was updated to instead calculate the curvature that would result from driving from the current way onto the candidate way. This means that we can just check for which way results in the smallest amount of curvature and that will be equivalent to the straightest path to continue on. This improvement should be most noticeable on exit ramps that have merges.

What's Changed

• improve logs and add logging levels by @pfeiferj in #35
• don't reset current and next way when crossing bounds by @pfeiferj in #36
• use curvatures to determine the most straight next way by @pfeiferj in #37
• configurable target lat accel by @pfeiferj in #38

Full Changelog: v1.7.5...v1.8.0