Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Communication between robots. #11

Open
3 tasks
Terae opened this issue Nov 25, 2018 · 1 comment
Open
3 tasks

Communication between robots. #11

Terae opened this issue Nov 25, 2018 · 1 comment
Labels
enhancement New feature or request help wanted Extra attention is needed medium priority

Comments

@Terae
Copy link
Member

Terae commented Nov 25, 2018

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:

Communication::wire_protocol primary("192.168.1.0");
Communicaiton::wire_protocol secondary("192.168.2.0");
primary.send_frame({. . .});
secondary.send_frame({. . .});
@Terae Terae added enhancement New feature or request help wanted Extra attention is needed medium priority labels Nov 25, 2018
@Terae
Copy link
Member Author

Terae commented Nov 29, 2018

I found this article on the forum.
Basically we have 4 solutions to communicate:

  • 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.

Does someone know a highly wifi-saturated place?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed medium priority
Projects
None yet
Development

No branches or pull requests

1 participant