Hacker News Reader

> Citroen has been doing it since the 50's with a purely mechanical system.

I remember watching Citroens demonstrating losing a wheel, and continuing to drive, in the early 1970s.

Citroens are cool. Maybe their build quality wasn't so good, or they were too expensive, as I've not seen them on this side of the pond.

I can confirm. Was driving for a while, impervious to any sign of having a flat tyre before someone on the street signalled me to stop. And that was on a Citroen Saxo, which I don’t think had the suspension of C5 etc. Amazing car, lasted for 15 years with me, with only battery and frankly inconsistent oil changes. The lady who bought it when we immigrated still runs it 15 years later. Build quality is a hit and miss per model I think.

Citroën pulled out of the North American market in the 1970s, due to US regulations that required headlights maintained a consistent height. Since their suspensions allowed them to raise and lower their height, there was no way they could be compliant without massive changes to their system. Besides, the Citroën network was not big in the US anyway, and since the DS had few facelifts in its 20 years in production, it was falling out of favour with US consumers who didn't want to be seen driving yesteryear's car.

Their build quality is fine, at least contemporarily to the rest of the market; of course today, we would find its steel pitiful. It's not without reason that people who maintain Citroëns of that era tend to replace the panels with fibreglass ones.

Additionally, as Citroën pulled out, the maintenance network in North America began to falter, as the suspension system required significant know-how. There are still a dedicated group of Citroën fans in North America (albeit small), and I met a lot of them when I drove from coast to coast (and back again) back in 2017 in a 1998 Citroën Xantia. A car that may not seem particularly interesting to Europeans (although it was the Activa V6 model), but it was extremely rare in North America.

https://en.wikipedia.org/wiki/Moose_test

"It is noteworthy that the previous record holder (set in 1999) was the Citroën Xantia 3.0i V6 Activa, an unassuming family car with a unique active roll bar system.[15]"

They should have just lobbied the government instead.

Citroën? A French auto-maker lobbying the US government so they can stay on the US market? Besides Citroën was basically always about to go bankrupt before Peugeot bought them in 1976. Buying Maserati and building the SM had not turned into the success they had hoped for.

> 1970s, due to US regulations that required headlights maintained a consistent height.

Were headlights bouncing up and down a problem back then?

Sounds so ridiculous, especially considering there is no regulation about the headlights’ actual height/color/intensity/angle, which causes many drivers to blind others these days.

The point of the regulation was to kick Citroen off the market

Unfortunately, I cannot find an actual source for this ban. So many sites repeat the claim, but with no citation. So now I am not even sure it's true. I tried searching NHTSA's website, but it's kind of a mess. I do know, that Citroën pulled out in 1974 from the US. The CX, released the year after, was never sold in the US, and the last year of the SM, which was popular in the US, only saw sales in Europe.

There absolutely is, at least in the EU.

You can have any colour, as long as it's 6000-ish K.

In France, every two years you gotta have your car legally checked. Misaligned headlights is ground for not passing, or being fined if the police notices it in between.

Ever since high power Xe headlights are a thing, headlight leveling is mandatory to be automatic.

