V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  cenbiq  ›  全部回复第 1 页 / 共 12 页
回复总数  235
1  2  3  4  5  6  7  8  9  10 ... 12  
10 小时 58 分钟前
回复了 aweim 创建的主题 随想 世界真的是空吗?
我感觉双缝干涉应该是被误传了,还有那个薛定谔的猫,人家原本想表达的重点是量子叠加态的宏观矛盾体现,现在传来传去已经是“未知状态”的代名词了
@cenbiq 然后给定 S=4 (每类 4 个) P=3 ( 3 类传感器),求 C 的收益最大化临界值,它给的结论是

- 当 C < 37 ,提升 C 的收益更大,优先优化决策与规划能力(如更好的 AI 训练、强化学习)。
- 当 C > 37 ,感知能力的提升开始逐渐接近甚至超过 C 的提升收益,合理分配资源。
- 当 C >= 60 ,感知能力的提升变得更有价值,因为决策系统已经足够成熟,可以利用更丰富的感知数据。

并最终建议

对于 S = 4, P = 3 这样的较强感知系统:
- 如果 C < 37 ,应该主要投入资源优化决策与规划能力。
- 如果 37 <= C <= 60 ,可以同时考虑提升感知能力,但提升 C 仍然更重要。
-如果 C >= 60 ,感知能力的提升成为主要瓶颈,应重点优化传感器融合、数据处理能力等。

结合 GPT 的意见,再考虑到融合传感器带来的成本,尤其是考虑到目前 FSD 方案下纯视觉完全没有融合传感器的情况(这可能放大了融合的成本),FSD 极有可能目前仍然认为提升 C 值更具有性价比(并可同时提升 S 来放大 C 的收益,只要不提升 P 也就是传感器维度成本不会爆增加,也就是不融合其它传感器只是加强学习驾驶和增加摄像头,如果 FSD 如此,那么其它投入更小的自动驾驶方案呢?),但这也预示着最终提升 C 、S 值不再具有性价比,到时 FSD 必然只有提升 P 这一个选项,也就是增加传感维度。
@param 我找 GPT 大致推导了一个公式,D=C/100·(1+a·S·P)。S 为传感器量化数,P 为传感器类型维度; S·P 为总体感知能力; a 为感知能力对驾驶水平的影响系数 GPT 提示约为 0.02~0.05 ;
@param 是的,我虽然不是行内人,但也能大致理解到自动驾驶存在两个方面,一是驾驶理解能力( 0-100 分,可以假设 60 分为拟人也就是等同于成年人对驾驶的理解),二是感知能力(最低拥有两个摄像头则类似人的水平)。如果驾驶理解能力不足( 6 岁孩童),那么给他增加感知设备带来的总体驾驶水平收益可能是极低极低的,甚至可能是负担。
@shunia 行我明白了,你的结论基于你认为纯视觉的 FSD 和其它家方案不存在差距,或则存在高于 FSD 水平的差距,那么可以看下 [FSD 对比 ADS 被吊打,第三梯队果然不过如此-哔哩哔哩] https://b23.tv/sBAgVoy FSD 国内版本和 ADS 同路段日常小路对比,我想开过几年车的应该都能看懂。
@shunia 但国内自动驾驶即使使用了多维感知方案却仍和 FSD 有差距,这是否说明纯视觉仍然有较大空间?现在存在一套纯视觉自动驾驶方案 > 几乎所有其它多维/纯视觉自动驾驶方案,那么关键因素在哪难道不明确吗?
@shunia 但如果总和其它传感器带来的总成本投入(考虑批量生产和额外算法成本)分配到纯视觉方案算法升级带来的智能收益 > 仅投入传感器和相应算法所带来的智能收益呢?
我发现这个论坛似乎很多人没法理性思考了,自动驾驶是一个多加一个传感器就多厉害一分的事吗?显然并不是吧。纯视觉方案还远未达天花板,在这之前当然可以引入激光雷达,但问题是你的本职工作自动驾驶这个事你还没能解决的很好,多引入一个两个传感器会有什么质的变化吗?一旦纯视觉接近天花板,给纯视觉巨大的投入也只能得到非常微不足道的回报的时候,再考虑如何引入并融合其它传感器来提升智能才是最佳时机。
6 天前
回复了 somebodybbb 创建的主题 汽车 GLC 300 和 YU7 怎么选?
不懂为什么喷 1 楼,感觉有些人似乎逻辑能力非常不过关,甚至还有说 1 楼说话不看场合这种问题的,我觉得 1 楼是典型的说话看场合的正面案例,OP 问 GLC 和 YU7 的选择,1 楼简单引用近期新闻不带任何情绪渲染去提醒 OP 选择 YU7 可能带来的风险,这不是非常合理且符合时宜的言论吗?
@nmap .net fx (~2016 ) > .net core ( 2016~2020 ) > .net ( 2020~)
为什么会有线程和协程哪个快这样的问题?当然是线程执行更快啊。能说出协程更快的怕是连协程是干什么的都没搞明白,协程对于开发更好用是因为协程帮助开发者自动化的管理了线程的利用率和上下文切换时机。这对于高频 IO 类型的程序更加友好(尤其是对于做应用层开发而言),让人产生了协程更快的“错觉”,应该说协程让整体系统资源运行更协调,而不是更快。
@arthas2234 我有肝病基础,印象中医生从没给我开过中成药
45 天前
回复了 cjlalalala 创建的主题 Web Dev API 请求体字段定义询问各位大佬。
从更标准的开发方式来说,肯定是接口算接口的,存储算存储的
这辈子忘不了曾经登录彩虹岛看到那个缤纷多彩新世界的快乐
74 天前
回复了 Niner 创建的主题 Java update 大家会允许这样写吗?
如果你用 C# ef orm ,官方就是推荐这么写的,但是 ef 自带乐观锁支持和 patch 更新,改了什么字段就更新什么字段
82 天前
回复了 magic3584 创建的主题 Android 如何入门 Android 开发
compose ,老的那套别学了,我也是前端兼容会写 Android ,写 compose 贼 6 很像 react hooks ,老的那套 xml 、adapter 什么的写不了一点,而且也快淘汰了
1  2  3  4  5  6  7  8  9  10 ... 12  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1306 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 33ms · UTC 17:29 · PVG 01:29 · LAX 10:29 · JFK 13:29
Developed with CodeLauncher
♥ Do have faith in what you're doing.