Closed RyanConnell closed 8 years ago
Looks good to me.
Is this ok with everyone else?
Yep fine by me
Just to note: you cannot return more than one type in C++ (and most languages, I presume). So, the responses actually have to return a struct containing the required primitives, rather than the the primitives themselves. This might be a minor thing that the document can ignore as an implementation detail?
@cgmc This would be up to whoever is writing the wrapper around it. This is just showing what information needs to be sent/recieved between the devices. Go supports returning multiple values so it could work with that, but most likely it would be a response struct.
LGTM
Question: when a stop command is sent, should the id be a new value, or the id of the last move or rotate command?
A new id for the stop command so it will know that the response it gets back is for that command.
Then what of the original id of the last move or rotate command? Will any part of the system be expecting responses with that id? As currently implemented in the simulator, issuing a stop command will change a global id variable, so I can see a case where if a stop command is issued quickly enough, the prior move or rotate command will never see a response with its id.
Then don't keep a single ID variable, have a list of previously used ones that you can refer to if one turns up in the future. This will be needed anyway if we implement scanning and moving at the same time in the future.
Also if you issue a stop command you can ignore any previous responses for other commands due to the fact that the stop command will respond with the information needed to figure out everything you need.
Should we limit the list's size, to say 40 ids? I have looked up the possibility of creating a dynamic-size array, but there are potential issues with heap fragmentation.
Once you get the response from the list you can just dump it. If you go too long with no response and move on, dump the id again. If you receive a response from an ID you don't recognize just dump that response too.
The list wouldn't need to be long as you will only ever be waiting on 2 ids at most (Moving, Scanning) But even that isn't needed at this point in time, as the flowchart shows we will only ever have a single state.
For now just stick with your single id implementation and ignore the response from anything if its not the exact id you are currently dealing with. The stop command will respond with the degree and magnitude it traveled so you wont need to wait for a response from move if its interrupted by a stop command.
Added the write up from the meeting last Wednesday. Also added an image of the State flow chart