search

CPSSD / robots

CA224 robotics project
4 stars 0 forks source link

Added RDP-Protocol Write up #56

Closed RyanConnell closed 8 years ago

RyanConnell commented 8 years ago

Added the write up from the meeting last Wednesday. Also added an image of the State flow chart

DarraghGriffin commented 8 years ago

Looks good to me.

RyanConnell commented 8 years ago

Is this ok with everyone else?

JackSmith54 commented 8 years ago

Yep fine by me

cgmc commented 8 years ago

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?

RyanConnell commented 8 years ago

@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.

conor-f commented 8 years ago

LGTM

cgmc commented 8 years ago

Question: when a stop command is sent, should the id be a new value, or the id of the last move or rotate command?

RyanConnell commented 8 years ago

A new id for the stop command so it will know that the response it gets back is for that command.

cgmc commented 8 years ago

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.

RyanConnell commented 8 years ago

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.

cgmc commented 8 years ago

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.

RyanConnell commented 8 years ago

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.

cgmc commented 8 years ago

Line 24: 360 should be changed to 42, as per issue 54. Apart from that, I think it's fine for now.