harvest-automation issueshttps://gitsvn-nt.oru.se/hkan/harvest-automation/-/issues2020-07-30T10:03:08Zhttps://gitsvn-nt.oru.se/hkan/harvest-automation/-/issues/5Improve TLV type msg handling2020-07-30T10:03:08ZNicholas ShindlerImprove TLV type msg handlingdata arrays are sent from the robot as tlv type messages. they are not being handled efficiently at the moment.
currently they are parsed into a hex string representation and must be converted back to a byte string before being parsed as an array.
it would be best to eliminate the need to reformat the datadata arrays are sent from the robot as tlv type messages. they are not being handled efficiently at the moment.
currently they are parsed into a hex string representation and must be converted back to a byte string before being parsed as an array.
it would be best to eliminate the need to reformat the datahttps://gitsvn-nt.oru.se/hkan/harvest-automation/-/issues/4Add in odometry state protection2020-07-31T13:50:02ZNicholas ShindlerAdd in odometry state protectionadd in protections to prevent odometry jumping when the robot settings are changed
The though on this is that currently the odometry comes from the robot, and is read only, there should be a way to create a service that sets the current position and orientation of the robot based on what the client side thinks that it should be.
This would be useful when switching robot 'modes'. when the robot switched from following to spacing the odometry is reset. to prevent this happening the best solution it to detect when this happens and set the position to whatever it was before the reset.
This will require finding the correct probe to do this and creating a ROS service that performs that task.
Additionally when this feature has been added it may be beneficial also add a feature to automatically preserve location when the robot task state switches.add in protections to prevent odometry jumping when the robot settings are changed
The though on this is that currently the odometry comes from the robot, and is read only, there should be a way to create a service that sets the current position and orientation of the robot based on what the client side thinks that it should be.
This would be useful when switching robot 'modes'. when the robot switched from following to spacing the odometry is reset. to prevent this happening the best solution it to detect when this happens and set the position to whatever it was before the reset.
This will require finding the correct probe to do this and creating a ROS service that performs that task.
Additionally when this feature has been added it may be beneficial also add a feature to automatically preserve location when the robot task state switches.https://gitsvn-nt.oru.se/hkan/harvest-automation/-/issues/3Add Line Sensor2020-07-31T13:53:45ZNicholas ShindlerAdd Line Sensorcurrently lidar data is only published when a whole scan has been taken, determine if each reading can be published in real time. this would give an option to get scan data as it happens, rather than waiting for all the data to be collected and published in a point cloud.
To implement this, the probe that returns a single beam from the range finder must be found, and then the angle of the beam must be determined as well.
finally a new sensor class must be created and publish a [LaserScan](http://docs.ros.org/melodic/api/sensor_msgs/html/msg/LaserScan.html) message in ROS.currently lidar data is only published when a whole scan has been taken, determine if each reading can be published in real time. this would give an option to get scan data as it happens, rather than waiting for all the data to be collected and published in a point cloud.
To implement this, the probe that returns a single beam from the range finder must be found, and then the angle of the beam must be determined as well.
finally a new sensor class must be created and publish a [LaserScan](http://docs.ros.org/melodic/api/sensor_msgs/html/msg/LaserScan.html) message in ROS.https://gitsvn-nt.oru.se/hkan/harvest-automation/-/issues/2Error handling2020-07-30T08:59:17ZNicholas ShindlerError handlingError handling should be more targeted, so that at least common errors are handled better.
Also currently only general exceptions are being caught, more specific error excepts need to be includedError handling should be more targeted, so that at least common errors are handled better.
Also currently only general exceptions are being caught, more specific error excepts need to be includedhttps://gitsvn-nt.oru.se/hkan/harvest-automation/-/issues/1Handle Broken Pipe Error2020-07-30T09:02:54ZNicholas ShindlerHandle Broken Pipe Errorthe server will drop the connection occasionally, this should be handled by either reconnecting or exitingthe server will drop the connection occasionally, this should be handled by either reconnecting or exiting