Closed tuxbotix closed 1 month ago
Just had a brief look, but do I see it correctly, that you subscribe to an Option<Option<T>>
and not an Option<T>
. If so, you have to specify the correct type (double wrapped Option
). JSON is able to flatten this nesting, bincode in the current implementation is not.
Huh I'm a bit confused now, the behaviour you explained seems to be the case, but I assumed the semantics differently:
The node has below additional output:
last_calibration_corrections:
AdditionalOutput<Option<Corrections>, "last_calibration_corrections">,
so I assumed that I need to have a BufferHandle<Option<Corrections>>
to subscribe. Am I mistaken? or should it be BufferHandle<Corrections>
instead?
It should be BufferHandle<Option<Option<Corrections>>>
, as AdditionalOutput
itself already introduces a layer of "optionality". As it is an additional output the node may decide not to produce the output, which in turn is reflected in having a None
as output.
IIRC, there is the missing feature (some might call it a bug) that new cycles do not reset additional outputs to None
s. But that might be a different topic
Aha now I understand what's going on! I'll change the node to remove the extra Option
and see how that works out.
I encoutered this in #1447,
I'm subscribing to an
Option<calibration::corrections::Corrections>
value atControl.additional_outputs.last_calibration_corrections
(current main). In my understanding,subscribe_value
should work and directly give me the deserialisation.For example, these seems to be working?
But it didn't for
Corrections
! While there were no compilation or runtime errors, the deserialised values were garbage, easily verified when comparing the values in aText
panel.But this works:
So it looks like (some?) additional outputs are sent as JSON? or what's going on O.o , is there something wrong with the type itself?