Just yesterday I was remembering the ride on a Citroen XM in the 90s which has the full blown hydropneumatic suspension (https://en.m.wikipedia.org/wiki/Hydropneumatic_suspension) . Decades later I haven’t been in a car with such a smooth ride

they even had a project for hydraulic-driven wheels - some kind-of water-mill in each wheel, and a huge pump, and that's it :)

p.s. long time ago i bought a 15y old hydraulic Citroen, drove it for 10 years.. the hydraulics was less breaking than the engine :/ . Now i have another (recent) Citroen but that "road-surface-ignorant" feeling of the hydraulics is completely gone.

The Citroen system was very ingenious but also physically quite simple.

It got a bad rep through an initial design flaw that was quickly solved, and (US) mechanics that did not know or learned how to do maintainance on these.

https://www.autoevolution.com/news/citroen-hydropneumatic-su...

I've had automatic inertial valve adjustment in my mountain bike for 10+ years as well.

This looks similar to Porsche Active Ride Suspension discussed here https://news.ycombinator.com/item?id=39739404.

My 1991 Mitsubishi 3000gt VR4 had switched dampers stock! These were not reactive it was just high or low with a button and maybe some automatic logic. But even on stiff mode, aftermarket struts were stiffer so I replaced them.

> If I remember right, the Bose implementation required too much electricity to be practical

Battery powered cars might have solved that? Although the extra battery mass would prevent "leaping".

It's really smart though: Why spend a lot of energy moving the wheel up and down, when you can just control the damper and rely the spring to store energy.

Precision, repeatability, responsiveness.

It's easy to underestimate just how slow digital systems are in many real time scenarios compared to analog systems.

Consider it in the context of camera based self-driving cars, it's tangential to this discussion but it's an easy to visualize metaphor:

- A car traveling 60mph is traveling at 88 feet per second

- Assuming a 60hz camera, there would be a 16.67 ms gap between each frame

- The car is traveling 1.5 feet between each frame interval

- A certain amount of exposure time is necessary for the camera to generate even 1 frame or it will be blurry

- High framerate cameras often work around this by staggering/interlacing multiple sensors, but doing this implicitly increases the latency of each frame

- A 120hz camera might deliver double the frames per second, but each frame could be arriving 4 frames late in exchange

- 4 frames would be imperceptible to humans, it would be 3 feet for the car

- You haven't even processed any of these frames yet.

- Your off the shelf library introduces a random 1 second delay for some reason and costs you 88 miles in processing time

- The car can drive as fast as 120mph

All digital sensors implicitly have a sampling frequency, and the fundamental disconnect is always high sampling frequency =/= low latency. People constantly make this mistake over and over, and by the time you notice you are already too deep into development to make a change.

Decreasing latency is expensive, and requires specialized knowledge. Often you get expert software engineers who end up bottlenecked by the hardware limitations they can't even comprehend or the reverse, hardware guys bottlenecked by the software they can't introspect. The latency is only truly understood when you get to integration testing.

Nearly every step of the way you discover you need specialized hardware, software, operating systems, sensors. Every part of the chain each costing you more latency. It's like it's own ecosystem where almost everyone writes everything from scratch and doesn't share anything. It's gotten better in recent years though.

Full disclosure: I work in medtech and don't actually deal with cars, but it's a very similar problem space. We often use the same hardware/software cars use for this reason.

88ft not 88 miles. I don't understand your 120hz camera line, I also have a degree in imaging tech and that part I do not understand, would you be so kind as to expand upon it??

Wew I'm getting a lot of pedantic replies here. Yeah I got the units wrong there my bad, you get the point I was making though right?

In regards to the 120hz camera line, I would be happy to expand on that for you. To be clear, I'm specifically talking about how when you try to increase sampling rate by interlacing multiple concurrent digital sensors you need to deal with the following potential problems (this is a property of all digital sensors):

- Real time synchronization between concurrent sensors requires additional processing time to ensure proper ordering. The samples need to be processed together in small batches. This adds latency and the more things you are trying to synchronize the more latency is introduced.

- Inter-sensor calibration to account for variations between individual sensors can be used to reduce the latency introduced by synchronization but lacking this, you are bottlenecked by the slowest sensor. There are a lot of different ways to handle this though so I'm speaking very generally.

- Broadly speaking most signals need to go through some kind of filter to remove noise, most digital filters have a certain amount of algorithmic latency built-in that is physically unavoidable. When you are interlacing multiple different sensors, you are getting more noise, so the likelihood of a filter being required starts to increase.

I want to stress here that these are not impossible challenges. In fact they are largely solved problems. But they are not universally solved in the same way, you need to balance between precision manufacturing, signal quality and signal latency. In practice most people are not prioritizing latency, so a 120hz camera might be optimizing for video recordings and not live processing scenerios. So long as you know what you are looking for you can avoid this when choosing which camera to use.

Computers can be fast, but fast can mean different things when dealing with real-time situations in high speeds. Bottlenecks need to be considered from all levels. The clock speed of the computers CPU often gives product managers weird ideas about what is possible. This was the main point I was trying to make here.

> I'm getting a lot of pedantic replies here. Yeah I got the units wrong there my bad, you get the point I was making though right?

You get the most pedantic replies when you're right and people don't like it.

I work on a latency sensitive product. You're pretty correct about most of it.

Anything with latency is amusing. You can send data a few thousand km in the time you can make it show up on your screen.

I can’t quite understand your comment.

> Assuming a 60hz camera, there would be a 16.67 ms gap between each frame. The car is traveling 1.5 feet between each frame interval.

Ok? So? You are just stating this as if we should understand the implications. I do in fact work with self-driving cars. What you say is true, but it is not a big deal. Why do you feel this maters? Or what is your point?

> A certain amount of exposure time is necessary for the camera to generate even 1 frame or it will be blurry

This is a confused statement. A certain amount of exposure is necessary for the camera to collect light. If you don’t have long enough exposure the picture will be dark, not blurry. Your statement makes it sound as if avoiding blur is why we need exposure time, which is a complete nonsense.

In reality none of this is a problem. There are automotive grade cameras which can collect enough light fast enough that the images are not blurry in practice. Yes, these cameras have a non-zero exposure time. Yes, this adds latency. No, this is not a problem.

> Your off the shelf library introduces a random 1 second delay for some reason and costs you 88 miles in processing time

You mean 88 feet. If my off the shelf library introduces a random 1 second delay i will chuck it in the bin post haste. Use stuff whose performance characteristics are well understood by you and is not terrible.

> Nearly every step of the way you discover you need specialized hardware, software, operating systems, sensors.

I do not recognise the world you describe.

> I do in fact work with self-driving cars. What you say is true, but it is not a big deal. Why do you feel this maters? Or what is your point?

Sorry not trying to dunk on you here, but this reads like something a junior engineer would complain to me about. These are not trivial problems, and I'm sure your co-workers who resolved them already so you didn't need to worry about them would agree with me.

> In reality none of this is a problem. There are automotive grade cameras which can collect enough light fast enough that the images are not blurry in practice. Yes, these cameras have a non-zero exposure time. Yes, this adds latency. No, this is not a problem.

You are contradicting yourself here, yes there are automotive grade cameras, but if this wasn't a problem, why would automotive grade cameras need to exist? My post wasn't saying these were impossible problems but hard ones.

> You mean 88 feet. If my off the shelf library introduces a random 1 second delay i will chuck it in the bin post haste. Use stuff whose performance characteristics are well understood by you and is not terrible.

Look I might have typed the wrong unit but it's a bit ironic you gave me this word salad right after complaining about this... Yeah you obviously don't use the library that adds a 1 second delay, but often you don't have the luxury of knowing that until after you learn about it through integration testing.

Libraries don't usually come with latency stats calibrated to your desired hardware right on the tin, would be pretty sweet if they did though.

> I do not recognise the world you describe.

I don't find this surprising :)

> These are not trivial problems

My complaint is that it is not clear why you think what you describe is a problem. You describe that by the time the next image arrives the car traveled a certain distance. And that is correct. But you imply that it is a problem without spelling out why it is a problem in your opinion.

You seem to assume it is so trivial to understand that you don’t even need to spell out the problem. But it is not. Because i don’t know what is in your head I can’t argue with the details of it. I know that whatever you feel is a problem is not a problem in practice.

Definietly not a problem you would solve by having higher frame rate cameras. So what I’m seeing is that you are unclear on the problem and jumping at a non-solution. One which adds other complexities without actually solving anything for you. And that is a certified junior engineer behaviour.

> if this wasn't a problem, why would automotive grade cameras need to exist?

Automotive grade cameras are special in their supported temperature range (they won’t die if you leave them baking in the sun) and their physical and electrical intefaces being resilient to vibration and electrical interference. You can point your smartphone out the window of your car and see that it can record clear images.

"My complaint is that it is not clear why you think what you describe is a problem."

Well, while you read, do the math in your head and think about what OP was trying to say. The point - latency is a cold and often uncalculated bitch that will screw with reliability and integrity of the system - got across to me quite easily. I was already on that page by the 4th sentence.

Ingenuity's wobble from a color vs bw frame is a great example of solvable but surprising latency problems along the way.

> while you read, do the math in your head and think about what OP was trying to say.

I did the math in my head. Before i read their comment in fact. Did calculations both on paper and spreadsheets too. Run simulations, and field tests too. Based on what i know i do not believe that the latency imposed by the frame rate of the cameras is a limiting factor on self-driving car performance or safety. I was asking to see if they have some particular scenairo in their mind to check if maybe i’m missing something. If anything I’m much more concerned about the latency of brake actuators.

> The point - latency is a cold and often uncalculated bitch that will screw with reliability and integrity of the system - got across to me quite easily.

Ah, ok. If we are just catching the vibes, then sure. The vibes are great.

> Based on what i know i do not believe that the latency imposed by the frame rate of the cameras is a limiting factor on self-driving car performance or safety.

This is would be pretty tangential to the discussion so not sure why you are bringing it up? Did you think my post was illustrating that camera based self driving cars were infeasible? Also it appears you are mistaking framerate for latency, something I specifically warned about in my post... I don't really know what to say here.

> Did you think my post was illustrating that camera based self driving cars were infeasible?

You said this line: “The car is traveling 1.5 feet between each frame interval” As I said before, this is a true statement. What I’m asking is what do you think is the significance of this value. You wrote it. It does indeed sound like you were saying this is an impediment, or at least a complication for implementing a camera based system. But I don’t know because you didn’t spelled it out, and I can’t read your mind. Hence I asked why do you feel that number is a problem. (If you don’t think it is a problem, just an interesting fact you wanted to share of course you can say that too.)

> it appears you are mistaking framerate for latency

I’m not. If you are measuring latency from “something is happening in the world” to “robot is reacting to it” then a component of that end-to-end latency is the time delay before your sensor captures a new measurement. That delay is a function of your framerate. This delay is only part of the full end-to-end latency. It appeared to me you were concerned about this delay and that is why you calculated how much the vehicle travels during this time.

> I don't really know what to say here.

I asked specific questions. If you would care to answer them we would be ahead. When i wrote “I can’t quite understand your comment.” that is not a retorical snipe. It literally means what i wrote: I do not understand your comment and I’m asking for clarification. I even quoted the bits which I don’t understand and asked my specific questions about them.

> This is would be pretty tangential to the discussion so not sure why you are bringing it up?

Because it seemed to me you were bringing it up in your comment. Or at least that is how i could interpret those few lines in your comment I was talking about.

Awesome post, illuminating metaphor, +1.

Tangent: why do so many people (even smart articulate ones like you) in our field (which involves precision with syntax and grammar) get apostrophes wrong?

"It's [IT IS] like its [ITS/HIS/HER/MY/YOUR/THEIR] own ecosystem..."

I anticipate downvotes for picking nits (let alone mentioning karma points), but FTR my intent is to help non-native English speakers (and mostly-literate English language-natives). Getting this "it's : its" distinction wrong is increasingly common and sometimes leads to signal loss.

Yesco, rereading your comment makes me slightly ashamed of this apostrophe rant, I hope others comment on the substance here. / end tangent

As someone who spent years doing web performance optimization for a living, your observations resonate. Beyond obvious low-hanging fruit, latency gains are rarely simple to achieve in practice; tradeoffs abound.

Ha yeah it reads a bit silly, to be honest I lazily typed my original post on my phone while sitting on a hammock outside, I didn't really review it much before posting. Autocorrect can make it challenging for me to do apostrophes correctly since it often overassumes my intent.

IME autocorrect costs me more time and keystrokes than doing without, so I always disable it (shrug)

different strokes...

To your tangent. When I was taught its vs it's, I was never given the association to his/hers/etc. It was just arbitrary and something you just had to memorize. Reading your post I am shocked I never made the connection earlier but it was just never knowledge I was provided with to work from.

Honestly I'm just a dumb web dev and even though many of our performance problems can be solved by horizontal scaling, there are a minority of cases where latency is important and that's when things get really fun :-) No more downloading random halfbaked libraries off the web, architecture starts to matter, vm settings start to matter, gateways/load balancers in the middle start to matter, even code optimization starts to matter again just like in good old days.

