Mario Kart Live: Home Circuit - Revision history

CFSworks: /* Type 0x01: Battery Status */ First byte actually indicates cable status

2021-02-26T17:10:12Z

Type 0x01: Battery Status: First byte actually indicates cable status

← Older revision		Revision as of 20:10, 26 February 2021
Line 479:		Line 479:
	\|-		\|-
	\|0x0		\|0x0
	\|~~0x3~~		\|0x1
			\|Cable status bitmask: 0x1 = Cable connected; 0x2 = Unknown; 0x4 = Unknown
			\|-
			\|0x1
			\|0x2
	\|Zero padding		\|Zero padding
	\|-		\|-

CFSworks: /* Network protocols */ Never mind about "Fuji Update" - I don't know what this RCD service is

2021-02-19T11:19:09Z

Network protocols: Never mind about "Fuji Update" - I don't know what this RCD service is

← Older revision		Revision as of 14:19, 19 February 2021
Line 171:		Line 171:
	\|-		\|-
	\|5107		\|5107
	\|"~~Fuji Update~~" RCD service		\|Unknown ("Event"?) RCD service
	\|0x0103		\|0x0103
	\|-		\|-

CFSworks: /* Type 0x02: IMU */ Fix units

2021-02-19T11:06:14Z

Type 0x02: IMU: Fix units

← Older revision		Revision as of 14:06, 19 February 2021
Line 510:		Line 510:
	\|0x2		\|0x2
	\|0x1		\|0x1
	\| colspan="2" \|Flags bitfield: ~~PCCCCNNN~~. P=High-precision, C=Unknown, possibly clipping indicators. N=Number of IMU samples.		\| colspan="2" \|Flags bitfield: IGA??NNN. I/G/A=High-precision units used, ?=Unknown, possibly clipping indicators. N=Number of IMU samples.
	\|-		\|-
	\|0x3		\|0x3
Line 527:		Line 527:
	\|0xC		\|0xC
	\|Integrator A position		\|Integrator A position
	\| rowspan="2" \|s32 x, y, z; gives an estimate of total displacement since this integrator was reset. Units: 24.59 * 2^-19 m(~~???~~)		\| rowspan="2" \|s32 x, y, z; gives an estimate of total displacement since this integrator was reset. Every 6ms step: pos += vel>>12; Units: (40960.006)² 2^-30 m (I=1), 78.4348 * (40960.006)² 2^-30 m (I=0)
	\|-		\|-
	\|0x24		\|0x24
Line 536:		Line 536:
	\|0xC		\|0xC
	\|Integrator A velocity		\|Integrator A velocity
	\| rowspan="2" \|s32 x, y, z; gives an estimate of total change in velocity since this integrator was reset. Units: ~2^-19 m/s		\| rowspan="2" \|s32 x, y, z; gives an estimate of total change in velocity since this integrator was reset. Every 6ms step: vel += acc>>12; (where 'acc' is acceleration in 2^-30 m/s²). Units: (40960.006) 2^-30 m/s (I=1), 78.4348 * (40960.006) 2^-30 m/s (I=0)
	\|-		\|-
	\|0x3C		\|0x3C
Line 545:		Line 545:
	\| rowspan="2" \|0xC*(NNN+1)		\| rowspan="2" \|0xC*(NNN+1)
	\| rowspan="2" \|1-8 raw IMU samples		\| rowspan="2" \|1-8 raw IMU samples
	\|s16 accel_x, accel_y, accel_z; // ~~in units of~~ 0.~~000244 Gs. 1G is~~ added to accel_z to compensate for gravity.		\|s16 accel_x, accel_y, accel_z; // Units: 9.81/4096 m/s² (A=1), 15.99*9.81/4096 m/s² (A=0) (9.81m/s² added to accel_z to compensate for gravity)
	\|-		\|-
	\|s16 ang_vel_x, ang_vel_y, ang_vel_z; // ~~in units of~~ 0.004375 ~~degrees per second~~.		\|s16 ang_vel_x, ang_vel_y, ang_vel_z; // Units: 0.004375 °/s (G=1), 0.1 °/s (G=0)
	\|}		\|}

