[feature] 不只是整车的代码，还有工具收集

[half-nothing]

Clear and concise description of your idea

1.希望可以同步整理一些工具，比如说摄像头的透传，或者一些好用的上位机等
2.讨论的地方可以扩展一下，Gitter不是很常用，可以换到Discord或者Kook

Describe how the idea would be helpful

.

Additional context

No response

Validations

• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
• Remember to follow the community guidelines and be friendly.

[ittuann]

感谢您的建议！

关于第2点，Gitter其实在开源社区中也是较为常用的即时通讯工具。另外，Github自带的discussions功能也是一个很棒的平台，与gh直接集成并且用户无需另外注册账号即可参与讨论。但有些可惜的是，从项目开源至今不到两周的时间，这两个讨论板都没怎么得到广泛使用。

关于第1点，仓库目前是想方便车友们找到优秀的开源项目做参考代码。另外对于工具而言，每个人的喜好不同很难筛选出好用的标准。就像有人喜欢用VSCode有人喜欢Keil有人喜欢用IAR一样。即使是小到像串口助手这样的工具，也有Tabby或是XCOM/SSCOM等等喜好之争。

我觉得更好的方式是，在收集表格里面找到自己喜欢的开源项目，然后点进对应项目里看作者有没有附加自己的调车经验文章，参考自己喜欢的作者的文章进程工具的使用和开发。

或是在github discussions等讨论版开一个讨论贴让大家一起讨论。

由我或其他贡献者个人的喜好整理工具，太过于主观化了不能给所有人参考。

[huoxingdawang]

我觉得大可以开一个工具集和大全，把大家收集到的工具全都堆进去，然后让用的人自己挑选。可以参考oi-wiki，逐步建立一个包含开源工程、工具集、常见算法、数据集、教程甚至与硬件结构、通用电路的wiki，而不是单单只做开源工程的收集。作为一个在三年内连续获得了四个国二的菜鸡，我认为智能车又不只有开源工程，芯片会变，IDE环境会变，开源出来的工程可能会随着时间的变化不能使用，但是算法的思想是不会变的，这是我应该被精炼和传承的，而不是一上来就把一大坨开源工程堆在那里。我认为readme里对于这个项目的定义一下将就把这个东西锁死了。

[huoxingdawang]

还有另一个情况在于，一个project往往代表着一个团队的意义，我认为如果要开project，要得到全队人的同意，但是算法的片段、调试经验、开发工具这些东西往往来自一个人的贡献，是比较容易从整个大的项目里分离出来开源的，而且工具的传承性会比项目长很多，比如我去年和前年的信标算法是我自己写的，系出同源，我其实可以大可以把算法放出来，但是不能放工程，因为工程里有地方参考了祖传的实现，我个人认为不大方便放。我认为有类似想法的人应该会有一部分。
再谈到工具，我们队里面有一个自己写的调参上位机，开源已经两年了，并且在持续的更新和调优，但是从反馈来看，没人用，甚至没人试图了解怎么用。

[huoxingdawang]

综上所述，我建议如果您真的准备推进智能车的开源这一宏图伟业，应当慎重的重新思考这个仓库是否只局限于收集工程。
当然以上只是一个做了三年都没有一个国一的菜鸡的粗浅的理解，可能有冒犯或者不妥之处，还望您海涵。

[ittuann]

综上所述，我建议如果您真的准备推进智能车的开源这一宏图伟业，应当慎重的重新思考这个仓库是否只局限于收集工程。 当然以上只是一个做了三年都没有一个国一的菜鸡的粗浅的理解，可能有冒犯或者不妥之处，还望您海涵。

感谢你分享了你的看法和经验！

我很赞同你所说的，智能车不仅仅只是关于开源，也有许多的算法思想、调试经验和开发工具等。这种多方面的知识确实是宝贵的。

但我也在犹豫的地方是，智能车竞赛其实更多的是一个工程类竞赛，与ACM那样纯算法类竞赛还是有所不同的。在工程实践中，很多东西并不是单纯的数学公式或算法可以描述的和比较优劣的。
就比如PID调参，基本上每个人都有自己的经验和方法，而这种经验和方法也很难量化和比较，遇到关于经验方面的争议要如何取舍就会是个问题。另外我自己也尝试过用Matlab仿真PID调参，但实际效果与稳定性也没那么理想，像这种实验性内容是否应该被纳入网页收集也是个值得考虑的问题。

不过，如果能建立像oi-wiki那样的资源库会非常价值。但在开始这样的项目也需要多考虑一些细节，尤其在做网页来面向新入坑的车友的时候时。我们必须提前考虑和规划许多细节和社区指导。

目前我仅停留在了收集开源链接的层面。让大家能在收集表中找到自己喜欢的开源项目，进而看作者是否分享了自己的经验。让车友们能根据自己喜欢的开源作者的文章进行工具的选择和开发。

最后，你并不是“做了三年都没有一个国一的菜鸡”啦，你的建议，见解以及经验都非常有价值。我也感谢你对这个项目的建议和反馈！我创建这个开源仓库的初衷就是为了尽我所能地协助新入坑的车友们。我的能力和思路也是有局限性的，但我坚信即使小小的努力也可以为推广开源文化做出贡献，就先从做一些微小的工作开始啦。我会努力让这个仓库更有价值，如果你还有其他想法或补充，欢迎随时与分享和讨论。

