We could look into using the negotiated MTU on the firmware side so we can send whole messages in one go.
I was initially thinking we could send pre-formatted strings, in order to limit the device specific stuff we need to add to Pybricks Code. But if make device specific visualizations anyway, we can look at packing a single port value into a 19 byte message, which should be feasible.
These implementation details are probably worth discussing here in a separate issue. Pre-formatted strings sounded nice at first, but we'll also be applying device-specific visuals such as the motor angle or detected color. So if we're going to unpack and parse the strings in Pybricks Code anyway, we should probably come up with a protocol after all. Then it can be packet-based too, avoiding streaming issues.
As with any protocol, this means we'd need something properly versioned, so Pybricks Code knows how to display it. Maybe it needs to be part of the existing hub protocol version.
Information we need to send for each port:
Device ID
Motors:
Data: Angle in degrees (LE int32_t), speed in deg/s.
Visual: Motor angle on shaft, and total degree value (no need for separate modulo degrees and rotation count). Maybe speed on a vertical slider? The numbers change too fast to read them.
Commands:
Reset angle, by clicking on the motor?
track angle (future)
Ultrasonic sensor:
Data: distance in mm.
Commands:
Set threshold. Perhaps with a field and slider. And then we can visually turn the lights on if closer than threshold. This lets you instantly explore the usefulness of the sensor. Default to 200 mm?
Color Sensor:
Data (reflect mode): HSV, intensity
Data (ambient mode): HSV, intensity
Commands:
Set mode, by clicking on the lights?
Set detectable colors (future)
Note: I'm thinking we should perhaps not show the rounded color like Color.RED. Because this creates the impression that only the default colors are possible. It would be great to do something interactive with the detectable colors, but that is perhaps for a future version. Maybe just show the HSV as-is for now?
And so on. In essence, what we have already done in the port script, but we'd need to formalize it. Perhaps something like:
PORT_ID | TYPE_ID | DEVICE_SPECIFIC_VALUES
It is the same for internal things like the gyro, but with a special ID representing itself, and an identifier for the internal device.
And for the reverse, setting data:
PORT_ID | COMMAND_ID | PAYLOAD
This is primarily for setting the mode. And for setting the motor position (more on that later).
(At this point, should we just implement it in C, or go for the whole LWP3 protocol? :smile: Nah, probably not.)
Originally posted by @laurensvalk in https://github.com/pybricks/pybricks-code/pull/2315#issuecomment-2383150449
These implementation details are probably worth discussing here in a separate issue. Pre-formatted strings sounded nice at first, but we'll also be applying device-specific visuals such as the motor angle or detected color. So if we're going to unpack and parse the strings in Pybricks Code anyway, we should probably come up with a protocol after all. Then it can be packet-based too, avoiding streaming issues.
As with any protocol, this means we'd need something properly versioned, so Pybricks Code knows how to display it. Maybe it needs to be part of the existing hub protocol version.
Information we need to send for each port:
Motors:
Ultrasonic sensor:
Color Sensor:
Note: I'm thinking we should perhaps not show the rounded color like
Color.RED. Because this creates the impression that only the default colors are possible. It would be great to do something interactive with the detectable colors, but that is perhaps for a future version. Maybe just show the HSV as-is for now?And so on. In essence, what we have already done in the port script, but we'd need to formalize it. Perhaps something like:
It is the same for internal things like the gyro, but with a special ID representing itself, and an identifier for the internal device.
And for the reverse, setting data:
This is primarily for setting the mode. And for setting the motor position (more on that later).
(At this point, should we just implement it in C, or go for the whole LWP3 protocol? :smile: Nah, probably not.)