Line 554:		Line 554:
	The IMU itself is mounted on the PCB "upside down" which gives a reference frame different from what one would expect: While +X does correspond to the driver's right-hand side, the +Y vector extends beyond the rear of the vehicle, and +Z extends out the bottom. All measurements are taken with respect to this reference frame.		The IMU itself is mounted on the PCB "upside down" which gives a reference frame different from what one would expect: While +X does correspond to the driver's right-hand side, the +Y vector extends beyond the rear of the vehicle, and +Z extends out the bottom. All measurements are taken with respect to this reference frame.

	The orientation quaternion is reasonably stable, but should still only be trusted for relative measurements over short periods of time, as the quaternion can drift due to error (noise, clipping, quantization) in the IMU samples. The quaternion is initialized to 1+0i+0j+0k once the IMU is enabled (i.e. when "connection_info" is set).		The orientation quaternion is reasonably stable, but should still only be trusted for relative measurements over short periods of time, as the quaternion can drift due to error (noise, clipping, quantization) in the IMU samples. The quaternion is initialized to 0i+0j+0k+1 once the IMU is enabled (i.e. when "connection_info" is set).

	The integrators are useful in an environment where packet loss is expected to be reasonably high, and so not all raw IMU samples can be reliably collected. The integrators are periodically reset (every 0x2000 samples), as they will accumulate error over time.		The integrators are useful in an environment where packet loss is expected to be reasonably high, and so not all raw IMU samples can be reliably collected. The integrators are periodically reset (every 0x2000 samples), as they will accumulate error over time.

	Both integrators are reset at the same time when the IMU is enabled, but integrator A is reset at sample 0x1000 so that the resets are staggered.		Both integrators are reset at the same time when the IMU is enabled, but integrator A is reset at sample 0x1000 so that the resets are staggered.

	If the 'P' bit is set, the integrator values are multiplied by 78.5(???) prior to being sent, for added precision. The kart will always set the 'P' bit as long as all integrator values are small enough to permit it.

	==== Type 0x03: Motion feedback ====		==== Type 0x03: Motion feedback ====

Cmdblkster: Removed my Sandbox link

2021-02-16T20:04:05Z

Removed my Sandbox link

