-
运行cd amct_onnx_op && python3 setup.py build时,报错:...creating build/lib.linux-x86_64-3.7g++ -pthread -shared build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/custom_op_library.o build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/ifmr_kernel.o build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/quant_kernel.o build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/dequant_kernel.o build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/ascend_quant_kernel.o build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/ascend_dequant_kernel.o build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/ascend_antiquant_kernel.o build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/dequant_quant.o build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/hfmg_kernel.o build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/search_n_kernel.o build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/search_n_v2_kernel.o build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/dmq_balance_kernel.o build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/amct_utils.o build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/dump_kernel.o -L/home/mdc510/.local/lib/python3.7/site-packages/amct_onnx/utils/../lib -L/usr/local/python3.7.5/lib -lpthread -lrt -lc -ldl -lstdc++ -lquant_onnx -lpython3.7m -o build/lib.linux-x86_64-3.7/amct_onnx_ops.cpython-37m-x86_64-linux-gnu.so -Wl,-z,relro,-z,now -Wl,-z,noexecstack -fopenmp -Wl,-rpath,/home/mdc510/.local/lib/python3.7/site-packages/amct_onnx/utils/../lib/usr/bin/ld: build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/custom_op_library.o: Relocations in generic ELF (EM: 183)/usr/bin/ld: build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/custom_op_library.o: Relocations in generic ELF (EM: 183).../usr/bin/ld: build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/custom_op_library.o: Relocations in generic ELF (EM: 183)/usr/bin/ld: build/temp.linux-x86_64-3.7/home/mdc510/share/mdc_workspace/MDC_AS31XM1X_ACC_LIB/amct/amct_onnx/amct_onnx_op/src/custom_op_library.o: error adding symbols: file in wrong formatcollect2: error: ld returned 1 exit statuserror: command 'g++' failed with exit status 1排查时发现,onnxruntime的头文件没有问题。g++, gcc版本也没有问题,为9.4.0
-
为什么机器人总是在泊位处呆着不动然后两两在这里碰撞?有什么解决方法吗?
-
Prescan模型概览如下:一、车道线预瞄思路及代码解析初始化雷达探测器 检测雷达探测器工作状态。在扫描点序号680-800范围内寻找最近的障碍物,并标记其位置,msg.ranges[ ]储存了距离信息,下标i与扫描点的角度之间存在映射关系。计算并记录离小车最近障碍物的距离。当最近障碍物的距离小于0.8时,记录has_obs = True。先确定雷达避障状态,再执行小车的行为。基本原理:通过高速旋转及高频收发激光对平面进行采样,以前进正方向为采样角度θ零点,在连续的两个采样点间的夹角角分辨率为Δθ=ω/f≈0.25其中,ω为雷达转速,f为激光发射频率。二、激光雷达避障思路及代码解析定义如下:nwindows: 窗口数;window_height: 窗口高度;nonzero: 画面中所有不为0的像素点的坐标索引;lane_current: 当前窗口底边中点的x坐标;margin: 窗口底边长度的一半;good_inds: 所有处在当前窗口中不为0的像素点的索引;lane_inds: 当前跟踪的车道线上的所有像素点索引,即所有good_inds的并集。通过二次函数拟合出车道曲线。根据aimLanP的斜率正负来计算像素点的x坐标求车道线端点。计算目标点的真实坐标,其中红框部分是为了避免行人的存在所产生的误导。计算轮胎旋转角度。根据相机及雷达的打开状态控制小车的行为,其中初始值为FALSE。
-
环境:ROMA 22.2.0场景:通过三方原生系统调用统一服务、统一接入接口。即:可以通过postmain调用统一服务、统一接入接口进行二次开发或者测试结果:按照文档获取网关地址,请求接口不通请帮忙告知 针对这种情况,应该怎么操作获取正确的网关地址,可以实现能够通过本地程序或者postmain来调用统一服务、统一接入的接口,在线等,谢谢!
-
请问,如果要采购MDC系统设备应该怎么联系呢?标书上面有这款产品,所以想要了解下
-
基于【NPU+AI ISP】方案开发边缘计算数据盒,对标Hi3559A平台边缘计算数据盒性能全面提升,引用达芬奇新DaVinci架构,双NPU组合,算力提升一倍,支持MindSpore AI开发环境,平滑升级无压力,避免因不同选型导致移植周期过长,可以无缝切换快速落地应用,减少运维成本,且供货保持稳定,是升级Hi3559A平台边缘计算方案的最佳选型。最新发布的SDK版本把双核NPU(4T+6T)都开放出来,但两个NPU核底层的模型和配套工具有区别,如果做边缘计算数据盒开发,总算力可以到10T。开发AI摄像机如需使用6T的NPU核,可使用最新的SDK版本升级成在程序运行时通过软开关来控制启动,实现白天用6T NPU核来跑其它算法,夜间启动AI ISP的最优状态。视频编解码均支持行业领先的H.264、H.265标准,解码最大可支持10路1080p@30fps,编码最大可支持4K@70fps,SoC具备PCIE的桥接功能,可以通过2颗芯片桥接支持4路4k的接入。编解码整体性能优异且稳定,降低网络波动带来的影响,带AI ISP优化视频画质,输出超高清且细腻画质的同时保持画面高度流畅性。
-
1)德赛西威基于多SoC芯片的舱驾融合方案2022年4月,发布车载智能计算平台“Aurora”—— 实现从了从域控制器向中央计算平台的跨越。在硬件层面,该中央计算平台搭载英伟达Orin、高通SA8295和黑芝麻华山A1000三大SoC芯片;在功能层面集成智能座舱、智能驾驶、网联服务等多个功能域;在结构形式上采用插拔式结构 —— 算力可伸缩配置,用于满足不同价位车型的多样化需求。 2)创时智驾基于多SoC芯片的舱驾融合方案(据推测)在硬件层面,正在规划两类高性能的舱驾一体域控制器:基于J5系列芯片和基于Orin系列芯片;在软件层面考虑采用成熟的中间件软件平台、支持多域融合的CarOS软件框架和支持应用软开发的安全组件产品Safety Copilot。3)中科创达A.基于高通SA8295的舱泊融合方案(座舱和泊车功能融合)2022年初,发布基于高通SA8295芯片的硬件平台,实现一芯多屏座舱域控方案,并在高算力(CPU算力200K DMIPS、GPU算力3000G FLOPS、 NPU算力30 TOPS)和多摄像头支持能力下,实现座舱和低速泊车功能的融合,支持360°环视和智能泊车功能。B. 基于高通SA8795芯片的舱驾融合方案(座舱和智驾功能融合)基于高通SA8795芯片(预计,CPU算力240K DMIPS、 NPU算力60 TOPS)布局座舱和智能驾驶的跨域融合方案,并计划于2024年实现量产。转载于汽车电子于软件微信公众号
-
以下文章来源于远川汽车评论 ,作者熊宇翔自动驾驶的寒风从Robotaxi吹到了激光雷达。一周前,全球首家激光雷达上市公司Velodyne宣布与另一激光雷达初创Ouster合并,行业为之震撼。Ouster的创始人出自另一知名激光雷达公司Quanergy,是一家试图以“固态”激光雷达颠覆行业的初创。而Velodyne则是行业曾经当之无愧的霸主,其生产的“大花盆”(机械式激光雷达)几乎是行业的图腾。但寒冬之下,地主家也没有余粮。两家公司称,投资人对自动驾驶的热情正在消减,必须抱团降本增效。双方合并后,将手握3.55亿现金, 市值约4亿美金,在此之前两家公司的股价已经跌去超过80%。据称该合并的实际情况是Ouster低价并购Velodyne。相比之下,国内激光公司虽然都还处于赔本赚吆喝的阶段,但因为有融资在撑着,日子也算过得滋润,以速腾、禾赛和图达通为代表的企业都已经绑定了小鹏、理想、蔚来这样的大客户,各种技术路线也在百花齐放,鹿死谁手,尚未可知。那么,曾经制霸行业的Velodyne是怎么沦落到要被并购的?其他公司又能够绕开Velodyne的坑成功上位吗?激光雷达行业最大隐忧又是什么?01 霸主陨落Velodyne堪称激光雷达行业中的传奇。2005年,美国音响大亨、Velodyne创始人大卫·霍尔了解到美国国防部发起的无人驾驶挑战赛,决定躬身入局,为无人驾驶汽车研发新的传感器,一出手便开发了64线机械式激光雷达HDL-64,性能远超原本被广泛使用的单线激光雷达,效果立竿见影。短短两年后,在新一届无人车挑战赛中,共有6款车完赛,其中5款安装了Velodyne的HDL-64,包括揽得冠亚的车队[1]。这场比赛成为美国乃至全球自动驾驶产业化的滥觞,参赛人员日后成为谷歌、Uber、福特等公司自动驾驶项目的中坚力量,Velodyne也近水楼台,开始了对车载激光雷达的10年统治。图达通的CTO李义民曾说,如果不是霍尔,全球自动驾驶行业的发展要延误10-25年。在2017年以前, Velodyne基本垄断高性能车载激光雷达,其HDL-64即便报价8万美元,主要是因为全机械部件需要人工调校,耗时耗力,但即便如此,仍是有价无市,黑市上的价格一度炒到200万元左右。2016年,百度向Velodyne投资7500万美元,只为获得优先提货权。那段时期,自动驾驶每年新增多少测试车,取决于Velodyne生产了多少枚雷达。但在2016年开始的自动驾驶创业热潮中,全世界都意识到激光雷达的前景,几年之间数十家初创涌入。在饱和的竞争下,Velodyne的王朝迅速衰退。在竞对中,最让Velodyne头疼的是两家中国公司:禾赛与速腾聚创。2017年,禾赛科技推出40线激光雷达,同年速腾聚创16线激光雷达量产,两家公司分别在中高、中低端与Velodyne开展竞争,以中国公司擅长的性价比争夺客户。次年,Velodyne的16线产品应声降价50%。但禾赛、速腾继续扩大份额。2019年,Velodyne发起专利诉讼,但禾赛、速腾在缴纳不菲专利费用后继续高歌猛进。2020年,当Velodyne以激光雷达第一股的身份,在美股勉强SPAC上市时,全世界卖得最好的激光雷达其实是禾赛。禾赛不少客户如百度、文远知行是从Velodyne倒戈而来,原因不仅仅是价格,还有更快的产品更新和售后服务。相较于禾赛,Velodyne在中国只设销售部门,服务支持能力孱弱,文远知行COO张力就曾吐槽,Velodyne的激光雷达返修要寄到海外,全程需要1-2个月,而国内的公司可以提供7x24小时的保姆式服务,甚至是7天包退换。而技术的更迭让Velodyne的处境变得更糟。2020年后,乘用车智能驾驶的加速普及,催生了对车规级激光雷达的需求,这是一片大得多的蓝海市场。但传统机械式激光雷达内部零件成百上千,且有大量活动部件,可靠性无法满足车规,减少活动部件的固态/半固态激光雷达呼之欲出。其实Velodyne早已看清趋势,2017年便发布固态激光雷达原型产品,2020年又发布了“量产版本”。然而Velodyne并无固态激光雷达的生产制造经验,公司管理层在上市后内斗,创始人霍尔也被爆料疏于管理[3],直到今天,Velodyne的固态激光雷达也没登上量产车。在车企的固态激光雷达定点订单中,Velodyne份额仅2%。Velodyne转型固态激光雷达的失利直接导致霍尔去年被董事会驱逐,管理层换血。与此同时,Velodyne本就不多的汽车行业客户还很“佛系”,他们对激光雷达上车的时间表多排在2023年甚至更晚,远不如国内车企这般激进。上市之后,Velodyne陷入持续亏损。多重利空之下,Velodyne江河日下,只能抱团取暖。Velodyne的遭遇其实只是一个缩影。去年以来,美股上市激光雷达公司股价普跌80%以上,不仅Velodyne被迫与Ouster合并,另一家Quanergy更是暴跌99%,惨被纳斯达克除名。当太平洋东岸的业绩一泻千里,太平洋西岸的量产则稳步推进。幸运的是,中国激光雷达厂商的种子客户是天然卷的造车新势力。在蔚小理狂热的智能驾驶竞赛下,自2021年以来,速腾、图达通、禾赛的固态/半固态激光雷达相继登上小鹏、理想、蔚来的量产车型。在这三对合作中,新势力都对激光雷达的产品定义进行了深度介入。其中蔚来更是亲自上手,设计了图达通猎鹰的电路板。Velodyne实际上输给了大洋彼岸充满危机感和战斗力的命运共同体。但行业远未到胜负已定的时刻。如果说车载激光雷达的商业化是一场100公里负重越野马拉松,那些跑在最前面的玩家,也才刚刚冲过了第一个检查点。02王座无人Velodyne的遭遇是一个残酷事实:尽管它比很多公司早将近10年进入行业,却没有什么护城河。其中的原因当然有管理、商业乃至政治的,但归根结底是技术的:过去几年中,车载激光雷达的主要市场从Robotaxi向乘用车迁徙,形态从机械旋转式转向固态/半固态。以机械激光雷达起家的Velodyne,未能顺利完成这场高难度的技术与产品重构。但那些将Velodyne赶下王座的挑战者们同样如履薄冰。因为整个行业的技术路线多样,且快速发展、切换,尝试构筑壁垒的技术豪赌,很可能会变成一场输光底裤的梭哈。这种不确定性具体表现为,在激光雷达的各项关键技术中——从测距模式,到激光发射、扫描、接收模块,几乎每一项都没有收敛出一个最优解,而是有多条各有优劣的道路供企业选(du)择(bo)。由此,行业中出现了百花齐放的场景:行业中有数十家公司,而几乎每家公司都通过技术排列组合,拿出不同于别家的方案。典型的例子是,激光雷达“国产三杰”禾赛、速腾、图达通的首款乘用车激光雷达AT128、M1、猎鹰虽然前后脚上车,但技术查重率很低。其中速腾M1偏向使用更成熟的零部件,已多次迭代提高部件集成度,理论成本低,适合扮演价格屠夫。禾赛AT128在光源上启用了新的VCSEL阵列,追求零部件的半导体化,尽量减少运动部件,有利于产品可靠性。图达通猎鹰则讲求大力出奇迹,用更大的体积、功率(以及更贵的零部件)换取更高的性能,看得更远,分辨率更高。在数十乃至上百万台激光雷达交付验证前,没人知道哪家的方案会胜出,或者三者会划分出市场的三个档次,抑或其他公司携突破性技术将他们扫进故纸堆——火热的激光雷达从光学、光通信、半导体延揽了大量人才,这不是一个缺少新技术的行业。对激光雷达企业来说,更确切的答案是尽快以足够低的成本登陆更多的智能电动汽车,并保证这种精密光学设备在复杂车辆环境上的可靠性,尽可能让自己的方案成为事实上的行业标准。因此,跑在前列的激光雷达企业聚焦于两个关键词:工程化与制造。禾赛科技CEO李一帆在接受《九章智驾》访谈时称, 禾赛负责工程化的CTO向少卿统管上千人,而他与首席科学家各管百来人。去年5月,禾赛投开始自建“麦克斯韦”激光雷达超级工厂。无独有偶,速腾聚创上周也与立讯精密成立合资制造公司“立腾创新”——两者试图带头将无休止的技术竞赛拉回精密制造的量产比拼。即便如此,激光雷达短期内仍然是一门烧钱的生意。禾赛麦克斯韦超级工厂投资2亿美元,规划年产能百万台。今年9月29日,禾赛才宣布车规激光雷达的月交付量刚刚突破一万台——这已经是速度最快的头部玩家。而在2天后,特斯拉一年一度的AI Day召开,马斯克把寒气传递给了每一家激光雷达公司。03最大敌人 并非同行一个容易被忽略的事实是,激光雷达公司们最大的敌人不是同业的竞争对手,而是摄像头,更准确地说,是那些研发纯视觉自动驾驶的公司,特斯拉是这一阵营的话事人。在过去几年中,马斯克多次Diss激光雷达,认为后者是自动驾驶的“拐杖”,任何依靠激光雷达的人都会失败。但一直以来,大多数从业者对激光雷达的态度都是“你喷你的,我用我的”。这是因为,不要激光雷达的纯视觉自动驾驶高度依赖深度学习,在环境感知上一度存在重大缺陷:一方面,摄像头本身并非全天候传感器,雨雪雾天与夜间难以正常工作;另一方面,在此前的视觉算法框架中,被摄像头拍到的物体必须被识别,才能被系统认为存在。这导致纯视觉自动驾驶在应对没训练过的障碍物、静止物体时表现极不稳定,常常漏检、误检。而激光雷达无需经过训练,也能通过准确的测距探测到障碍物,为自动驾驶提供保障。因此,智能驾驶行业此前的主流看法是,应该搭建多传感器融合的感知系统,让摄像头与激光雷达优势互补。然而,激光雷达的硬件优势正在被特斯拉通过软件算法的优势渐渐拉平。在今年AI Day上,特斯拉详尽介绍了占用网络(Occuppancy Network),这一算法能够基于二维图像,高精度高实时性地还原三维世界,不仅能感知物体的体积,也能判别其动静状态。这与激光雷达的能力实质上没有什么不同。上图为激光雷达感知,下图为占用网络感知如果摄像头能够成为激光雷达的平替,后者的生存空间将岌岌可危。理想今年在大力加码基于视觉感知的智能驾驶。而在占用网络公开后,理想更是率先长他人志气——CEO李想在微博上称,激光雷达的本质就是占用网络。据说小鹏智能驾驶负责人吴新宙也私下告知激光雷达厂商,要准备转型。不过,行业中并不全是特斯拉的追随者。到今年年中,速腾聚创拿下了超过40个激光雷达车型定点,禾赛也声称,来自主机厂的前装定点有数百万台之多。更多的车企则在观望:激光雷达用不用,取决于它够不够便宜,性能够不够稳定。在此之前,车规级激光雷达的价格已经从上万元,被压缩到了3000余元,但相比于几百元一枚的高清摄像头,激光雷达的身价仍然让绝大多数车型难堪重负。将价格再降一个数量级,是车企们对激光雷达的殷切希望,也是大规模装车的前提条件。一场摄像头与激光雷达相互偷家的暗战实际上已经打响。激光雷达的战略目标是降本,按照李一帆的展望,激光雷达最终的价格将是摄像头的2-3倍[4];而摄像头的战略目标则是提效,让视觉算法精度、置信度更高,尽可能逼近激光雷达。当下,两者共存的声音仍是主流,但在这场竞速赛中,作为新兴传感器的激光雷达面对着更大的隐忧——历史上决定一项新技术兴衰的首要因素常常不是其理论性能的先进性,而是对既有技术、设施的调用能力,翻译一下就是,生态。比之激光雷达,摄像头的生态完善而庞大。基于图像的计算机视觉向来是AI显学,传感器(摄像头)的保有量最大,数据量最多,人才最为密集。这种优势直接继承到了智能驾驶领域,眼下绝大多数智能驾驶功能,都是由摄像头+视觉算法完成,或者至少以摄像头为主。这带来的是完整的数据闭环,以及视觉算法极高的进化速度。相较之下,激光雷达的生态建设尚在初级阶段,数据与人才更少,算法也更加稚嫩。甚至于,因为人眼熟悉的是图像而非点云,造成激光雷达的数据标注效率要比图像更低,要价更高:一幅图像的标注通常耗时数十秒、开价几毛钱,而一幅激光雷达点云的典型标注成本则是数分钟、十元起[5]。这些差异的根源可能要追溯到文明形成甚至人类的远古祖先进化出眼睛。特斯拉前AI总监Andrej 近日在一场播客中称,人类打造的人工世界,是从便于人眼感知的角度出发而建,视觉传感器天然地会因此居于核心地位。想明白了这一点的特斯拉,每年都在突破视觉智能驾驶的天花板,就在三天之前,特斯拉开始在北美推送FSD V11。这意味着激光雷达要打一场不对等的战争。面对快速进化的对手,激光雷达如果要在自动驾驶中争得一席之地,需要跑得更快,与下游的合作更加紧密,尽快突破“成本、性能和稳定性”的不可能三角。转载于汽车电子与软件微信公众号
-
智能汽车高级驾驶辅助系统我将其细化为十大员,全面覆盖汽车智能化各个领域,是以后汽车智能化智慧化的研究方向和细化塞道。其中在智能汽车监管系统方面,针对公车监管、出租车监管、共享汽车监管、两客一危车辆监管系统等等,有有一套可让交管部门事后处罚式被动监管变事前限定式主动监管系统。其中最基本最简单的一种创意技术是一种车用安全带智能监管系统。该创意技术能使中国安全带的使用率由现在的30%提升到90%,超越M国的80%。原理合理、结构简单、成本低廉,适用国家交管部门强行推广和车企市场竞争。
-
2020年10月30日,华为Mate40发布会在万众瞩目中隆重召开。在这场发布会上,HUAWEI HiCar将华为全场景能力,带入到车载系统中,让手机与汽车快速连接,带来精准便利的语音操作体验,让智慧出行更便捷。华为云会议强大的音视频以及全平台开放的能力,结合HUAWEI HiCar全场景分布式技术,把手机和汽车的硬件资源、系统能力快速融合在一起,打造跨设备的无缝流转体验。手机共享车机的硬件设施,如车载大屏、摄像头、音响等,促进手机和汽车之间的互联互通,提升用户在汽车座舱内的使用体验。华为云会议,结合智慧办公和智慧出行,在继智能会议室、智能经理室、家庭智慧屏开会之后,又将智能延伸到了汽车上。在华为云会议的全场景里,在会议室用会议宝开会,在办公室用电脑开会,在家里用智慧屏开会,外出时用手机开会。以前,在车里也只能用手机开会,当华为云会议结合HiCar智慧出行后,手机与车机连接后,手机App端预约的4小时之内的会议,将呈现在汽车显示屏上,方便一键点击入会。当您边走边用手机开会,到了车上,车载大屏自动与手机连接,感应到手机上正在开视频会议,也会自动识别出会议应用卡片,只需轻轻一点,会议无缝转移到车载大屏上,同时调用车内摄像头和音响,此时,您的爱车便是您的移动会议室啦。在停车场、有司机驾车,以及未来自动驾驶场景,都可以让您拥有更好的视频开会体验。华为云会议,支持全系列终端一键接入,会议全场景无缝流转,让您无论身处何地,都可以享受最优的开会体验。华为云会议全平台开放,也将联合伙伴,探索更多创新场景,适配更多行业应用,让沟通更简单,让协作更高效,让智慧一路相随。转载:IT168
推荐直播
-
全面解析华为云EI-API服务:理论基础与实践应用指南
2024/11/29 周五 18:20-20:20
Alex 华为云学堂技术讲师
本期直播给大家带来的是理论与实践结合的华为云EI-API的服务介绍。从“主要功能,应用场景,实践案例,调用流程”四个维度来深入解析“语音交互API,文字识别API,自然语言处理API,图像识别API及图像搜索API”五大场景下API服务,同时结合实验,来加深开发者对API服务理解。
去报名 -
企业员工、应届毕业生、在读研究生共探项目实践
2024/12/02 周一 19:00-21:00
姚圣伟 在职软件工程师 昇腾社区优秀开发者 华为云云享专家 HCDG天津地区发起人
大神带你一键了解和掌握LeakyReLU自定义算子在ONNX网络中应用和优化技巧,在线分享如何入门,以及在工作中如何结合实际项目进行学习
即将直播 -
昇腾云服务ModelArts深度解析:理论基础与实践应用指南
2024/12/03 周二 14:30-16:30
Alex 华为云学堂技术讲师
如何快速创建和部署模型,管理全周期AI工作流呢?本期直播聚焦华为昇腾云服务ModelArts一站式AI开发平台功能介绍,同时结合基于ModelArts 的实践性实验,帮助开发者从理论到实验更好地理解和使用ModelArts。
去报名
热门标签