-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement and Test VirtualJointKinSensor in ICub wearable device #32
Comments
The
Upon preliminary investigation, this error output is during the call to the One wild bug that may be happening is, that @diegoferigo let me know if you can think of something. Thanks. |
I did more debugging and discovered that the first joint sensor status setting is failing at times this is probably dude the failure to call correct encoder interfaces. So, I updated the interface pointer handling in joint sensor constructor e69b83a and now |
@Yeshasvitvs As discussed f2f, please move the code that can fail from the constructor to a separated method, and call it after the objects are contructed, handling possible errors. Also, check the return value of the yarp interfaces. |
@diegoferigo I ran into a tricky situation! Now, the tricky part is, when I run wrapper and remapper, they expect some kinda update from the newly added sensor type as they are build with the new sensor implementation. But as the xsens suit device is not built, it will not give any update on this sensors I think. So, the wrapper is kinda stuck in waiting for first data during the device CC @lrapetti |
I didn't fully understood the problem @Yeshasvitvs. Is your recording fresh from yesterday? |
No the recording is an old one without the ‘()’ for the newly added sensor. Is there a way to control the type of sensors to be handled by wrapper and remapped ? |
This is what I suspected. I fear that the thrift message must be complete at the moment, even if I marked the fields as optional. Though, this behavior has never been tested. I am not even sure that having an optional field means the possibility of not having the |
I think the catch is inside the wrapper and remapper. Inside the wrapper run() we are calling all the sensors. If a wearable device doesn't have a sensor implemented, then that sensor data place holder in the wearable message is plain I know this is a bit of unnecessary control over the sensors but I think it will be a good option for future wearable devices that may depend on some sdk to be necessary to build a particular wearable device. |
This would be an overkill and unnecessarily complicated. I am pretty sure that somehow this can be sorted out in the thrift level, but I did not have enough thrift hands-on to point you to the right solution. The problem is still not 100% clear to be honest. If I understood, this happens only if producer (e.g. |
Addition of new sensors like the joint sensor needs an implementation of the sensor virtual methods in the wearable devices. The This message is displayed when the attached |
This is not the current situation. All our wearable devices (
They try to read all the sensors, but if the wearable device does not provide any sensor reading for a given type, the thrift map entry of the
As I wrote above, you cannot assume that recordings serialized with an old thrift can be read also after you edited the thrift. This can be done only by telling thrift that some data is optional, and despite I assume there is a way to do it in thrift, how to do it has yet to be investigated. In short, if you change the serialization, old recordings are no longer valid. I suspect that you get that message in |
The callback onRead() of the wearable data buffered port is never called. |
Yeah, that makes sense! |
I tested the |
Following the addition of
VirtualJointKinSensor
#31 in this issue, we track the details related to the implementation of the sensor inICub wearable device
. With this implementation,ICub
wearable device will connect to the robot control boards and stream the joint quantities(position velocity acceleration)
as wearable data.This implementation is done in dae6687 and the data from the robot seems to be parsed correctly as wearable data from the producer side.
Soon I will test this on the consumer side through
IWearRemapper
and see if the wearable data is read correctly.@diegoferigo @lrapetti @DanielePucci
The text was updated successfully, but these errors were encountered: