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

FSD Beta Videos (and questions for FSD Beta drivers)

This site may earn commission on affiliate links.
note, I HATE the mechanical liability of PTZ mechanism, but it has to be solved, solved for car temps and vibration (and lots of abuse), but you know, this is a solved problem, mostly. outdoor ptz cameras can be bought and designed to be ruggedized. its some work but not rocket science ;)

you also need a good suspension or good software to do the stabilization.

this adds cost.

elon hates cost.

but cost is a necessary thing when 5 nines come into play (life and death).

its always helpful to keep the end goal in mind: human beings trusting their lives to the hw/sw. in that aspect, cost is 100% irrelevant to me.
 
Agreed. Middle lens with the unshrouded fish-eye lens helps with this. We've been manipulating and processing images for centuries so all of this is well understood.

There are spots that aren't safe. Maintenance crews need to regularly cut back vegetation growth so drivers can see and pull-out safely. Having a Tesla is great because you have the ability to accelerate really quickly when needed.

Note this is not really possible with the current triple cam setup. The image sensors are all on the same control board and can't be moved independently. You can have the lenses swivel, but that will cause issues for light transmission (light will be off axis) and will have focus uniformity issues (like a tilt/shift lens).

And if you swivel the whole assembly, you pretty much would have redesign the whole housing. At that point, it makes more sense to just have 5 cameras and use a switch to switch between camera signals (if bandwidth does not allow them simultaneously). In general any physical moving mechanism is another source of failure, so I think tesla will want to avoid that.

Tesla-Triple-Forward-Camera-part-collection-System-Plus-Consulting.jpg
 
Note the color of the broken stripes separating opposing traffic when the car wanted to move left. They're white. White lane markings are only used for same-direction travel.

That's the US standard for separating lanes moving in the same direction. Yellow stripes are to be used to separate different directions of traffic. See, for example, Helpful Driving Info | Markings: Colors, Patterns, Meaning

More evidence: many locales in CA have replaced the double double YELLOW lines separating HOV from mainlines (both with traffic in the same direction) with double WHITE lines.

So the city has made an error in road markings, which could confuse anyone depending on those lane markings that imply one-way traffic.

This is a corner case due to improper lane markings. Nothing more.
You can see, that there are cars coming at your direction. You don’t need to check the colours of the lines.
 
You can see, that there are cars coming at your direction. You don’t need to check the colours of the lines.
What if there wasn't until you went into that lane? In general the car would still have to figure it out without relying only on other cars.

I don't know about Europe, but the USA has center left turn lanes, where it is expected to have opposing traffic come your way. Opposing traffic does not mean you are improperly in a lane. So definitely there is a need to check the lines.
27hop.gif
 
What if there wasn't until you went into that lane? In general the car would still have to figure it out without relying only on other cars.

I don't know about Europe, but the USA has center left turn lanes, where it is expected to have opposing traffic come your way. Opposing traffic does not mean you are improperly in a lane. So definitely there is a need to check the lines.
27hop.gif
I don't think anyone is suggesting that AVs should just ignore lane markings.
Humans know that there is no plausible road configuration where it could switch to a one lane road there. It is a very interesting case because it's hard to even explain how human drivers can easily determine this. I bet if you sat there for a week you wouldn't see a single human driver change lanes in to the oncoming traffic lane. Though I bet there are vehicles parked on the left which would be a huge clue.
Of course to achieve FSD the vehicle will have to drive when there are no lane lines such as when the roads are covered in snow.
 
  • Like
Reactions: Matias
you need to get a better av technician... the guy you’re using mustn’t be very good. And there are better technologies than WiFi.


I use this every weekend and never have a dropout unless I’m 2 miles down range.
You also use it outdoors with the signal source up in the air. That's line of sight, point-to-point, with no multipath interference. That's approximately the easiest wireless environment to deal with. Just shout loudly enough to get the signal to the destination and you're done. The only reason they even need MIMO for that is because they want to keep the transmission power down for battery life reasons.

Contrast that with a car, where you'll have interference from other similar cars nearby, huge amounts of metal between you and the signal source, multipath galore (including from nearby concrete or rock walls, ceilings, bridges, asphalt, cars, etc.), and lots of interference from other 2.4 GHz sources (Bluetooth, Wi-Fi) actively in use within your car. It's an entirely different kind of signaling. And other frequency bands would be saner in that regard, but more problematic because of less penetration through whatever materials the vehicle is made of.