另外可能建个QQ群会比较好？感觉即时交流和讨论可能更有效果

[half-nothing]

感谢您的建议！

关于第2点，Gitter其实在开源社区中也是较为常用的即时通讯工具。另外，Github自带的discussions功能也是一个很棒的平台，与gh直接集成并且用户无需另外注册账号即可参与讨论。但有些可惜的是，从项目开源至今不到两周的时间，这两个讨论板都没怎么得到广泛使用。

关于第1点，仓库目前是想方便车友们找到优秀的开源项目做参考代码。另外对于工具而言，每个人的喜好不同很难筛选出好用的标准。就像有人喜欢用VSCode有人喜欢Keil有人喜欢用IAR一样。即使是小到像串口助手这样的工具，也有Tabby或是XCOM/SSCOM等等喜好之争。

我觉得更好的方式是，在收集表格里面找到自己喜欢的开源项目，然后点进对应项目里看作者有没有附加自己的调车经验文章，参考自己喜欢的作者的文章进程工具的使用和开发。

或是在github discussions等讨论版开一个讨论贴让大家一起讨论。

由我或其他贡献者个人的喜好整理工具，太过于主观化了不能给所有人参考。

关于我的第二点，首先声明一点，虽然现在机场的价格并不高，但是不可否认的是有很多新入门的车友并没有具备上github等网站的条件，所以我觉得是不是需要有一个国内能轻松联系上的方法，而不是看着圈圈发呆。

至于第一点，我觉得做这个项目的初衷不应该是“推荐”工具，我们也不应该去“筛选出一个好用的标准”，我们只是一个工具的集合，方便各位车友找到自己需要的工具，而不需要去搜索引擎上大海捞针。

[half-nothing]

我觉得大可以开一个工具集和大全，把大家收集到的工具全都堆进去，然后让用的人自己挑选。可以参考oi-wiki，逐步建立一个包含开源工程、工具集、常见算法、数据集、教程甚至与硬件结构、通用电路的wiki，而不是单单只做开源工程的收集。作为一个在三年内连续获得了四个国二的菜鸡，我认为智能车又不只有开源工程，芯片会变，IDE环境会变，开源出来的工程可能会随着时间的变化不能使用，但是算法的思想是不会变的，这是我应该被精炼和传承的，而不是一上来就把一大坨开源工程堆在那里。我认为readme里对于这个项目的定义一下将就把这个东西锁死了。

首先膜拜一手大佬

然后讲讲我的看法
首先是对开源工程的收集，我觉得重点是对项目的简洁和整理，提炼重点，而不是在一堆库文件里面大海捞针找自己需要的部分。如果说需要精炼算法的话，我觉得CSDN上面有些文章可能更加详细一点，我觉得智能车开源项目应该更加关注于各个组件之间的协作，和对算法的一些就实际情况的改造或者效率优化，一些算法精度与算法开销间的取舍等等。
智能车开源究竟是开源什么？
我觉得这才是我们应该思考的问题，是整个项目，还是代码，还是工具，还是说是个人经验？我觉得这一点才是我们需要考虑的

[ittuann]

感谢您的建议！
关于第2点，Gitter其实在开源社区中也是较为常用的即时通讯工具。另外，Github自带的discussions功能也是一个很棒的平台，与gh直接集成并且用户无需另外注册账号即可参与讨论。但有些可惜的是，从项目开源至今不到两周的时间，这两个讨论板都没怎么得到广泛使用。
关于第1点，仓库目前是想方便车友们找到优秀的开源项目做参考代码。另外对于工具而言，每个人的喜好不同很难筛选出好用的标准。就像有人喜欢用VSCode有人喜欢Keil有人喜欢用IAR一样。即使是小到像串口助手这样的工具，也有Tabby或是XCOM/SSCOM等等喜好之争。
我觉得更好的方式是，在收集表格里面找到自己喜欢的开源项目，然后点进对应项目里看作者有没有附加自己的调车经验文章，参考自己喜欢的作者的文章进程工具的使用和开发。
或是在github discussions等讨论版开一个讨论贴让大家一起讨论。
由我或其他贡献者个人的喜好整理工具，太过于主观化了不能给所有人参考。

关于我的第二点，首先声明一点，虽然现在机场的价格并不高，但是不可否认的是有很多新入门的车友并没有具备上github等网站的条件，所以我觉得是不是需要有一个国内能轻松联系上的方法，而不是看着圈圈发呆。

至于第一点，我觉得做这个项目的初衷不应该是“推荐”工具，我们也不应该去“筛选出一个好用的标准”，我们只是一个工具的集合，方便各位车友找到自己需要的工具，而不需要去搜索引擎上大海捞针。

添加了Discord和QQ的链接 (17655c9)

其实，为了大家在各种网络环境和设备下都能轻松访问这个项目，除了标准的GitHub Pages，我还特意提供了Netlify和Vercel的镜像网站作为备选。

对于有意直接参与项目修改的，关于如何加速访问Github仓库这个老生常谈的话题，百度简单搜一下就能检索到许多解决方案，使用网络代理也不是唯一的方法。仓库始终欢迎大家积极参与讨论与交流，但也希望先做基本的自我努力去百度一下。

最后，通过Github Discussions公开的讨论内容很可能会被搜索引擎索引，这意味着更多有相似疑问或需求的人可以从中受益。而Gitter则在提供即时通讯的功能基础上与Github也提供了集成。我依然推荐首选使用 Github Discussions