Add capabilities to read/write multiple sensors in single transmissions

[proan]

At this time, each sensor read or write requires a separate transmission from the computer to the hardware_interface. Of these transmissions happen over the USB bus, which has limited abilities to do this type or short, rapid transmission quickly.

This issue will collect thoughts and requirements for modifications to enable multiple devices connected to a single hardware_interface to be read and/or written in a single transmission.

[Poofjunior]

I agree with the description above. Right now, a single transmission from the computer to the Leonardo and back to the computer can clock in at about 200[hz]. Transmission may be able to pick up a bit more speed by tightening some of the interface overhead, but I suspect that the usb-transfer is no longer the bottleneck. (We ran transfers back and forth over USB today just over Arduino virtual serial and were able to transfer data well over 200[hz].)

To enable multiple-sensor-transmission from one hardware-interface in a single loop (pc-to-sensors and back), we need to make the PC and hardware-interface aware of the sensor network. Right now, we have a tree of data transmission with the pc as root and sensors as leaves. Getting all sensor data means we need to take N walks from root to sensor and back to the root, where N is the number of sensors. The slowest path is between the pc and hardware-interface, so minimizing these trips would be ideal for the highest rate. We can do this by first telling the hardware interface all of the hardware-specific commands it needs to send to all of its sensors in one transmission and receiving back the bulk data from the hardware interface after it's pulled the data from each connected sensor with the sensor-specific commands. This idea works in theory, provided that getting the data requires a single read from each sensor. (I think this is the case.) In practice, though, we cut down on the abstraction of the hardware interface by implementing this technique. Overall, the hardware interface becomes less-generic, as it needs to know how to do multiple reads from receiving a single PC transmission. (The Sub20 can't do this in a single transmission since it's just a passthrough.) Provided that our hardware interface isn't just a passthrough, we can implement firmware to do this for each hardware interface that can be programmed. In that sense, all Arduinos, a Raspberry Pi, or a STM32F4 could be programmed to reflect this new software architecture, provided that we write dedicated firmware for each one.

With a new software architecture that minimizes pc/hardware-interface transmissions, we would get 200[hz] if implemented on an Arduino Leonardo. However, the rewriting of the hardware interface to be "intelligent" would not be possible on the Sub20. Furthermore, the top-level method of requesting data would need to be much more aware of the "connectedness" of the sensor network--possibly to the point where requesting data from a single sensor without specifying the hardware interface would be uncommon. It would probably be messy to keep the Sub20 while creating a new implementation of hardware-interface.

Right now, if we address 3 motors and one imu individually, we cut our loop rate down to 50[hz].

One alternative: we could write a "triple-motor-driver" to change the speeds of three motors at once with a single message from the pc.

I'll bring up some more info about the specific hardware implementation that this driver will be used for in another email.

[proan]

Your proposal sounds like moving the device drivers down into the Arduino firmware. This would probably work with the Leonardo, but the Uno definitely won't have enough memory for this. It would be easy (and possibly worthwhile) to do some of this for the built-in devices, and we could tackle managing pins (#10) at the same time.

I was thinking that we could start every Arduino transmission with the number of sensors to read/write. This would allow us to set a number of times through the data processing loop. Modifying the computer side to collect all of the read/write commands will be a bit more difficult, but one solution is to configure a polling frequency.

As you noted, these solutions do not apply to the Sub20, but I think we could make them still reasonably interoperable.

[Poofjunior]

I think bumping the drivers down a level would make bulk transmission a lot easier. Depending on how many features we really need out the chip, we could probably keep the driver pretty minimal. We'll lose the generic feel of the original version, but perhaps we can keep the actual driver code as templated as possible to be able to drop it into various hardware interfaces. (We'd probably just need a set of writeToReg(...), readFromReg(...), etc. functions implemented for each hardware interface.)

Since the hardware interfaces don't need to do anything else, they could just constantly poll the sensors and save the latest data in a buffer. When the PC requests data, the hardware interface can be prepared to write back whatever (or all) parts of the data that was requested. We could also just configure it to send all as often as possible.

[sebEg]

We also need the hardware interfaces to set different signals (GPIO, PWM, ...) requested by the PC. I think this would not work well with the hardware interface just sending its data as often as possible. But when the PC is requesting data, it could also send the signals to set in the same message.

Another approach would be to separate reading sensors and setting signals, but this would require more hardware.