I'm just not convinced that it's feasible. Multiplexing multiple signals on the same wire (e.g. side cameras up at the top of the windshield at both sides with wires running under the headliner from a modified central camera assembly, or extra cameras built into the side repeaters) probably is, and seems like a much more reasonable and reliable approach.
 
Note the color of the broken stripes separating opposing traffic when the car wanted to move left. They're white. White lane markings are only used for same-direction travel.

...
So the city has made an error in road markings, which could confuse anyone depending on those lane markings that imply one-way traffic.
This is a corner case due to improper lane markings. Nothing more.
The markings as of 2013. Got a little faded over the next 8 years...
Up until the blue bus it was doing well as it crossed the dashed white lines into the right turn lane. Then it crossed two solid white lines for the edge of the right turn lane and the bike lane and headed for the far left. Even with the faded line markings elsewhere, the solid white lines were still clear as it crossed them, then they all faded again. Certainly poorly maintained line markings.

Chicago.png


Oct 2020
Chicago2.png
 
I don't think anyone is suggesting that AVs should just ignore lane markings.
Humans know that there is no plausible road configuration where it could switch to a one lane road there. It is a very interesting case because it's hard to even explain how human drivers can easily determine this. I bet if you sat there for a week you wouldn't see a single human driver change lanes in to the oncoming traffic lane. Though I bet there are vehicles parked on the left which would be a huge clue.
Of course to achieve FSD the vehicle will have to drive when there are no lane lines such as when the roads are covered in snow.
I'm not sure if you are referring to the same thing, but according to a deeper analysis here, that road on the opposite side does change to a one lane road.
FSD Beta Videos (and questions for FSD Beta drivers)
FSD Beta Videos (and questions for FSD Beta drivers)
In fact there's a car in the lane the Tesla was trying to cross into, waiting for the left turn, because actually it's a one lane road on the opposite side.
VhWOTDe.png


If instead you are talking about the lane travelling in same direction as the Tesla, that Tesla's AI may have thought was suddenly changing into a parking lane, note such a lane design does exist in the real world.

Here's an example, I've encountered myself:
Google Maps

In case the 360 google maps link doesn't work, I have put pictures below.
It's a time conditional lane, where cars can park in the lane at certain hours (but lane is a valid travel lane in other higher traffic hours). You can see the 3 white cars parked in the lane in picture below. However before the driveway, there is a "No Stopping Any Time" Sign. Note how the lane abruptly ends at the driveway and there is no indication of a need to merge to the next lane over on the pavement (no arrows or other markings). It just changes to a parking lane right after the driveway (according to hours posted).
parking_lane_1.jpg

This picture, turning the view to the left makes it clear it's a travel lane further up the road (see the Dodge pickup truck approaching):
parking_lane_2.jpg
 
Last edited:

Attachments

  • 1628891640821.png
    1628891640821.png
    1.4 MB · Views: 31
Oops, I meant one way road. It's two lanes on the opposite side.
The original and current sorry state of the lane markings are in this post (FSD Beta Videos (and questions for FSD Beta drivers))
But the Tesla didn't appear to think it was a one way road. You can see in the visualization it still shows the yellow line.

Note the pathfinding is not necessarily always following the road design that the car detects. We've seen plenty of examples of this, for example it plotting a route through a metal fence, even though it knows that it's off the road. Probably there needs to be additional sanity checks in the code to prevent that.
 
But the Tesla didn't appear to think it was a one way road. You can see in the visualization it still shows the yellow line.

Note the pathfinding is not necessarily always following the road design that the car detects. We've seen plenty of examples of this, for example it plotting a route through a metal fence, even though it knows that it's off the road. Probably there needs to be additional sanity checks in the code to prevent that.
Yeah, the big mystery is why it swerved left when it had a right turn coming up.
My response was to the suggestion that the white lane markers indicated the road is one-way.
 
the range is 3 miles. 6ft shouldn’t be an issue lol. And the signal doesn’t that’d to be perfect with zero latency.

Those audio systems I talked about are supposed to have range measured in thousands of feet. They still fail at single-digit feet when you have the right combination of physical conditions (signal-reflective surfaces near the receiver, signal-absorbing surfaces between the transmitter and receiver, etc.). Wireless works well in large open rooms. It does not work well in a giant tin can.

