Simulator ignores objects in a room when determining the destination of the robot #162
Comments
cgmc
added a commit
that referenced
this issue
Apr 11, 2016
The simulator now takes into account the existence of any objects in the room when determining where the robot's destination will be. References #162.
cgmc
added a commit
that referenced
this issue
Apr 16, 2016
Object detection remained broken because getDestination() was accessing the j'th index in the object array, which was one ahead of where it should have been accessing. Rooms larger than 30 cm square could not be properly created and used because hasInterception() was using a hard-coded boundary check which assumed that the room was 30 cm square. The function has been overhauled, and now uses the start and end points of the line in question in its boundary checks. The room has also been adjusted to test this - it is now 60 cm square, and the single object in the room has been moved accordingly. The room class does not automatically have access to a max() function - it must be referenced from the Arduino header. Finally, I noticed that there was some code duplication in regards to float comparison, so I created two new functions to consolidate the code. References #162.
cgmc
added a commit
that referenced
this issue
Apr 18, 2016
Consider the following scenario: 1. The simulator executes a move command, but encounters a wall or object, stops moving and sets its current position accordingly. The robot is now on the line of the wall or side of object. 2. Another move command is issued, in either the same direction or another which would direct the robot through the wall or side of object. The wall or side of object would be detected, and a valid interception point would be generated, but it would be identical to the robot's current position, and because therefore there would be no translation in x or y when moving to that point, it would not be set as the nearest point to the robot. If no other point could be found that would be closer than the projected destination, that original destination would be returned as the correct destination, even if it would take the robot out of the map or through an object. The code has been modified to compare each valid interception point against the robot's current position, and if a match is found, the simulator "steps back" from the wall or side of object, in order to obtain a translation in x and y towards it, and determines if the signs of translation towards the wall or side of object and towards the projected destination are identical. If so, it returns the robot's current position as the destination (i.e. no movement). References #162.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: