The configs JSON is the primary way to seed the AVL tree with a complete set of obstacles in a single request. It combines simulation-wide settings (road length, car physics, update rate) with a batch list of obstacles to insert. The entire payload is validated server-side byDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/tutosrive/avl_tree_car/llms.txt
Use this file to discover all available pages before exploring further.
Utils.validate_json_configs() before any inserts take place — if any required field is missing or malformed, the tree is left untouched and a 400 error is returned immediately.
Full JSON structure
The example below is the canonical test payload from the project README. Post this toPOST /avl/add/configs to seed the AVL tree with eight obstacles across a 1 000-unit road.
configs object fields
The configs object carries simulation-wide parameters. total_distance and jump_height are the only two fields validated as required by the server; the remaining fields are consumed by the frontend.
Total road length in units. Defines the span of the simulation track that the car travels.
Maximum jump height for the car in units. Used by the frontend to calculate jump clearance over obstacles.
Car speed in units per tick. Controls how fast the car advances along the road each update cycle.
Frontend update interval in milliseconds. Determines how frequently the simulation state is re-rendered on the client side.
Hex color codes used to tint the car sprite (e.g.
["#F54927", "#8F2510", "#BD2C11"]). The frontend cycles through these values for visual variety.obstacles array
Each element of the obstacles array describes one road obstacle to insert into the AVL tree. The server iterates the list, constructs an Obstacle object for each entry, and attempts an AVL insert. Successfully inserted obstacles are tracked by the auto-generated random ID assigned at construction time.
Horizontal position of the obstacle on the road, measured in road units from the start of the track.
Vertical position or height of the obstacle in units. Used by the frontend to determine collision geometry.
Obstacle type name in lowercase (e.g.
"rock", "cone", "tire"). Must match one of the ten type names defined in obstacles_types.json. See Obstacle Types for the full list.The configs JSON uses the string
type field (e.g. "rock"). Direct single-node calls to POST /avl/node/add use type_id (the numeric ID) instead. See Obstacle Types for the mapping between names and IDs.Validation rules
The server runs all checks in sequence and returns on the first failure. No obstacles are inserted until the entire payload passes validation.Response shape
A successful request returnsstatus: 200 with the list of auto-generated IDs for every obstacle that was newly inserted. A failed request returns status: 400 or status: 500 with details in error.
HTTP-style status code embedded in the JSON body.
200 on success, 400 on validation or duplicate errors, 500 on an unexpected server error.true when at least one obstacle was inserted successfully; false on any error.Human-readable result message, e.g.
"The configurations has been added succesfully!" on success or "There are some errors in the sent data!" on a validation failure.List of obstacle IDs (random 8-character strings) that were successfully inserted into the AVL tree. Empty on failure. Each ID uniquely identifies an
Obstacle node and is used to reference that node in subsequent operations.Error details on failure. Contains the validation error string (e.g.
"Missing 'configs' section") or the exception message on a server error. null on success.