... | ... | @@ -13,14 +13,17 @@ Reader child classes are put in the `Sensors` directory and the classes that are |
|
|
### Creating the class
|
|
|
|
|
|
To create a new function to read data from the HV Robot, the Reader class must be extended. the child class needs to have a `__init__()` function where the *publisher* is defined and saved to a class variable and the required
|
|
|
probes are defined and passed to the parent. the child class also requires a `publish` function that creates the message to be published to a ros topic. data from the robot is stored in the *queue* variable as a dictionary, where the key is the probe name. a reader class can get data from multiple (or a single) probe, but can only publish to a single ros topic
|
|
|
probes are defined and passed to the parent. the child class also requires a `publish` function that creates the message to be published to a ros topic.
|
|
|
|
|
|
### Extending a class to publish to multiple topics
|
|
|
|
|
|
If there are more than one ros topic that requires the same data formatting, such as the IR cameras where there are 4 cameras and therefor 4 topics, there must be 4 classes. however a middle class can be created in the same form as above, however rather than specifying in the constructor the probes that are passed in, the constructor takes the probes as a input variable. then child classes can be created that contain only a constructor where the probes are defined and passed to their parent. Because the topic names in the publisher are defined by the probes, as long as the probes names are different in the child class it will create a unique topic for each instance.
|
|
|
|
|
|
#### Formatting the data
|
|
|
The writer will take either a list of messages or a single message. if you send a single message, and there is only a single probe associated with the class, then a single probe-message tuple is created, if there are multiple probes associated with this class, then each probe is sent the same message. If a message array is passed and there are multiple probes defined, then the two arrays will be zipped together, and if they are not the same length then it will raise an exception. messages are associated to probes sequentially, so data at index 0 is paired with probe at index 0.
|
|
|
|
|
|
Data from the robot is stored in the *queue* variable as a dictionary, where the key is the probe name. a reader class can get data from multiple (or a single) probe, but can only publish to a single ros topic.
|
|
|
|
|
|
**IMPORTANT**: if the data is of the *TLV* data type (such as a laser scan), it is formatted as an array of hexadecimal numbers separated by a `:`. each hex number in the array is the integer representation of a *char* and to use the data it must be converted back to a char string and then unpacked using the `struct.unpack` method using the proper data type (int/float) where each char is 1 byte. The LIDAR sensor class can be used as a example of this process.
|
|
|
|
|
|
### Adding to options
|
|
|
All new controller classes need to be added to the options in the parser controller argument, and subsequently to the all services list as well as the controllers list in `main_node.py`. This requires creating an Enum value for the controller as well as defining it as a variable in `config.py`. finally the class needs to be added to the *cmdr* list in the `hv_client.py` constructor. |
|
|
\ No newline at end of file |
|
|
All new sensor classes need to be added to the options in the parser sensor argument, and subsequently to the all services list as well as the sensor list in `main_node.py`. This requires creating an Enum value for the sensor as well as defining it as a variable in `config.py`. finally the class needs to be configured to be able to be added the *lstnr* list in the `hv_client.py` constructor. |
|
|
\ No newline at end of file |