Sentry drain reduction coming?

[Dilly]

This popped up on Elektrek

Tesla works to slash Sentry Mode power usage by ~40%, and why that's bigger than you think — Electrek

Tesla is working on a software update to slash Sentry Mode power usage by ~40% – reducing “vampire drain” on parked vehicles.

apple.news

 

[TheMacMan]

Would be a welcome update by all.

 

[Cloggie]

I hope this is true! My car lost 5% over 12 hours yesterday with only 1 sentry event recorded

 

[Foxsbiscuits]

It would be nice. I'll believe it when I see it.

 

[CyberGus]

I always figured Sentry efficiency could be improved, such as by reducing frame rate and CPU speed until there is an event of interest.

 

[GeorgeSymonds]

I was under the impression the high energy use was because the whole autopilot and associated systems were kept awake which were pretty energy hungry. I guess they’ve either found a way, maybe the lower frame rate although I doubt that alone would save a lot of energy, or it’s something HW4 enables and they’re now looking to implement/activate in software but only for more recent cars

It would be kind of disappointing if they’d been able to do it on older cars for years and didn’t until now. Think of the amount of wasted energy they could have saved, but better late than never I guess

 

[Tony Hoyle]

Could be just mucking around with clock rates etc. but without a hardware revision I'd be surprised if they could save very much as they've never shown any ability to selectively shut down parts of the system before.

 

[CyberGus]

I don't know of any modern CPUs that run continuously at 100%, but they will when demanded. The key is reducing demand, but the trick is doing so "smartly" as to not impair function.

 

[Billbrown1982]

I don't know of any modern CPUs that run continuously at 100%, but they will when demanded. The key is reducing demand, but the trick is doing so "smartly" as to not impair function.

Think you hit the nail on the head. We will probably get some kind of implementation where the system shuts itself down and by the time its back up and running, the thing you wanted it to record has long since been missed.

 

[CyberGus]

Think you hit the nail on the head. We will probably get some kind of implementation where the system shuts itself down and by the time its back up and running, the thing you wanted it to record has long since been missed.

To be fair, it's not an impossible task. There are battery-operated security cams that last for weeks by throttling down between events.

I mean, FSD needs to react within a few milliseconds to drive, but 200ms while stationary should be fine, rite?

 

[GeorgeSymonds]

I’d have thought continuously processing the video images from multiple cameras to be able to trigger an event would take the most compute, and the record itself is a fairly small extra unless they’re continuously writing the video at the moment regardless of there being a triggered event. I’m pretty sure the cameras are dumb unlike home CCTV systems where they can locally process images to trigger an event.

Maybe that’s also why they introduced the option not to trigger an event unless an interior sensor went off (or something like that) so the cameras could be left of until needed, and all those things are now coming together.

I guess without actually knowing where the energy is going it’s hard to know what options there are to reduce it and whether the performance will be compromised. Be good if they can.

 

[Adopado]

Some of the posts here which refer to potentially lowering frame rates before a trigger are missing how Sentry works.

Sentry has to run at full resolution and frame rate all the time. This is so that when the actual trigger occurs the system can retain not only a record of that moment but also for the period leading up to the trigger point. Having that lead-in period at a lower quality means missing relevant context for the event.

The energy saving aspect has to focus on shutting down the many other CPU processes which are unnecessarily running by default.

 

[NewbieT]

If they can do it, save 5% across the entire global fleet and that’s a lot of electricity saved.

 

[ringi]

Sentry has to run at full resolution and frame rate all the time. This is so that when the actual trigger occurs the system can retain not only a record of that moment but also for the period leading up to the trigger point. Having that lead-in period at a lower quality means missing relevant context for the event

It only need to record movement before the trigger event.

 

[MrBadger]

Does non camera sentry mode use less power than traditional camera based sentry mode that is potentially not explained by not running front windscreen camera demist?

 

[brkaus]

To be fair, it's not an impossible task. There are battery-operated security cams that last for weeks by throttling down between events.

I mean, FSD needs to react within a few milliseconds to drive, but 200ms while stationary should be fine, rite?

Some of these use a totally different technology for motion detection. They use an IR motion sensor then fire up the recording when motion is detected.

The battery powered IR motion sensors can run for a year on a small cr123a battery.

 

[Adopado]

It only need to record movement before the trigger event.

The thing that triggers the event is not the only visual record required … for example another car’s number plate may be clearly visible as it moved towards your car but may not be visible at the point of impact or afterwards. I captured images of a couple of people messing around near my car but the trigger only came much later when there wasn’t much to see. When the lights flashed they jumped away but the full face visuals were all before that point.

 

[CyberGus]

Some of the posts here which refer to potentially lowering frame rates before a trigger are missing how Sentry works.

Sentry has to run at full resolution and frame rate all the time. This is so that when the actual trigger occurs the system can retain not only a record of that moment but also for the period leading up to the trigger point. Having that lead-in period at a lower quality means missing relevant context for the event.

The energy saving aspect has to focus on shutting down the many other CPU processes which are unnecessarily running by default.

I'm working under the assumption that capturing video is a small part of the power consumption, while most of the energy is being demanded by the FSD computer to detect events.

 

[Adopado]

I'm working under the assumption that capturing video is a small part of the power consumption, while most of the energy is being demanded by the FSD computer to detect events.

I suspect that neither of those aspects take much power. For all we know the computer could be running lots of other things that are standard for when the car is "on" and either driving along or about to drive but are not needed when parked and just running Sentry. If it wasn't initially designed to shut down individual elements there could be lots of scope for power saving. I believe this type of efficiency of shutting down unnecessary processes and hardware is common in modern laptops and phones.

 

[CyberGus]

I suspect that neither of those aspects take much power. For all we know the computer could be running lots of other things that are standard for when the car is "on" and either driving along or about to drive but are not needed when parked and just running Sentry. If it wasn't initially designed to shut down individual elements there could be lots of scope for power saving. I believe this type of efficiency of shutting down unnecessary processes and hardware is common in modern laptops and phones.

The FSD AI is computationally expensive.