It actually does have to have zero latency or very nearly so. Otherwise, you can't cross-compare the image in one camera against the image in another camera to get a reliable distance and speed estimate. You can do only single-camera estimation, which is less precise. And the later the signal arrives, the more likely the information is to be useless by the time the computer can act on it. Even one full frame of latency is likely too much, which pretty much rules out compressed video unless you're doing something very minimal (e.g. MJPEG sent without doing multiple passes to compute the quantization or something equally low-quality), and even then, it would mean custom codec hardware.

And uncompressed video is completely out of the question. One camera produces about 531 Gbps of data. That's more than five times the current world record for wireless communication. And you want to do that reliably in a safety-critical system.

Whfey.
 
Those audio systems I talked about are supposed to have range measured in thousands of feet. They still fail at single-digit feet when you have the right combination of physical conditions (signal-reflective surfaces near the receiver, signal-absorbing surfaces between the transmitter and receiver, etc.). Wireless works well in large open rooms. It does not work well in a giant tin can.

It actually does have to have zero latency or very nearly so. Otherwise, you can't cross-compare the image in one camera against the image in another camera to get a reliable distance and speed estimate. You can do only single-camera estimation, which is less precise. And the later the signal arrives, the more likely the information is to be useless by the time the computer can act on it. Even one full frame of latency is likely too much, which pretty much rules out compressed video unless you're doing something very minimal (e.g. MJPEG sent without doing multiple passes to compute the quantization or something equally low-quality), and even then, it would mean custom codec hardware.

And uncompressed video is completely out of the question. One camera produces about 531 Gbps of data. That's more than five times the current world record for wireless communication. And you want to do that reliably in a safety-critical system.

Whfey.
If you are talking about audio, wireless local transmission of that have been done reliably for a while already, the broadcast world depends on it. If you are talking about video, I'm guessing you aren't using a dedicated transmitter/receiver pair (like the ones that have an SDI or HDMI connector directly on the transmitter/receiver).

Most likely you are using software that works through standard ethernet equipment, in which case there's a lot of components (including sometimes the software itself) in between that can lead to dropped frames unrelated to the system being wireless (AKA it'll do the same even if the connection was wired). You can analyze the wireless connection for dropped packets (easy way to do this is just send a ton of pings, but there are other tools that can do so also). It's easy to find examples of people using wired connections with dropped frames when using NDI or NDI HX (lots if you just google it).
NDI Dropping Frames
Diagnosing inconsistent frames with the Analyzer of NDI HX camera's

But I don't really think they will go with wireless video regardless. I agree with your post previously they would more likely do multiplexing or just switching of signals given no all cameras necessarily need to be on at the same time (like some cameras can turn only to get more detail for turns).
 
Last edited:
  • Like
Reactions: qdeathstar
w
Those audio systems I talked about are supposed to have range measured in thousands of feet. They still fail at single-digit feet when you have the right combination of physical conditions (signal-reflective surfaces near the receiver, signal-absorbing surfaces between the transmitter and receiver, etc.). Wireless works well in large open rooms. It does not work well in a giant tin can.

It actually does have to have zero latency or very nearly so. Otherwise, you can't cross-compare the image in one camera against the image in another camera to get a reliable distance and speed estimate. You can do only single-camera estimation, which is less precise. And the later the signal arrives, the more likely the information is to be useless by the time the computer can act on it. Even one full frame of latency is likely too much, which pretty much rules out compressed video unless you're doing something very minimal (e.g. MJPEG sent without doing multiple passes to compute the quantization or something equally low-quality), and even then, it would mean custom codec hardware.

And uncompressed video is completely out of the question. One camera produces about 531 Gbps of data. That's more than five times the current world record for wireless communication. And you want to do that reliably in a safety-critical system.

Whfey.

We just want to know whether a car is present or not for a relatively large period of time. We wouldn’t need a high level of precision necessarily because it doesn’t matter if the car is 400ft away or 410ft away of 390 ft away, just if it is 400ft away or 300ft away and an estimate about what the close rate is.


I agree already a wired system would be best, but we are talking about if it is possible at a certain level of saftey. It certainly is for the limited scope we are talking about, forward facing cameras on the repeaters to check for cross traffic.

chszmm