It's not the same.

For a simple example, let's say you are simply driving in a circle. The car wants to lean toward the outside. The linear motors can provide a countering force, lifting the outside, lowering the inside, so the car stays level. Variable damping can only control the rate that it rolls. It will still roll in sub-second timescales, unless it completely locks down the suspension, which is terrible for both handling and comfort.

For another simple example: going over a speed bump. Linear motors can lift the front wheels over the bump, and then the rear wheels, so the body stays level the whole time. An active damper can go full-soft the moment the wheel hits the bump, but the compressed spring will still start lifting the front of the car. An active damper can do a better job managing the rebound on the far side so it doesn't oscillate, but it can't entirely prevent the bump from pitching the body up and down in the first place.

That's not to say it's worthless. Very fast active dampers can improve both handling and comfort. It's just nowhere near the level which is possible with linear motors.

This is my biggest fear of technologies like these.

The whole point of a speed bump, for example, is to ensure that behaviour that puts others at risk will, at the very least make the driver uncomfortable. If we then deploy technologies that make speed bumps “disappear” from the perspective of vehicle occupants, it’s going to enable people to comfortably drive a lot more aggressively at the expense the people on the other side of the windshield.

Conversely, if we were to deploy technologies like speed governors, then we could do away with the speed bumps and the need for fancy suspension.

