The communication module is responsible for building/creating/receiving and processing packets. For creating packets it receive control from the Control Center module and will encompass all communication with the robot actor. This design conforms to the overall loose coupling of our system as its execution is independent of other modules in the system. This module is broken down into to main applications: send and receiving packets.
The entities that are part of the communication module include:
· Communication Processor: The object responsible for the processed of sent/received packets. Primarily sent packets are motion plans and execution commands (the commands that can be sent are listed in section 6.5). Received packets are primarily status updates from the robot (a complete list of the messages that can be received from the robot is listed in section 6.5).
· Message: An object that contains the compiled data that is sent and received between the station software and the Robot.
· Motion Plan: Is an object comprised of a collection of movement commands. This entity is defined in the Editor Module but is input to the Communication Module by the Control Center Module.
There are few attributes that the communication module has to be concerned with. Namely this is a message type attribute and communication status (sending, pending received, idle).
There are six key functions:
|
Create Packet
|
|
· This function sends an input packet (via a Bluetooth socket connection) to the robot.
|
|
· Input:
o Slot ID (integer)
o Motion Plan ID (unique integer)
o Command Type
o Command Data (specific to the command type, ie: this would be the motion plan for an “upload” command type)
|
· Output:
o Compiled Packet
|
|
|
|
Send Packet
|
|
· This is the function that waits for and receives the packet from the robot. Visual Basic should allow this to run concurrently so that the program does not halt while waiting for a packet.
|
|
· Input:
o Compiled Packet
|
· Output:
o None (a compiled packet is sent)
|
|
|
|
Receive Packet
|
|
· This is the function that waits for and receives the packet via the Bluetooth socket connection created with the robot. Visual Basic should allow this to run concurrently so that the program does not halt while waiting for a packet.
|
|
· Input:
o None ( a compiled packet is received within this function but it is not provided as a parameter)
|
· Output:
o Compiled Packet
|
|
|
|
Process Packet
|
|
· This function takes the packet it receives as input and scans the data. This is done by checking the Command Type ID to discover what type of message the packet holds. Then a response is created by sending an interpreted data response to the Control Center module.
|
|
· Input:
o Compiled Packet
|
· Output:
o Interpreted Data
|
|
|
|
Connect to Robot
|
|
· Creates a Bluetooth connection with the robot by opening up a serial port
|
|
· Input:
o None
|
· Output:
o Boolean indicating success
|
|
|
|
Disconnect from Robot
|
|
· Breaks the Bluetooth connection with the robot and proper closes the serial port
|
|
· Input:
o None
|
· Output:
o Boolean indicating success
|
[Enter text here]
The communication protocol was not defined in the Requirements Specification, but it is important that the protocol that will be used for communication is clearly stated. The first point to consider for Bluetooth communication is who is going to be the slave and who is going to be the master. In out system the station software will be the master and the robot will act interact with it as a slave device.
The communication module assumes this protocol:
One Byte will be used to indicate which type of message is being sent:
|
Command Type
|
Bits Set
|
|
Create Motion Plan
|
0000 0000
|
|
Stop Motion Plan
|
0000 0001
|
|
Update Motion Plan
|
0000 0010
|
|
Execute Motion Plan
|
0000 0011
|
|
Status Update
|
0000 0100
|
|
Query Motion Plan
|
0000 0101
|
|
Adjust Motion Plan
|
0000 0110
|
|
Error Message
|
0000 0111
|
|
Create Trigger Plan
|
0000 1000
|
|
Query Trigger Plan
|
n/a
|
The station team will send all messages (except for the trigger motion plan) to mailbox 7. The robot team will respond to every message sent to mailbox 7 by copying the message into their "out" mailbox 7. This will allow the station team to confirm messages were received.
The required Bluetooth bytes will precede all messages (as specified by the Bluetooth format, these are the bytes that must be sent such as message length, type, mailbox, etc)
- Sent from: Station -> Robot
- Contains the Motion Plan ID and the slot to put the motion plan into on the robot
- An error will be returned if a motion plan already exists in that slot (the user should delete
the motion plan first - the station software should take care of this user path elegantly)
- The message will then contain a series of bytes broken up into 8 bit movement commands:
- Bits 1-3 : indicate which wheels to change speed
- Bits 4-8: indicate the distance to travel (if only a single wheel is being moved it will
indicate the turning degrees)
- Moving increments of 1 cm for with a maximum move distance of 3m
- Turning increments of 3 degrees with a maximum turn of 90 degrees
|
Bluetooth bytes
|
Command Type ID
(0000 0000)
|
Motion Plan ID
|
Slot (0-4)
|
bit 1
|
bit 2
|
bit 3
|
bit 4
|
bit 5
|
bit 6
|
bit 7
|
Bit 8
|
…
|
- Sent from: Station -> Robot
- Only contains the stop ID
- If no motion plan is currently executing the robot will ignore the message and send an error
Back
|
Bluetooth bytes
|
Command Type ID
(0000 0001)
|
- Sent from: Station -> Robot
- Identical to a create motion plan except the command type indicates an update rather than a create
- An error will be returned if the motion plan ID's do not match for the slot
- An error will be returned if no motion plan is in that slot
|
Bluetooth bytes
|
Command Type ID
(0000 0010)
|
Motion Plan ID
|
Slot (0-4)
|
bit 1
|
bit 2
|
bit 3
|
bit 4
|
bit 5
|
bit 6
|
bit 7
|
Bit 8
|
…
|
- Sent from: Station -> Robot
- Slot indicates which motion plan to execute
- Robot will compare the Motion Plan ID sent to the motion Plan ID the robot has in that slot. If they do not match an error message will be sent and no motion plan will be executed
- If no motion plan is in that slot an error message will be returned (and no motion plan will be executed)
|
Bluetooth bytes
|
Command Type ID
(0000 0011)
|
Motion Plan ID
|
Slot (0-4)
|
- Sent from: Robot -> Station
- Return Message contains the motion plan ID and the slot of the currently executing motion plan.
- It then contains a "Step" parameter: an integer indicating which movement command the robot is executing
|
Bluetooth bytes
|
Command Type ID
(0000 0100)
|
Motion Plan ID
|
Slot (0-4)
|
Step
|
- Sent from: Station -> Robot
- Slot indicates which slot ID to query
- The Motion Plan ID sent out is just a dummy parameter
|
Bluetooth bytes
|
Command Type ID
(0000 0101)
|
Motion Plan ID
|
Slot (0-4)
|
- Sent from: Robot-> Station
- Return Message contains the motion plan ID and the slot it is in (Motion Plan ID will be 0 if no plan is in that slot)
|
Bluetooth bytes
|
Command Type ID
(0000 0101)
|
Motion Plan ID
|
Slot (0-4)
|
- Adjust Motion Plan (change speed of wheels)
- Sent from: Station -> Robot
- Similar structure to the "Create Motion Plan" message:
- Byte A: indicate which wheels to change speed
- Byte B: indicate the speed change (range from -100% to +100%)
- An error will be returned if no motion plan is currently executing
|
Bluetooth bytes
|
Command Type ID
(0000 0110)
|
Motion Plan ID
|
Slot (0-4)
|
Byte A
|
Byte B
|
- Sent from: Robot -> Station
- The Error ID will indicate what trouble the robot encountered
|
Bluetooth bytes
|
Command Type ID
(0000 0111)
|
Error ID
|
- Sent from: Station -> Robot
- To create a trigger plan the station software will just send a motion plan (minus the slot ID) to mailbox 5.
- If the robot encounters a trigger situation it will execute any motion plan stored in mailbox 5.
|
Bluetooth bytes
|
Command Type ID
(0000 1000)
|
Motion Plan ID
|
Slot (0-4)
|
bit 1
|
bit 2
|
bit 3
|
bit 4
|
bit 5
|
bit 6
|
bit 7
|
Bit 8
|
…
|
- Sent from: Station -> Robot
- Robot team puts a copy of the "Connection Lost" trigger plan in outbox 5. The station software will check outbox 5 for querying the current trigger plan.
3 Bits are used to describe which wheels should be used for an given movement command. The bit representation for this will be:
|
Wheel(s)
|
Bits Set
|
|
L & R Forward
|
000
|
|
L & R Back
|
001
|
|
L Forward
|
010
|
|
L Backward
|
011
|
|
R Forward
|
100
|
|
R Backward
|
101
|
L = Left Wheel
R = Right Wheel
* There will be no movement commands that move the wheels in opposite directions.
1 Byte will be used to encapsulate the errors that are returned in the "Error Message"
|
Error Description
|
Bits Set
|
|
Create motion plan failed - a motion plan is already in that slot
|
0000 0000
|
|
Update motion plan failed - motion plan ID's do not match
|
0000 0001
|
|
Update motion plan failed - there is no motion plan in that slot
|
0000 0010
|
|
Update motion plan failed - no motion plan currently executing
|
0000 0011
|
|
Execute motion plan failed - motion plan ID's do not match
|
0000 0100
|
|
Execute motion plan failed - there is no motion plan in that slot
|
0000 0101
|
|
Stop motion plan failed - no motion plan currently executing
|
0000 0110
|
|
Adjust motion plan failed - no motion plan currently executing
|
0000 0111
|
Comments (0)
You don't have permission to comment on this page.