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出來測試下。非常感謝！

帳號		自動登錄	找回密碼
密碼			立即注冊

久久久久久久999_99精品久久精品一区二区爱城_成人欧美一区二区三区在线播放_国产精品日本一区二区不卡视频_国产午夜视频_欧美精品在线观看免费

2個或多個物體碰撞,交換各自參數如何實現？

評分

評分

評分

評分

評分