← Older revision		Revision as of 23:04, 16 February 2021
Line 427:		Line 427:
	=== Teleoperation ===		=== Teleoperation ===

	The kart is operated over UDP port 5102. This port is only open when the kart is in [[~~User:Joel Osler/sandbox~~#Command 0x04: SetState\|drive state]]. It expects packets of the form:		The kart is operated over UDP port 5102. This port is only open when the kart is in [[#Command 0x04: SetState\|drive state]]. It expects packets of the form:

	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"

Cmdblkster: Added new information about the "product_code" parameter

2021-02-16T03:44:58Z

Added new information about the "product_code" parameter

Show changes

CFSworks: /* Type 0x02: IMU */

2021-02-13T04:31:03Z

Type 0x02: IMU

← Older revision		Revision as of 07:31, 13 February 2021
Line 477:		Line 477:
	\| 0xC		\| 0xC
	\| Integrator A position		\| Integrator A position
	\|rowspan="2"\| s32 x, y, z; gives an estimate of total displacement since this integrator was reset. Units: ~~unknown~~		\|rowspan="2"\| s32 x, y, z; gives an estimate of total displacement since this integrator was reset. Units: 24.59 * 2^-19 m(???)
	\|-		\|-
	\| 0x24		\| 0x24

CFSworks: /* Network protocols */ Start documenting some telemetry protocols

2021-02-12T22:57:35Z

Network protocols: Start documenting some telemetry protocols

@@ Line 374: / Line 374: @@
 === Teleoperation ===
-The kart is operated over UDP port 5102. This port is only open when the kart is in [[#Command 0x04: SetState|drive state]] It expects packets of the form:
+The kart is operated over UDP port 5102. This port is only open when the kart is in [[#Command 0x04: SetState|drive state]]. It expects packets of the form:
 {| class="wikitable" border="1"
@@ Line 414: / Line 414: @@
 '''NOTICE:''' ''Home Circuit'' contains logic to detect when the kart is being held, and it locks out the controls in such cases. This logic is not implemented in the kart, which will eagerly follow any valid throttle/steering command given. The kart is not likely to cause injury if operated while held, but nevertheless, if you do so, it is at your own risk.
 = Versions =

CFSworks: /* Teleoperation */

2021-02-12T21:32:26Z

Teleoperation

← Older revision		Revision as of 00:32, 13 February 2021
Line 374:		Line 374:
	=== Teleoperation ===		=== Teleoperation ===

	The kart is operated over UDP port 5102. It expects packets of the form:		The kart is operated over UDP port 5102. This port is only open when the kart is in [[#Command 0x04: SetState\|drive state]] It expects packets of the form:

	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"

CFSworks: /* Network protocols */ Teleoperation

2021-02-12T21:30:10Z

Network protocols: Teleoperation

← Older revision		Revision as of 00:30, 13 February 2021
Line 371:		Line 371:

	Expects 0x20-byte zero-padded application ID (''Home Circuit'' uses "YVCOQ00000000XFB") and retrieves data stored in the kart unique to the application.		Expects 0x20-byte zero-padded application ID (''Home Circuit'' uses "YVCOQ00000000XFB") and retrieves data stored in the kart unique to the application.

			=== Teleoperation ===

			The kart is operated over UDP port 5102. It expects packets of the form:

			{\| class="wikitable" border="1"
			\|-
			! Offset
			! Size
			! Description
			\|-
			\| 0x0
			\| 0x1
			\| Throttle; a signed integer. -128 is full-speed reverse, +127 is full-speed forward.
			\|-
			\| 0x1
			\| 0x1
			\| Steering; a signed integer. -128 is full left, +127 is full right.
			\|-
			\| 0x2
			\| 0x1
			\| Brake light control. 0x00 turns the brake light off, 0x01 turns it on. This is independent of throttle.
			\|-
			\| 0x3
			\| 0x1
			\| Pad byte, apparently always zero.
			\|-
			\| 0x4
			\| 0x4?
			\| Little-endian packet counter. Incremented by 1 for each sent packet. Unknown total size.
			\|-
			\| 0x8?
			\| 0x18?
			\| Zero padding to bring the total packet size to 0x20.
			\|}

			''Home Circuit'' sends these packets at 30 Hz. Any rate that is at least 1 Hz will do, however. The kart will automatically zero the throttle (and only the throttle) if a valid packet is not received in a one-second period, as protection from loss of control.

			The counter appears to be intended as a mechanism for detecting duplicated/reordered packets, as such packets will have a counter that is not greater than the previously-accepted packet and can be quickly discarded. However, it appears to be ignored entirely by the kart. Nevertheless, it is a good idea to include it anyway.

			'''NOTICE:''' The throttle/steering values take effect immediately. ''Home Circuit'' applies smoothing to these values, possibly to simulate the physics of a much more massive kart. However, this smoothing may also be necessary to keep the kart from suffering undue mechanical stress.

			'''NOTICE:''' ''Home Circuit'' contains logic to detect when the kart is being held, and it locks out the controls in such cases. This logic is not implemented in the kart, which will eagerly follow any valid throttle/steering command given. The kart is not likely to cause injury if operated while held, but nevertheless, if you do so, it is at your own risk.

	= Versions =		= Versions =

CFSworks: /* Hardware */ I think I identified the IMU

2021-02-12T03:05:49Z

Hardware: I think I identified the IMU

← Older revision		Revision as of 06:05, 12 February 2021
Line 88:		Line 88:
	\| STM32F		\| STM32F
	\| Responsible for real-time steering and throttle control loops, six-axis IMU acquisition, GPIO, battery status		\| Responsible for real-time steering and throttle control loops, six-axis IMU acquisition, GPIO, battery status
			\|-
			\| IMU
			\| STMicroelectronics
			\| LSM6DSL
			\| Unconfirmed. Mounted "upside-down" on the PCB: +X=right +Y=back +Z=down. Sensitivities: 4.375 m°/s, 0.244 mg.
	\|-		\|-
	\| Li-ion pouch cell		\| Li-ion pouch cell