You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This year, we will use two robots (primary and secondary).
We made a lot of changes in the electronic architecture and it seems to be the right moment to centralize the strategy of the both.
And so on, the idea is to use one raspi on each to control the overall electronic, but only one will calculate the strategy of both robots (the environment will be shared and it is easier to make decisions).
Actually, our communication protocols work for serial and ethernet connections, so we need:
to choose the physical transport: Wifi? Bluetooth? ==> be careful, the wire environment is saturated because of the amount of teams so we should choose a reliable protocol not impacted by interferences
setup the protocol usage on the raspi
develop the appropriate code for the slave raspi to transmit orders from the master to elec and vice versa)
All the process needs to be transparent for the strategy: for example, if the primary robot is on the network 192.168.1.0 and the *secondary on 192.168.2.0, this code should be sufficient:
WiFi 2.4GHz, which is exasperatly saturated at the Cup (in particular on the channel 1)
WiFi 5Ghz, which allows more channels and which is less used; the communication rate is higher but the range is smaller (only 3 to 4.5 meters)
Bluetooth
XBee
Li-Fi, using visible light; because of the illumination environment I wouldn't use it.
Personally I think we should use WiFi 5GHz, use 2 raspis to set up a communication in order to test the maximum range, and use this solution on an saturated environment. We need to find a raspi module to communicate in this band width.
We could also use a Bluetooth communication; the arno's team use this tecnology since 3y without any problem.
This year, we will use two robots (primary and secondary).
We made a lot of changes in the electronic architecture and it seems to be the right moment to centralize the strategy of the both.
And so on, the idea is to use one raspi on each to control the overall electronic, but only one will calculate the strategy of both robots (the environment will be shared and it is easier to make decisions).
Actually, our communication protocols work for serial and ethernet connections, so we need:
All the process needs to be transparent for the strategy: for example, if the primary robot is on the network 192.168.1.0 and the *secondary on 192.168.2.0, this code should be sufficient:
The text was updated successfully, but these errors were encountered: