2个或多个物体碰撞,交换各自参数如何实现？

ID:915384 · 发表于 2021-9-27 10:17

请教各位大佬，我现在有个功能需求，2个或多个物体在碰撞时，交换各自的参数，要如何实现？
不用蓝牙，WIFI。
我初步的设想是RF无线传输，但是同时发送的时候干扰怎么处理？

ID:262 · 发表于 2021-9-27 16:16

不太明白意思,你是说把传感器粘在碰撞物体上,测量碰撞前后的碎片数量,动量,方向等参数吗?

ID:624769 · 发表于 2021-9-27 19:20

好深奥……

长方形A 和长方形B, 碰撞，然后长方形A 变成长方形B的长宽，长方形B变成长方形 A的长宽？
红球撞绿球，然后红球变绿绿球变红？

还是向沙发说的那样，记录碎片数量？

ID:915384 · 发表于 2021-9-28 07:41

heicad 发表于 2021-9-27 16:16
不太明白意思,你是说把传感器粘在碰撞物体上,测量碰撞前后的碎片数量,动量,方向等参数吗?

不是，我举个很简单的例子，比如2个杯子，颜色不一样，在碰撞后，彼此交换颜色。不需要什么传感器，只是无线交换数据，碰撞可以用很简单的震动开关来启动，这个只是个启动信号，不用传感器。
这里的关键是数据交换，因为没有主从关系，也有可能多个杯子参与进来。
不知道我这样描述清晰没有，谢谢。

ID:915384 · 发表于 2021-9-28 07:43

188610329 发表于 2021-9-27 19:20
好深奥……

长方形A 和长方形B, 碰撞，然后长方形A 变成长方形B的长宽，长方形B变成长方形 A的 ...

不好意思，可能我的描述不好理解，其实就是你说的2个不同颜色的球碰一下，交换颜色，只不过我的需求可能是3个球或4个球。
麻烦帮忙想下，谢谢了。

ID:123289 · 发表于 2021-9-28 17:01

问题理解不了，帮不上忙。

ID:624769 · 发表于 2021-9-29 00:29

linpeng1981 发表于 2021-9-28 07:43
不好意思，可能我的描述不好理解，其实就是你说的2个不同颜色的球碰一下，交换颜色，只不过我的需求可能 ...

信息量太少，所以，这个问题，只能你自己解决，最多帮你分析一下。

首先，几个球撞都不是问题，你只要明确一点，（当你无穷分割时间的前提下，即精确到ms不够就us, us不够就ns, ps, 按照这样分割的话），同一时间点，只会存在两球的碰撞，决不会存在多球碰撞的，所以，所谓的多球碰撞无非就是 N次的两球碰撞组合体而已，所以在处理上，只要依次处理两球碰撞即可。

基于上面这个理论，对时序要求会很高，所以，不可能碰撞的时候，再在若干个球之间互相对个时，确认谁先谁后，所以，必须要有个基站（总服务器），所有球发生碰撞后，把碰撞次数，和自身参数上传，服务器根据各球上传参数，以及碰撞次数，碰撞时间（服务器收到时间）互相匹配相撞球，交换他们的参数后，下发。

根据你提出的信息，目前看来，只能朝这个方向搞。

ID:420836 · 发表于 2021-9-29 07:56

也许可以使用模式识别和机器视觉来测量多体系统的物理参数，例如速度、颜色等的交换。

ID:844772 · 发表于 2021-9-29 09:05

抛开碰撞说法，无非就是多个实体间传输数据，如果能用WIFI设备是最好的，它有防冲突机制。不能用WIFI，就需要自己设计协议，你可以参考cdma或令牌的机制，设计简单协议，不过是传输几个参数，用443收发都可以。

ID:915384 · 发表于 2021-9-30 06:47

glinfei 发表于 2021-9-29 09:05
抛开碰撞说法，无非就是多个实体间传输数据，如果能用WIFI设备是最好的，它有防冲突机制。不能用WIFI，就需 ...

感谢您的回复，不能wifi。不分主从，可能有多个物体。所以蓝牙也用不了，操作上也不会有连接等操作。

您说的CDMA或令牌的机制我不是很熟悉，等下去了解下。
但是我有个疑问，这个是不分主从的，按照您的建议是否可以实现？

ID:915384 · 发表于 2021-9-30 06:48

yzwzfyz 发表于 2021-9-28 17:01
问题理解不了，帮不上忙。

问题已经描述了，可能是我表达问题，谢谢回复哈

ID:915384 · 发表于 2021-9-30 06:49

TTQ001 发表于 2021-9-29 07:56
也许可以使用模式识别和机器视觉来测量多体系统的物理参数，例如速度、颜色等的交换。

