Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Tesla Autopilot maps

This site may earn commission on affiliate links.
I found the whole presentation fascinating but at the end they talked about needing HD maps (1-fully automated data collected from even current cars with cameras for things like LKA and uploading to build their maps AND 2-crowdsourced input to the maps for some specific things like stopping point for a redlight or stop sign [I have another thread on this because comma.ai is going to do this in 2018)

I don't think we have seen evidence of stopping points on any of the tile/map data at intersections ... that I recall.

A fair amount more info on Mobileye redlight and stopsign needs (HD maps) at 53:15 into this in the Q&A.

Crowdsource 'stop line' knowledge is critical.

http://youtu.be/GQ15HWCw_Ic?t=3195
 
  • Informative
Reactions: robertvg
I found the whole presentation fascinating but at the end they talked about needing HD maps (1-fully automated data collected from even current cars with cameras for things like LKA and uploading to build their maps AND 2-crowdsourced input to the maps for some specific things like stopping point for a redlight or stop sign [I have another thread on this because comma.ai is going to do this in 2018)

I don't think we have seen evidence of stopping points on any of the tile/map data at intersections ... that I recall.

A fair amount more info on Mobileye redlight and stopsign needs (HD maps) at 53:15 into this in the Q&A.

Crowdsource 'stop line' knowledge is critical.

http://youtu.be/GQ15HWCw_Ic?t=3195

Haven’t seen the whole presentation yet but 06:30 in it: Mobileye is going to launch Holistic Path Prediction in 2018...
Something we have had in Tesla Autopilot since end of 2015?

EyeQ3 in production since 2014, first customer: Tesla.
Tesla has now implemented the next generation AP hardware since end 2016.
MobileEye will start series production and implementing their next generation -EyeQ4 - in Q3/2018...

EyeQ5 should be good enough for level 4 autonomous driving, first samples coming this year....
 
Last edited:
Haven’t seen the whole presentation yet but 06:30 in it: Mobileye is going to launch Holistic Path Prediction in 2018... Something we have had in Tesla Autopilot since end of 2015?
EyeQ3 in production since 2014, first customer: Tesla. Tesla has now implemented the next generation AP hardware since end 2016. MobileEye will start series production and implementing their next generation -EyeQ4 - in Q3/2018...
EyeQ5 should be good enough for level 4 autonomous driving, first samples coming this year....
Will be interested in peoples views once they watch it all. TIP: I usually watch these in my PC browser window where youtube gives me the gear icon and I can change the speed to x1.25 or x1.50

They are doing a LOT and now they have/mentioned a lot of Intel resources helping. Personally I'm very impressed and sure they are conservative but their whole RSS (math based safety to help with standardization) effort seemed reasonable and a ton of work. Yes, it benefits them but the whole industry.

I was pointing out above the redlight/stoplight issue and the need for HD maps as I thought it was relevant to this thread. Here is a thread I started as comma.ai had a reveal that they are going to do it in 2018. I like them prototyping what can be done with limited (but custom) hardware and 'AI' software. comma.ai: announces stopsign/red-light 'AP' - needs 10 cm GPS loc
 
oh man, this thread is going to get me in trouble. for years i was just roaming about my neighborhood with my dash cam on and my gps logger active. i was big into the openstreetmap project. now i have a AP2 car... i have a feeling i am going to start driving around my neighborhood regularly passing roads that are not in the tesla hd maps yet. hahah FSD here we come!
 
Haven’t seen the whole presentation yet but 06:30 in it: Mobileye is going to launch Holistic Path Prediction in 2018...
Something we have had in Tesla Autopilot since end of 2015?

EyeQ3 in production since 2014, first customer: Tesla.
Tesla has now implemented the next generation AP hardware since end 2016.
MobileEye will start series production and implementing their next generation -EyeQ4 - in Q3/2018...

EyeQ5 should be good enough for level 4 autonomous driving, first samples coming this year....


In 2015... Tesla was using Mobileye....

EyeQ4 is good enough for level 4 autonomous driving.
 
Tesla bought back the Model X that @verygreen owned due to multiple problems, leaving him without a Tesla. Moreover, he said that Tesla had recently closed a lot of the holes that he had used to access the software internals, making it harder to reveal similar details in the future.
Oh we totally understand what happened, but that still doesn’t prevent me from acting like a child and stomping my feet craving some sort of insider hacker update from him :-/

Come on! Do Tesla hacking!!!


In all seriousness, I thoroughly enjoy(ed) reading all of his posts and others of his kind and skill level - it is immensely informative and interesting coming from somebody who has about 1/10th the skill and aptitude. It must be sort of like somebody smart explaining how particle physics works to kindergartners.

Waiting patiently for “official” updates sucks in comparison.
 
Ah, now I understand. Yes, it is exactly as you said - there is a byte in the spline structure, that is equal to 1 when the road does NOT have a central divider. At first this line of text was just "F22: Yes/No", later I changed "F22" to "Not Divided" and this is the result. Maybe I should have used the terms "True/False" to better describe what it means. I'll change it when I have time to work on it more.

This confusion may be caused by the language differences. I think it's quite clear by now, that my English skills are not too good. Sorry about that.



Like you already realized, this list is rather not related to separate measurements, or separate cars. I'm quite sure that this database doesn't contain any individual readouts, only aggregated data. I didn't explained it very well previously, so maybe I'll try to reiterate. I think that this list is showing how the speed is changing along the spline. So when there are three entries in the list, than the first entry shows the observed speed at the beginning of the spline, second in the middle of the spline, and third at the end of the spline. I came to this conclusion after seeing its visualization on the map. It just makes sense, when showing the acceleration and slowdown on highway ramps, slowing down in tight corners, or slowing down when driving thru an intersection:
View attachment 265013

I believe however, that this list is not used by the car to slow down in the corners. I compared it to one of youtube videos, and the car slowed down significantly more, than the speed in this list.

Because of similar reasons I think that the second field in this list elements is an observed acceleration. This one have more noise in it, but you can see patterns of braking before intersection and quickly accelerating after turns, or similar ones. I don't know the unit of this one, but if it is an acceleration, than I would be surprised if it's something different than m/(s^2).



Ok. I have some values in multiple units, but for me meters are normal, so I didn’t thought about all occurrences.




Yes, verygreen in first post mentioned, that there is a property saying whether radar braking should be enabled. My guess is that it is F18. It is a very weak guess, but If this assumption is correct, than you could expect that the car will brake before vague stationary radar echoes only on roads with F18 active and when it is outside of the radar exclusion zone (ignoring the details).

F18 is also visualized when in Radar Zones highlight mode. Roads with F18 active are dark blue, instead of black.
Maybe this is a way they resolved annoying braking and slowing down on yet unknown roads? That is, the braking is activated on a given spline when enough data is gathered about it and all exclusion zones are mapped.



Yes, when I see how many radar exclusion zones there are I also have some doubts. However this is better than nothing. When so called "radar only braking" is not active we just get back to remaining measures. That is, beside vision, radar can still detect non-stationary objects like in standard TACC mode. Besides, we don't know how exactly this works. Maybe they are able to detect some stationary obstacles even in the exclusion zones. Each zone has the height at which the obstacle is detected stored, so maybe they are able to do something with it, to some degree.



F7 is hard to determine. It’s quite random. There is a tendency that when it is not active the trust level is at most 10, but there are too many exceptions to draw any conclusion from this.



Ok, all this kind of suggestions are welcome. I can’t promise when I manage to work on new version, but I’ll try to correct that.



Well, this is not how most likely it works, and you don’t really have to download any more detailed versions. All roads in publicly available database exist as one big set at the surface of whole world map. There is no more or less detailed versions (as far as we know). Because the whole map is so big it has to be divided into some more manageable structure. Tiles are just a management mechanism on top of the map, to quickly find needed parts. Big tiles are a way to split map into files requested by the cars from servers. Smaller tiles are part of the structure inside of the big tiles, existing to speed up the search of splines. When downloading a big tile you have all publicly available splines within that region.



I was curious about that too and checked a fragment. I didn’t found anything related to Left/Right Hand drive, so this is most likely determined in some other way. I also checked if the on ramps and off ramps are labeled correctly, and they are (that is, on opposite sides than in US).



I have no idea how the trust is calculated. I’m not event completely sure if this is a “trust” value. When looking at the highlight of that property it looks like this value is greater for roads with bigger traffic, like highways and main roads, so that's the only hint about it I can find.



I don’t know how they determine that the road should be included on the map, or even how they know about existence of the road. I have however one related observation. It looks like there is more splines in their internal database than we can see in the publicly available tiles. Sometimes a fragment of a road is missing, or a whole road existing in google maps is missing, but the ID references suggests, that nearby splines are connected with this missing piece. Like here, where two pieces of highway ramps are missing, but nearby splines have references to same ID missing in this tile:
View attachment 265029
This could mean, that those missing splines have their IDs assigned, but are not published.



Yes, usually when clicking on a road a whole spline is selected and its information are displayed. When in Radar Zones highlight mode it is also possible to click onto specific zone and information about this specific zone will be displayed as “Current zone”. This is helpful when a spline contains multiple zones. Similarly in Local Speed mode a speed interpolated in clicked point is shown, and in F5 Zones the clicked zone is show. There should be some visualization on the map, that the information are related to a specific point, that is still missing, so this might be a little confusing.



F25 doesn’t look to be a good candidate for line change flag. It can be found both active and not active for good quality highway splines, and it has different values for various local roads. F21, F24 and F26, that differentiate highways and local roads look to be more appropriate, or even F22 (currently known as Not Divided). Besides, F25 looks to be missing in tiles from dev branch.

And one more thing. I found that in some European tiles there are significant differences in F22/Not Divided flag between live and dev branches. So maybe it would be wise to check live branch when comparing properties to the current, known behavior.
I didn't notice this discussion about stopped vehicles under an overpass until now, a little after I gave a related answer in post #60 here: AEB Won’t Prevent an Accident . I think it is likely, when a vehicle is stopped under an overpass or overhead sign, that even when the vehicle is not separately identified as an object, the "merged" vehicle and overhead structure may be reported by the radar with a different height than was the overhead structure alone. If so, then that disparity between real-time reported height and that recorded for that radar object in the Tesla map tile may be used to indicate something unusual is there and probably dangerous. I have no knowledge whether Tesla actually uses the data in that way, but if the radar returns a different height for a "merged" stopped vehicle underneath an overhead structure, compared with the height it gives for the structure with nothing present and stationary underneath, then it should be possible
 
Last edited:
I found the whole presentation fascinating but at the end they talked about needing HD maps (1-fully automated data collected from even current cars with cameras for things like LKA and uploading to build their maps AND 2-crowdsourced input to the maps for some specific things like stopping point for a redlight or stop sign [I have another thread on this because comma.ai is going to do this in 2018)

I don't think we have seen evidence of stopping points on any of the tile/map data at intersections ... that I recall.

A fair amount more info on Mobileye redlight and stopsign needs (HD maps) at 53:15 into this in the Q&A.

Crowdsource 'stop line' knowledge is critical.

http://youtu.be/GQ15HWCw_Ic?t=3195


Yo!!! Omg. I was the person who asked this question at that presentation :)

But yea, I agree the stop line is critical... Whether it is crowd sourced, or created manually in urban areas.
 
  • Like
Reactions: hiroshiy
I did 400 miles on 2018.10.4 in our '17 X over the weekend and really enjoyed the new AP (NN model).

I had an auto braking incident (75 -> 65 perhaps) while going under this overpass. Not sure the best way to report it? Downloaded the tile and saw: 'Radar Braking Enabled: No'.

42.28982401, -88.96468875
Google Maps

rtGVfMO.jpg
 
I did 400 miles on 2018.10.4 in our '17 X over the weekend and really enjoyed the new AP (NN model).

I had an auto braking incident (75 -> 65 perhaps) while going under this overpass. Not sure the best way to report it? Downloaded the tile and saw: 'Radar Braking Enabled: No'.

42.28982401, -88.96468875
Google Maps

rtGVfMO.jpg

Seems kind of sloppy..

to have hard coded road sections that have radar braking disabled.
 
  • Like
Reactions: croman
Could an invalid "next" spline be responsible for this almost crash into a lane divider: Autopilot Barrier Lust (2018.12) • r/teslamotors

https://daws.tesla.services/iiNG2d6xFR1USl/live/c23p2.tile

From OP there:
Not a construction zone. It's where the express lanes in Seattle merge back into the main lines. It's been like this every day for 50 years. Going to the left is going onto oncoming traffic. These lanes are used one direction in the morning and another in the evening.

Previous autopilot versions didn't do this. 10.4 and 12 do this 90% of the time.


spline 112402426 seems to be ****ed up. "next" reference is leading nowhere (not a valid spline: 112410607). "following" are the splines: 1) in the different direction 54729252
2) the correct spline 54737434
3) the invalid "next" spline 112410607
 
Could an invalid "next" spline be responsible for this almost crash into a lane divider: Autopilot Barrier Lust (2018.12) • r/teslamotors

https://daws.tesla.services/iiNG2d6xFR1USl/live/c23p2.tile

From OP there:



spline 112402426 seems to be ****ed up. "next" reference is leading nowhere (not a valid spline: 112410607). "following" are the splines: 1) in the different direction 54729252
2) the correct spline 54737434
3) the invalid "next" spline 112410607

Tiles aren't being used yet for driving.