5

I have a GPS unit with an IMU based on the Intel Edison I want to used alongside a Raspberry Pi for a robotics project. The general idea is that I want to use the Edison unit to provide the Pi with sensor data (gps, gyro, compass, ++) on a standardised format, and use the Pi to drive the robot itself. This will allow me to add further Edisons in the future, and/or replace them with newer and improved sensors without having to modify the computer driving the robot.

However, I'm stuck on how to integrate the two. My initial idea was to use the onboard USB ports for communications, but I don't quite know where to start. Reconfiguring the USB port to provide ethernet over USB is an alternative if that simplify things.

Having the Edison write continuously to the usb port with no other communication between the two is no problem, but there are scenarios where the Pi should send commands to the Edison in order to reset or calibrate one or more sensors or disable them during testing.

Is the best option to write a custom driver for this, or would I be better off using ethernet over USB and simply implement a server/client model using TCP?

If the USB driver option is the best, where would be a good place to look? This driver would essentially have to run one or more programs/commands on the Edison returning the output to the Pi.

Edit: As mentioned USB is the preferred method for connection, as it allows for both data and power to the Edison (driving it from the Pi) so I can avoid having to add a separate power source for the Edison. The messages will ideally be simple json strings going at a rate of approx 100/sec. The Edison is running Busybox and the Pi is on a Debian-based distro. Neither will have access to an external network while running, so they will be limited to USB or Ethernet over USB as there are no other physical connectors found on both units.

  • Seems more like a distributed, peer to peer model is more appropriate as it sounds like you have a Pi with a model and the Edison providing the control. The Pi takes data and events from the Edison, incorporates that sensory data into the model to determine current state, and then makes decisions about what to do next. I would go with the easiest transport mechanism between Pi and Edison in order to work on the the really important bits of the model in the Pi with its decision making and the data communicated between Pi and Edison. – Richard Chambers Jan 10 '18 at 14:18
  • Correct. And how to divide the responsibilities between the two isn't the problem, the actual communication is the issue. I have no experience writing anything to do with USB (hence this project), so I don't know how difficult that would be compared to doing a TCP server/client, and how much I get for free from the underlying libraries or OS. – bjelleklang Jan 10 '18 at 17:23
  • 1
    Have you considered using UDP/IP over Ethernet as your transport? If the messages are small UDP/IP might be a good alternative. A direct connection between the Pi and the Edison with a null modem type Ethernet cable would be very reliable. The technology is well known with lots of open source examples. I took a look at TCP over USB and there seems to be several closed source products. I found an open source project but not sure whether it still alive. – Richard Chambers Jan 10 '18 at 21:20
  • 1
    Perhaps you could updated your posted question with some idea as to what you need from a transport layer for your messages? – Richard Chambers Jan 10 '18 at 22:26
  • You might first take some time to figure out what the Edison offers for connection to a desktop PC; likely the same mechanism can work with a pi. Or if your data rates are low, you could just use serial UARTs, possibly using a USB<>UART adapter to implement that on one or both ends (at an increase in latency). – Chris Stratton Jan 11 '18 at 7:05
3

Configuring the USB port as Ethernet only complicates things. Not only does is throw the uncommon, proprietary RNDIS protocol into the mix, but then you need to add an IP server/client application on top.

The Micro USB connector on the Edison is already configured to provide a bridge to a UART using an FTDI chip. The Raspberry Pi already comes with (equally proprietary, but hugely common) FTDI drivers. The drivers will create a /dev/ttyUSB device on the Pi when the Edison is plugged in that you can talk to like any other serial port.

Create a server for the serial port on the Edison that responds to simple commands (or simply periodically sends data) and create a client for the virtual serial port on the Pi that handles the other end.

  • Great, this sounds like a simpler solution than what I had in mind. Thanks a bunch! – bjelleklang Jan 30 '18 at 7:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.