List of Assumptions we have made on the requirements:
· While a motion plan is being executed by the robot, no other motion plan can be viewed or edited.
· If a motion plan is deleted from the station software it will also be deleted from the robot (If there is a connection to the robot and that motion plan exists on the robot.)
· A motion plan can only be executed if it exists on both the station software and the robot. If a circumstance arises where a user has deleted a motion plan from the station software and not the robot, that motion plan will no longer be valid (it cannot be run anymore.)
· Attempting to load a motion plan into a slot on the robot that already contains a motion plan will cause a warning prompt for the user at which point the user can choose to over write the old motion plan.
· A trigger motion plan will use up one of the 5 motion plan slots available.
· If a command is made to change the real-time execution of a motion plan, the RCR system will no longer guarantee its performance to be 95% accurate.
· The station software will automatically connect to a turned on robot only if: it is not already connected to another robot and the Mac address on that robot has been set to the station software's or the station software’s previous connection was to that robot.
· The RCR’s 95% performance accuracy will only be guaranteed on hard surfaces (not carpet)
· Visual Basic, created by Microsoft for building stand alone Windows-based programs, is derived heavily from Basic. Our group had a discussion while writing the project plan to determine a programming language to implement this project with, debating between C# and VB. Since most of our team members don’t have much experience with C#, VB was selected. It was here that we made a very important technical assumption. that we as developers can use VB to quickly build our GUI application. Since the whole coding part of this project is relying on this assumption, this is a crucial point. If during the processing of implementing, VB is unable to satisfy the requirements of our GUI or it’s extremely hard to use, then we may need to change our plan and that could lead to a delay and the project falling behind schedule.
· The station software will be responsible for ensuring that motion plans have unique ID (we will not assume that the user will provide valid data)
· A motion plan is required to have a minimum of one movement command. This will ensure that motion plan data being sent to the robot always contains at least one valid movement command.
Comments (0)
You don't have permission to comment on this page.