Software stack has poor performance

[kierdavis]

As pointed out in #49, reading from GPIO pins (something that someone may legitimately want to do many times per second) was found to take about 80ms to execute, which in my opinion is worryingly slow. I can't comment on what the performance of other API functions may be like.

I believe that some investigation into whether/how we can optimise the performance of robot-api, robotd and the embedded firmwares.

A good starting point would be to benchmark the API calls, which will help us determine which parts of the API to focus on.

[mxbi]

I think it's possible this is part of the problem:

https://github.com/sourcebots/robotd/blob/cc1e692de7c9f028127a9daf4105494295b5eebc/robotd/devices.py#L262

It looks like the arduino is set to run at 9600-baud (1.2KB/s), when the Arduino supports up to 115200-baud. A gpio-read sends and receives about 20 bytes both ways (I think), meaning just the time taken to send the data over the serial cable is >30ms (it could be 2-3ms with the higher baud rate).

I haven't tested it since I haven't got access to the arduino, but increasing the baudrate might be able to shave a lot of time off the arduino operations, especially the operations like analog_read which I believe receives around 100 bytes.

[kierdavis]

That is indeed part of the problem, but that baud rate setting is deliberate choice rather than an oversight. Looking at the history of the file, the baud rate was previously reduced from 115200 to 9600 in this commit. Communication with the servo assembly has been notoriously unreliable, and I believe this change was one that we put in place to try and increase reliability (at the expense of performance).

Improving the reliability of the servo board is something we'd like to do before next year's competition (but is probably too vast a change to make it in during this year's one). For what it's worth, I'm currently working on an alternative firmware for the servo board that might address this. It's not compatible with the current state of robotd however, so you can't just drop in it and hope it to work immediately.

[mxbi]

Thanks for the background info, that makes sense. Would it not be good to try something in between 9600 and 115200 baud? Or did you find that they were all too unreliable and so settled for the minimum?
Out of curiosity, I'll probably end up benchmarking the different baud rates next week anyway.