betaflig/inva/cleanflight,没用rtos,但是有任务及任务调度,好奇为何不用freertos。
px4用的nuttx,看不懂,也不想学,放弃...
有的飞控好像用了chibios
正点原子提供的atkflight,用了freertos.
好奇,觉得freertos应用比较广了吧,为何这么多飞控用freertos的这么少。
最近编辑记录 Gentlepig (2023-12-09 10:18:08)
离线
看了一点atkflight源码,好像就是把betafligth的流程,用freertos实现了一遍。
离线
APM:裸奔
Pixhawk:Nuttx
MWC/Naze32:裸奔
Openpilot:PIOS
Autoquad:CoOS (an embedded real-time multi-task OS specially for ARM Cortex M series)
Paparazzi:ChibiOS匿名飞控:
RT-Thread(国产飞控+国产RTOS)
Crazyflie:FreeOS
https://www.zhihu.com/question/28981423/answer/51314550
知乎上看到的。
另,遥控器,有哪些开源硬件?指的是pcb及原理图也公开了的。
最近编辑记录 Gentlepig (2023-12-11 15:33:56)
离线
不要以自己的立场感受为常识。比如,从事Linux底层的人对nuttx就会很熟悉并觉得freertos功能太少。
像小米就选nuttx作为他们产品的RTOS,明显是因为他们的团队以前是搞手机系统的,众所周知,手机系统内核是Linux。
确实,自己了解的还是太少太片面了。nuttx之前只是见到过这个名字,chibios是第一次见到...
是不是不少rtos也兼容posix? rtt好像支持吧,微软的threadx是不是也兼容呢?
------------------------------------------------------------
搜到了这个:
为什么选择NuttX?
市场上开源或商业的RTOS非常多,为什么我们最终选择NuttX作为Xiaomi Vela的基础?主要有以下几个原因:
NuttX对POSIX标准有原生兼容:NuttX是可商用化RTOS中唯一一个对POSIX API有原生支持的实时操作系统,所以很多Linux社区的开源软件可以很方便的移植到NuttX上,这样可以极大的简化开源软件移植,方便代码复用,降低学习曲线,其它RTOS需要适配层把POSIX API转成内部API,而且通常只兼容一小部分的POSIX接口。
完成度高:NuttX集成了文件系统、网络协议栈、图形库和驱动框架,减少开发成本。
模块化设计:所有组件甚至组件内部特性,都可以通过配置Kconfig来调整或关闭,可按需对系统进行裁剪,适用于不同产品形态。
代码精简:所有组件都是从头编码,专门对代码和数据做了优化设计。
轻量级:虽然NuttX实现了传统操作系统的所有功能,但是最终生成的代码尺寸还是可以很小(最小配置不到32KB,最大配置不超过256KB)。
和Linux系统的兼容性:因为NuttX整体设计、代码组织,编译过程和Linux非常接近,将会极大地降低Android/Linux开发者的迁移成本。
活跃开放的社区:很多厂商(比如小米、Sony,乐鑫、NXP等)和开源爱好者都在积极回馈社区。
最近编辑记录 Gentlepig (2023-12-11 15:51:04)
离线
强事实控制系统裸奔最好,引入一个组件就会增加额外的风险
离线
@海石生风
我写过很多数字电源电机控制项目,也见过无数类似实时控制系统的代码,都是强实时控制系统,都是裸奔。原来你是写飞机、导弹、飞船代码的?失敬失敬。顺便请教下,你们飞机、导弹、飞船用几个CPU/MCU?都用什么系统?电动自行车用一个MCU,电动滑板车用3个MCU,都是裸奔。比较简单的汽车要用50-100个MCU。
最近编辑记录 echo (2023-12-16 10:30:00)
离线
飞控都是不用os的,主要是为了可靠性和实时性。
包括现在在役的战斗机,都是如此。
离线
@Gentlepig
狭义的APM跑在8位arduino上,确实是裸奔(但是实现了一套任务调度而且甚至今天的ardupilot也还在用。。)
广义点的APM(ardupilot)大致14-18年跟随px4用的nuttx,后来转了chibios(大概是ardupilot团队嫌弃nuttx太重,不选freertos可能也有性能考量)
然后最近有一款fmt国产飞控也不错,国产团队,用的rtthread也是国产
px4其实没啥说的,出的比较早,那会应该nuttx相对完善一些,而且px4架构设计得好,方便在Linux是跑(高通早期出过骁龙的飞控套件就跑的px4)
离线
国外的VxWorks,RTEMS,ECOS那些就不提了。 国产的嫦娥也有在用操作系统,前一阵子不是报道的挺火的吗。SpaceOS
还有多一嘴,战斗机有上N个实时系统,冗余再冗余。好多资料都是网上公开可查的,实在懒问下chatGPT也能有答案
离线
引入rtos往往会增加系统复杂性,竞争条件,死锁。。。然后投降并放一个看门口了事。。。不建议鄙视裸奔
前年在某公司接手前辈工程师的项目,是裸奔系统,其中有一个 control.c 差不多 4000 行,,,后来。我做了这个
https://gitee.com/everlink/ee_core
相当于裸奔前提下穿一条丁字裤,然后一个control.c 化身成二十几个文件
我发现,很多做了好久单片机的同学,没有听说过竞争条件,却很懂各种RTOS
离线
@EE
起初是裸机,由于对可靠性要求极高,于是最起码要对不同任务进行内存地址隔离。隔离后,不同任务间要通信,就是要做通信组件;还要监控不同任务是否正常运行,如果异常就要做最小损失处理。还要对整个任务系统进行备份(我国当前的航天器已经做3套备份了)。
这些东西做下来,就不由自主地变成一个OS了。
顺便一提,经常飞越星际的VxWorks已经支持“容器”这个虚拟系统的概念了,将实时性要求不高又容易出错的任务跑在容器里,以隔离其对整个系统的影响。
航空航天的可靠性要求不是民用的能比的,而航空航天系统又越来越复杂,肯定要对硬件资源进行管理,这一管理就变成一个OS了。
这不是为了OS而上OS,而是无奈地成为了OS。
离线
@海石生风
可靠性要求每一行代码都是可控的,引入一个未知组件都有额外的风险。如果要引入,要评估带来的益处和引入的风险。
如果要引入RTOS,一种可能的场景是要用某些现成的软件组件,比如网络,比如文件系统之类。
题主都已经说了,飞控源码用freertos的少,不用肯定是有原因的,至于背后的原因,自己多踩一些坑就理解了。
题主看到的是开源的飞控,闭源的飞控就更不用说了,各个公司最好的飞控代码肯定不是开源的。
离线
@echo
少在那误导了。
https://baike.baidu.com/item/Rtems/6985412
https://baike.baidu.com/item/vxworks?fromModule=lemma_search-box
看看哪个不是用在可靠性极高的地方。
离线
@echo
少在那误导了。
https://baike.baidu.com/item/Rtems/6985412
https://baike.baidu.com/item/vxworks?fromModule=lemma_search-box
看看哪个不是用在可靠性极高的地方。
你自己多踩一些坑就明白了
离线
@echo
rtos本身就不适合数字电源、电机控制这些应用, 这些应用要很快的响应速度,可能是微秒或纳秒级的。rtos解决的问题不是快,而是多个复杂任务的时间确定性。
要论快当然裸机最快,但很多时间不需要那么快。
离线
@echo
rtos本身就不适合数字电源、电机控制这些应用, 这些应用要很快的响应速度,可能是微秒或纳秒级的。rtos解决的问题不是快,而是多个复杂任务的时间确定性。
要论快当然裸机最快,但很多时间不需要那么快。
能得出rtos不适合数字电源这种结论,其实是原于对RTOS不了解,因为当需要微秒或纳秒级响应的时候,往往是通过硬件中断来保证的,与是否存在RTOS没有关系,RTOS一般情况是不接管硬件中断的,任务调度的优先级比所有其他硬件中断都要低。
离线
regbbs 说:@echo
少在那误导了。
https://baike.baidu.com/item/Rtems/6985412
https://baike.baidu.com/item/vxworks?fromModule=lemma_search-box
看看哪个不是用在可靠性极高的地方。你自己多踩一些坑就明白了
那么裸机也一样有坑,也一定会踩坑的。
RTOS的坑和裸机的坑不一样,以及在DEBUG时候是不一样的。
那么多航空航天军用设备都可以用RTOS,这种可靠性实时性要求高的都可以用,你哪来的自信说裸机是更好的选择。
离线
楼主看ardupilot呢,这个他自己搭了一套框架,底层HAL层适配了很多OS,有裸机,linux,nuttx,chibios,它官方mcu芯片推荐用chibios这套的,也适配了市面上大大小小几十个开源飞控硬件,成熟度非常高。国内也有人适配了rt-thread的,基于他们HAL框架适配别的OS也是比较容易的
离线
@nongxiaoming
下载了ardupilot源码,发现是c++的,就放弃了。
离线