用在很简单的产品上面，成本上无法使用您说的那些模式识别等传感器。

ID:915384 · 发表于 2021-9-30 06:54

188610329 发表于 2021-9-29 00:29
信息量太少，所以，这个问题，只能你自己解决，最多帮你分析一下。

首先，几个球撞都不是问题，你只要 ...

我拿杯子来做举例，其实就是每个杯子里有个震动开关，当2个或多个杯子碰撞的时候，把杯子的颜色互换。那么从基本流程出发，1，各自把各自的颜色发出。2，各自接受发出的颜色参数。3，收到后跟自己的颜色比较，如果不同，就换。

假如我用433传输信号，如果同时发的话，信号会有干扰，特别是有多个杯子同时发送信号。
因为不分主从，所以也无法统一主机发送。

ID:915384 · 发表于 2021-9-30 09:03

glinfei 发表于 2021-9-29 09:05
抛开碰撞说法，无非就是多个实体间传输数据，如果能用WIFI设备是最好的，它有防冲突机制。不能用WIFI，就需 ...

您好，我了解了下您说的令牌机制，不知道是否理解有误，感觉还是有点困扰，需要向您请教：
我先说下我现在的初步思路：用433M发送、接受数据。
当2个或多个杯子碰撞启动数据交换的时候：
1，先看下是否有数据在接受。
2，没有，则发送自己的参数。
3，有，等待接受完。
4，重复1-3，直到发送完。

但是，这里我担心有个问题，就是可能会出现2个杯子同时发送的情况，这样就没有办法解决。
因为433M接受模块都需要前导码，这个都有10ms左右的延迟。

还望指点，谢谢。

ID:844772 · 发表于 2021-9-30 11:02

linpeng1981 发表于 2021-9-30 09:03
您好，我了解了下您说的令牌机制，不知道是否理解有误，感觉还是有点困扰，需要向您请教：
我先说下我现 ...

你这个机制是可以的（最好再完善点防冲突机制），不过你这个方案是CDMA/CD模式，不是令牌机制。令牌机制，相当于有个令牌在你几个杯子之间做击鼓传花，谁手上有令牌才能发言，令牌是不会冲突的。
现在感觉前一种好点，令牌要组网不适合随意加杯子。你说的碰撞不是问题，无非就是四个事件的循环啊：侦听、发送、检测、冲突处理，您先按之前方案处理，有问题再加上冲突处理（就是若发送过程中发现数据碰撞，先发送阻塞信息，强化冲突，再进行侦听工作，以待下次重新发送），感觉杯子碰撞事件处理时间也超过10ms，不用中间冲突处理也可以的，关键是在3步骤，不能单纯等待，要延时等待延时的策略就是逐步增加，但加上了中间防冲突可以防止外界干扰。还有那些433遥控模块发一个24bit的码要200ms多，好像时间有点长。我觉得是把颜色编号，最多不过传递颜色号和杯子地址，也就4+4bit就够了。

ID:959346 · 发表于 2021-9-30 11:10

linpeng1981 发表于 2021-9-30 09:03
您好，我了解了下您说的令牌机制，不知道是否理解有误，感觉还是有点困扰，需要向您请教：
我先说下我现 ...

按照你这个思路，有点没太理解呵：
1 先看单组2个杯子碰撞的时候，2个都同时检测到碰撞，是否会同时都发送数据了？
2 如果在前导码这个时间内，同时有几组杯子碰撞，就分不清哪组跟哪组碰撞了？
如果只考虑同时只有一组，用你这个思路，就要考虑同时发送的问题，如果要考虑某个时间内同时有几组，就需要一个公共时间来区分吧？

ID:915384 · 发表于 2021-9-30 12:01

glinfei 发表于 2021-9-30 11:02
你这个机制是可以的（最好再完善点防冲突机制），不过你这个方案是CDMA/CD模式，不是令牌机制。令牌机制 ...

您好，我的这个方案问题就在于很难发现数据碰撞，因为都使用的是433M的发送。
所以问题在于，如果同时发送的话，这个功能就没法实现。

ID:624769 · 发表于 2021-9-30 12:02

linpeng1981 发表于 2021-9-30 06:54
我拿杯子来做举例，其实就是每个杯子里有个震动开关，当2个或多个杯子碰撞的时候，把杯子的颜色互换。那 ...

1，各自把各自的颜色发出。2，各自接受发出的颜色参数。3，收到后跟自己的颜色比较，如果不同，就换。

