FlexSEA Wiki

A WEARABLE ROBOTICS TOOLKIT

User Tools

Site Tools


fxplanstack_newclasshierarchy

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
fxplanstack_newclasshierarchy [2019/08/06 16:28]
yangwill Adding flowchart
fxplanstack_newclasshierarchy [2019/08/15 15:34] (current)
yangwill Added more details about how connecting to the device works
Line 28: Line 28:
 Each of these actions is serviced by a separate thread. So for an opened Device (ConnectionState >= OPEN), there are four threads running for that Device. The streaming and logging threads will always be running even if they are not executing any tasks; <​del>​**this can later be optimized with a condition variable**</​del>​ This has been implemented. Each of these actions is serviced by a separate thread. So for an opened Device (ConnectionState >= OPEN), there are four threads running for that Device. The streaming and logging threads will always be running even if they are not executing any tasks; <​del>​**this can later be optimized with a condition variable**</​del>​ This has been implemented.
  
-Commands are packed into individual Message objects and pushed to a queue to be sent. From a lot of testing, the queue never grows too large and the latency for sending commands is between 8 - 12ms. To ensure ​there are no leftover unsent Messages, the commandSender thread will not stop running until the queue has been cleared. For this reason, we must call the stopStreaming() function before the stopThreads() function.+Commands are packed into individual Message objects and pushed to a queue to be sent. From thorough ​testing, the queue never grows too large and the latency for sending commands is between 8 - 12ms. To ensure ​we send all messages (most importantly that we turn off the controller properly), the commandSender thread will not stop running until the queue has been cleared. For this reason, we must call the stopStreaming() function before the stopThreads() function. Note: if the frequency that we send setPosition commands from the script is extremely high ( > 2000Hz), the queue will back up and shutting down the device will not be immediate. **If absolutely necessary, we can adjust the frequency that we clear the queue by changing the sleep duration in the commandSender thread (it's currently set at 500 microseconds).**  
 + 
 +Opening the Device, tryOpen(). tryOpen is how we establish a serial connection with the ActPack. The function will open the serial port and then send a CMD_SYSDATA_R to the ActPack. **The next step in connecting to the ActPack is handled in the separate deviceReader thread**. The deviceReader thread will process the ActPack metadata and populate the flexseaDevice and Device fields. Only then will the Device class get a devId. This is better visualized in the flowchart above.
  
 Optimization: ​  <​del>​The current thread management will start all the threads when the Device is opened and will not stop any of the threads until the Device is closed. The reason I did not incorporate more granularity is because it makes cleaning up the threads far more complicated and will make it much harder to maintain the code base later. The best way to reduce device idling is to incorporate a condition variable for the commandStreamer and deviceLogger threads as stated previously.</​del>​ Implemented Optimization: ​  <​del>​The current thread management will start all the threads when the Device is opened and will not stop any of the threads until the Device is closed. The reason I did not incorporate more granularity is because it makes cleaning up the threads far more complicated and will make it much harder to maintain the code base later. The best way to reduce device idling is to incorporate a condition variable for the commandStreamer and deviceLogger threads as stated previously.</​del>​ Implemented
Line 44: Line 46:
 FlexseaDevice is where the returned ActPack data is stored. This data can be accessed by CommWrapper::​fxReadData(),​ DataLogger::​logDevice(),​ and possibly directly by the GUI.  FlexseaDevice is where the returned ActPack data is stored. This data can be accessed by CommWrapper::​fxReadData(),​ DataLogger::​logDevice(),​ and possibly directly by the GUI. 
  
-**Might be good to change the name of FlexseaDevice to better reflect its function, I name the instance of it "​serialDevice" ​in the Device class.**+**Might be good to change the name of FlexseaDevice to better reflect its function, I named the instance of it in the Device class as "​serialDevice" ​.**
  
  
fxplanstack_newclasshierarchy.txt · Last modified: 2019/08/15 15:34 by yangwill