-
Notifications
You must be signed in to change notification settings - Fork 1
Add support for generic arduino commands #55
Add support for generic arduino commands #55
Conversation
We take in a command as a list of JSON-encodable entities and pass that to robotd. We expect to immediately get back a response message (as well as the usual status blob) which contains either valid data from the arduino or a description of the failure. This includes a novel testing approach which: - creates a valid robotd Board instance - mocks the underlying serial connection - creates a robot-api Board instance - mocks the socket connecting the robot-api Board such that it connects to the robotd Board instance This avoids real sockets and multiprocessing, both of which incur substantial overhead during tests along with the introduction of timeouts (which is just nasty).
The test failure on the CI is due to sourcebots/robotd#35 not being available in that test environment. |
I'm liking this use of fake sockets, hopefully these changes can be backported into the remainder of the tests (separate PR) to reduce the oddness they bring |
@RealOrangeOne indeed, I've some thoughts -> #57 |
for cls in (CommandError, InvalidResponse): | ||
if cls.__name__ == response['type']: | ||
raise cls(response['description']) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if we receive a response with an invalid type
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point; I'll make that error harder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After testing on a kit last night I'm confident this works as intended. I would be grateful if the conflicts could be resolved before I approve. |
@kierdavis conflicts resolved; please could you take another look? |
This adds a new
direct_command
method which takes in a command as a list of JSON-encodable entities and passes that to robotd. It expects to immediately get back a response message (as well as the usual status blob) which contains either valid data from the arduino or a description of the failure.This includes a novel testing approach which:
connects to the robotd Board instance
This avoids real
socket
s andmultiprocessing
, both of which incur substantial overhead during tests along with the introduction of timeouts (which is just nasty).This relies on sourcebots/robotd#35.