# OrleansAGV

**Repository Path**: zxfsc/orleans-agv

## Basic Information

- **Project Name**: OrleansAGV
- **Description**: 基于Actor模型，使用Orlean框架重写的版本，核心功能写完了，供大家学习新技术和思路完全够了。
- **Primary Language**: C#
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 1
- **Created**: 2025-09-10
- **Last Updated**: 2025-09-10

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# OrleansAGV

#### 介绍
基于Actor模型，使用.NET6 + Orlean框架重写的版本，核心功能写完了，供大家学习新技术和思路完全够了。因为身上的开发工作太多，已经写不下去了。再者，这玩意儿应该和ROS一起做设计，而不是等AGV成型后让工程师来独自开发。


#### 优点
1、正经的高并发，开发人员不用加锁的那种级别，代码一下就简单了。比如某一个交管区域，永远只有一个Actor在负责，即使多个请求进来了也得等着（10个交管区10个Actor，互不影响）。

2、场景恢复，虽然也是使用redis，但是Orleans在缓存数据的保存和读取时，真的不要太友好，简单的write和read就搞定了。也根本不需要考虑redis连接数过多和释放的问题。

3、AGV端和机台端独立了。也就是说，核心调度程序更新重启时，不会影响机台端的信号接收。机台传输协议需要调整的时候，不影响核心程序的正常运行。同时不同工序还可以独立出来，比如制绒是一个client，激光也是一个client，它们之间连程序都是独立的。

4、分布式。Server端仍然放在主控机台上，只控制几道工序的client端部署在设备就近的机台上

5、不再太多的依赖数据库。数据库完全成了基础数据和配置项的载体，即使使用excel都能让调度系统跑起来。


#### 缺点
1.  非b/s架构，对只会写java的人很不友好。

2.  数据展示上，由于实时数据都放在内存里不是数据库中，需要点额外的工作量

3.  对外部访问缓存数据极不友好，orleans对键值做一些算法，不看内容根本不知道是啥。外部真的那么好奇里面的数据，可以单独创建一个client连接server，开放webapi的方式

4.  对.net core新手和菜鸡不友好，学习成本偏高，设计能力要求偏高。


#### 后话
由于项目对应的AGV，在巡路模块和数据上有些个性，大家拿去实用会蛋痛，看看学习一下思路，了解一些新的框架和想法就行了。

仅供学习~结合视觉+雷达，以全局统筹+路径动态规划才是上上策，根本不需要小弟在车间内边写码边受罪！！