第三点,是不需要考虑的, 就算和自己颜色一样, 你执行了更换, 最终结果也不会变, 没有必要做这个判断。而且，在你设计的整个机制里面，变更自己颜色这个操作，并不占用多少资源。

你现在最关键的需要考虑的问题：如果 AB 互相碰撞，同一时间 CD互相碰撞， ABCD 距离又非常接近，按你非接触的互换数据，又不分主从，这个时候，如何避免 AC 互换数据， BD互换数据？
这就是为什么我说，有必要建立一个基站统筹所有的数据交换的原因。

ID:915384 · 发表于 2021-9-30 12:04

Jiang_YY 发表于 2021-9-30 11:10
按照你这个思路，有点没太理解呵：
1 先看单组2个杯子碰撞的时候，2个都同时检测到碰撞，是否会同时都发 ...

1，我的方案就是无法处理这个情况。所以现在就困在这步。
2，不管几组，都可以当成若干个杯子碰撞。

最重要的是1的情况如何处理。2的情况使用环境很少，可以不考虑

ID:915384 · 发表于 2021-9-30 13:10

188610329 发表于 2021-9-30 12:02
1，各自把各自的颜色发出。2，各自接受发出的颜色参数。3，收到后跟自己的颜色比较，如果不同，就换。

...

如果AB碰撞的时候CD碰撞，可以就直接当ABCD同时一起碰。
没法建立基站统筹，应用环境所致。

现在问题的核心就是：A,B,C,D如果有2个同时发送数据要如何避免？其他情况的应用环境不考虑。

ID:624769 · 发表于 2021-9-30 13:26

linpeng1981 发表于 2021-9-30 13:10
如果AB碰撞的时候CD碰撞，可以就直接当ABCD同时一起碰。
没法建立基站统筹，应用环境所致。

你可以效仿对讲机抢麦机制
某机（比如：A机）发送：我是 123 请求连接，收到请回答，
所有收到的回复，我是 xxx 收到123请求，可以连接我。
A机不管收到多少个回复，随机性取一个（比如456），然后发送 456，我开始连接你。
所有收到这条的，除了456 进行应答，其他进入静默模式，直到收到 A 机发出的，数据交换完毕，OVER.（或者多少ms 以后，判为超时等同于A机通讯结束）
其他机器再复活，发出：我是 xxx 请求连接，收到请回答。依次类推。
就是人为的把混乱的全双工，当作半双工来处理。

ID:915384 · 发表于 2021-9-30 14:32

188610329 发表于 2021-9-30 13:26
你可以效仿对讲机抢麦机制
某机（比如：A机）发送：我是 123 请求连接，收到请回答，
所有收到 ...

有几个地方需要注意：
1，没有主从之分，可以是A，也可以是B，或者其他。所以你说的应答机制无法建立。
2，其实问题的核心还是在于：如何解决同时发送数据的问题。如果依次发送，那么是没有问题的。就是探讨有没有好的办法或者一个机制来解决或避免同时发送干扰问题。
目前的机制：
发送前，检测通道是否被占？但是用433Mhz的话，前导信号较长，有MS级别的延迟，还是会有概率数据同时发送。
如，A/B碰撞，A先检测到碰撞，然后发现通道空闲，于是发送自己的参数。由于433模块的接受前导信号有5-10ms，那么假如B在这期间也检测通道，发现空闲，就会同时发送数据出来。
这个是我目前没有想到好的办法去解决的。

ID:624769 · 发表于 2021-9-30 15:38

linpeng1981 发表于 2021-9-30 14:32
有几个地方需要注意：
1，没有主从之分，可以是A，也可以是B，或者其他。所以你说的应答机制无法建立。
...

因为,没有主从之分, 才让你选择效仿半双工对讲机的抢麦方式.
半双工对讲机知道吧？听就不能说，说就不能听。

一发炮弹打下来，所有人炸晕了，醒了之后拿起对讲机说：有喘气的么？这时候别的对讲机可能也正好有人说，那么大家都没有听到对方的话，所以，隔一段时间，再抢一次麦，直到有听到一方讲话为止。而多人都要轮流讲话的话，就要每次讲话都带上自己的代号，和对方的代号，非相关人员，不插嘴。所以，你要自己建立一套握手标准。
比如，侦听20MS 没有人占线，就自己占线表明身份，表明自己没有配对。然后继续进入侦听状态。如果有人收听到你的信息，表明了自己身份，你就跟他连接，其他人就等你们完成后，再连接。

ID:844772 · 发表于 2021-9-30 15:43

linpeng1981 发表于 2021-9-30 13:10
如果AB碰撞的时候CD碰撞，可以就直接当ABCD同时一起碰。
没法建立基站统筹，应用环境所致。