>technologies that make speed bumps “disappear”

My 2004 Land Cruiser has such technology. It's called "being a Land Cruiser". As a sports car fan, I'm quite familiar with how hard it is to make speed bumps that work for every vehicle. You're not wrong, but also it's a pretty crude technology, speed bumps.

The problem with speed bumps is that the level of annoyance is drastically higher for the already-slow prudent driver in a reasonable vehicle, compared to the lackadaisical latently-fast driver in an oversized monster SUV. So most of the intended targets get punished with "wow that was bouncy lol!" while the collateral damage gets comically slow crawling and/or frame damage. Speed bumps also draw the attention of drivers towards focusing on the obstacle, and away from staying alert for pedestrians.

I just had an experience with a parking lot (at a place generally full of kids), that had added a horrible speed bump at the entrance and then removed it a few months later. As far as I know there was no problem with people speeding in the lot, it was likely just some busybody trying to make things "better". Thankfully someone more in charge saw the light of reason.

> I've spent all morning doing a FEA analysis of their valve.

You did a finite element analysis analysis?

I knew someone was going to be pedantic when I wrote that.

I don't know if it's pedantic, I also have no clue what it stands for

RAS syndrome is not actually a problem, it's never actually misunderstood, in fact it usually adds clarity as redundancy in language usually does.

