oliverlee / phobos

TU Delft bike lab embedded systems projects
http://spaaaccccce.com/Space_space_space_Going_Going_there_Okay_I_love_you_space_Yeah_yeah_yeah_okay_okay_Atmosphere_Black_holes_Astronauts_Nebulas_Jupiter_The_Big_Dipper_Im_proud_of_you_son_Space_space_wanna_go_to_space
BSD 2-Clause "Simplified" License
1 stars 5 forks source link

Define config protobuf message type #153

Open oliverlee opened 7 years ago

oliverlee commented 7 years ago

This is a build configuration option and can vary for different binaries. We should add the tick frequency to the protobuf message so that we can obtain timing information correctly and other fields related to the ChibiOS configuration.

tentative config schema

enum EnumSetupType {
    SIMULATOR = 0;
    STEERBYWIRE = 1;
}

enum EnumProjectType {
    UNSPECIFIED = 0;
    FLIMNAP_AREND = 1;
    FLIMNAP_KINEMATIC = 2;
    FLIMNAP_WHIPPLE = 3;
    FLIMNAP_ZERO_INPUT = 4;
}

message pbConfig {
    optional EnumSetupType setup = 0;
    optional EnumProjectType project = 1;
    optional FirmwareVersion gitsha1 = 2;
    optional bool build_ndebug = 3;
    optional bool ch_st_resolution_32 = 4; // 16-bit if false
    optional uint32 ch_st_frequency = 5;
    optional uint32 ch_rtc_frequency = 6;
    optional uint32 heartbeat_period = 7; // to be used for two-way communication?
}
mickvangelderen commented 7 years ago

Or you could scale timing information.

oliverlee commented 7 years ago

Right now we record: timestamp - units of system ticks (10 kHz in current master f2c686b, but I want to increase it to 100 kHz in PR #152) computation time - units of realtime counter ticks (168 MHz) transmission time - units of realtime counter ticks (168 MHz)

We could scale to microseconds and transmit. The issue that I can think of is if we reduce the size of the unsigned int use to store/transmit timing information from uint32_t to uint16_t or uint8_t, we'd have to be careful about overflow.

With uint32_t the timestamp will overflow in 4.97 days at 10 kHz and 11.9 hours at 100 kHz.

mickvangelderen commented 7 years ago

The way I see it now there are three options:

1) leave as is, read clock frequencies from .h files

oliverlee commented 7 years ago
  1. leave as is, read clock frequencies from .h files

One issue that could arise is if we use different clock frequencies in different headers/projects, we would need to know which is the right frequency when decoding.

  1. transmit the counter frequencies

I think we could just send the clock frequency once in the first message

mickvangelderen commented 7 years ago
  1. scale to a unit that works for all possible clock frequencies

Floats are precise up to 6 significant digits (23 bits give steps of 2^{-23} \approx 1.19\cdot10^{-7}
).

Usually relative timestamps can be represented by a float but an absolute timestamp cannot. The value must be < 2^23 to prevent loss of precision.

I think we could just send the clock frequency once in the first message

If we can send a few extra bytes per message to make each message individually interpret-able we should.

oliverlee commented 7 years ago

We already do this (dependent messages) for model stuff since we would be retransmitting a lot of data that doesn't change with each message.

On Mar 23, 2017 12:55, "Mick van Gelderen" notifications@github.com wrote:

  1. scale to a unit that works for all possible clock frequencies

Floats are precise up to 6 significant digits (23 bits give steps of [image: 2^{-23} \approx 1.19\cdot10^{-7}] https://camo.githubusercontent.com/6f1545b90841c60597ff1a8c45f08eada0b96aa9/68747470733a2f2f6c617465782e636f6465636f67732e636f6d2f6769662e6c617465783f322535452537422d3233253744253230253543617070726f78253230312e313925354363646f7431302535452537422d37253744 ).

Usually relative timestamps can be represented by a float but an absolute timestamp cannot. The value must be < 2^23 to prevent loss of precision.

I think we could just send the clock frequency once in the first message

If we can send a few extra bytes per message to make each message individually interpret-able we should.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/oliverlee/phobos/issues/153#issuecomment-288695733, or mute the thread https://github.com/notifications/unsubscribe-auth/AC0-J7e57Xo0aiADCeycwozWNmW_Cu1aks5rol2WgaJpZM4MZd_f .

oliverlee commented 7 years ago

I think we need to fully define the protobuf message types, specifically the "configuration type", and the corresponding fields.

This is related to https://github.com/oliverlee/phobos/issues/181

oliverlee commented 7 years ago

I'm also in favor of dropping the Message suffix and replacing it with a pb prefix until namespaces are supported.

mickvangelderen commented 7 years ago

Just thought of something. We should include a session number because that might come in handy. There was a RNG unit on the microconroller right?

oliverlee commented 7 years ago

Let's try to switch to proto3 when implementing this and two-way communication, but fall back to proto2 if it doesn't work.