我理解你的前导10ms是为抗干扰的那个拉低信号，这是可以监听到的啊，而且那是自己定义的，可以少一点。对于信号碰撞我建议，线路监听时，即使没人发射，也要加个概率延迟，而不一定马上发射信号；另外发射时本机还要监听，有冲突会误码，就重新监听——发射。

ID:415064 · 发表于 2021-9-30 17:43

这个干通讯冲突问题必然存在，所以我认为，开机的时候大家选举出一个老大这样，所有数据全部汇总到老大。当这个老大挂了，再重新选出一个老大

ID:915384 · 发表于 2021-10-1 07:34

glinfei 发表于 2021-9-30 15:43
我理解你的前导10ms是为抗干扰的那个拉低信号，这是可以监听到的啊，而且那是自己定义的，可以少一点。对 ...

是的，如果是有线连接，那么加上重发机制，可以很好解决，检测所谓的通道只要一个电平可以迅速响应，无线的话有延时这点无法避免同时发送的概率，目前好像没有别的更好办法，只能按这个思路先打板做出来测试看看实际效果。
感谢您的思路跟建议，到时候实际PCB出来我测试下效果再来跟各位汇报。谢谢了。

ID:915384 · 发表于 2021-10-1 07:35

wojiaoguogai 发表于 2021-9-30 17:43
这个干通讯冲突问题必然存在，所以我认为，开机的时候大家选举出一个领袖这样，所有数据全部汇总到领袖。当 ...

随机增加物体的，这个思路可以，但是比较麻烦。

ID:915384 · 发表于 2021-11-13 09:30

各位：做个汇报，目前已经做了2块PCB板出来，测试了下，目前的话有一定的出错，但是有80%的成功率，这个目前还算可以接受，我看了下，从软件上还可以改进一些。
另外，我使用的是433MHZ的调制解调电路，距离有点远，我想距离限制在10cm左右。
NFC可能成本问题无法使用。
RFID，是最有可能的，但是我查询到的都是集成电路或IC，成本无法接受，而且应用的话也有限制。

所以我的想法是：
1，使用RFID的电路，主要是传输数据，另外就是距离短。
2，自己定义传输数据，只是使用该电路调制信号。目前没有找到合适的电路图。

谢谢。

ID:624769 · 发表于 2021-11-13 13:37

RFID也是有方向性的吧？你打算如何调整方向？
按你的距离，我还是觉得红外近场通讯更实在啊，你如果有调整RFID方向的手段那么用在红外上一样可以实现，成本就可以接受了，另外，即便不能调整角度，如果用6个广角红外管基本可以做到无死角。而且用红外线的话，只要控制电流，不载波发射距离就可以达到很近很近。接串口的话，连通讯协议也不用写。总觉得更加省时省力省心啊……

ID:915384 · 发表于 2021-11-19 15:42

188610329 发表于 2021-11-13 13:37
RFID也是有方向性的吧？你打算如何调整方向？
按你的距离，我还是觉得红外近场通讯更实在啊，你如果有调 ...

是，你说的没错，可能RFID的方向性也没办法调整，也不太适应我的应用环境。
用多个红外的是个思路，还要结合结构再想想。
目前用433MHZ的发射接收效果还可以接受，只是距离太远，可能从硬件电路上调整参数相对来说还是容易点。

谢谢了。

ID:313048 · 发表于 2021-11-19 16:08

本帖最后由 AUG 于 2021-11-19 16:10 编辑

linpeng1981 发表于 2021-11-19 15:42
是，你说的没错，可能RFID的方向性也没办法调整，也不太适应我的应用环境。
用多个红外的是个思路，还要 ...

12楼的方法应该是可以的，球形里面你要解决的就是接收和发送的问题，无非在于是否要像他这样用2个平行的线圈，给你个我的猜想，在他这个电路上，发射用线圈围绕小球一圈，然后接收用电感，在球心，这个距离应该是可以接收到的，具体参考智能车竞赛的电磁组，通过这种方法，你完全可以实现你的通信，而且同一个球内，发射和接收永远是错开的，所有不会出现数据接收错误的问题。这里的12楼是你发的另一个帖子里面的。

ID:915384 · 发表于 2021-11-20 06:53

AUG 发表于 2021-11-19 16:08
12楼的方法应该是可以的，球形里面你要解决的就是接收和发送的问题，无非在于是否要像他这样用2个平行的 ...

好的，我看看要不要打几块PCB出来测试下。非常感谢！

帐号		自动登录	找回密码
密码			立即注册

2个或多个物体碰撞,交换各自参数如何实现？

评分

评分

评分

评分

评分