>You did a finite element analysis analysis?

That'd what it's called when you put the FEA in the circular file because the part is an inconsequential revision of something that's been in production forever and works fine.

Exactly what I came here to post. Mag fluid suspension has been mainstream for a while. Cadillacs aren't exotic.

I would guess this feels quite a bit different, the clearmotion tech puts electrohydraulic actuators in every corner of the vehicle and is proactively pushing and pulling wheels. MagneRide isn't even active (maybe semi-active, not sure) - never mind predictive and proactive.

except that this demo isn't ClearMotion, and instead of actuators they are using magnetic fluid and valvework...

much like every luxury brand has tried at least once or twice in the past 30 years.

The demo in the page of the "NIO ET9 SkyRide Fully Active Suspension system test"? - I presume they included that to show the legacy systems? If you do a technical dive through the CM technology it's clearly not just a magnetic fluid/hydraulic, this site gives a good breakdown: https://mf-topper.jp/articles/10003931

So...more like Mercedes' system?

Adjusting damping rates is very different from proactively lifting a wheel just as it reaches a bump.

Here's the Porsche way and it's actually available, today, if you go to a Porsche dealership and buy a Panamera with the active ride system:

(active ride begins at half the vid, at 1:17):

https://youtu.be/LU9s4q0FUS8

Or look the slalom at about one minute in the vid. That's not 3D.

https://www.youtube.com/watch?v=ELmY_HLtxTo