Chintu turns a Telegram request into a Swiggy Instamart order, an approved Prava payment, and a physical pickup completed by a Raspberry Pi robot.
Send Chintu what you need. It finds the item, presents the exact purchase for approval, completes checkout, follows the delivery, rides its pulley platform down when the rider reaches the gate, collects the package, and brings it back up to you.
▶ Watch the full Chintu demo on YouTube
Chintu inside the pulley platform that carries it up and down between floors.
▶ Chintu leaving the hostel on a mission
Private Telegram chat
|
v
OpenAI interpretation -> persisted Chintu mission workflow
| |
| +-> Mission Control dashboard
v
Live Instamart quote -> Prava owner approval -> Swiggy checkout
|
v
Swiggy MCP order-status polling
|
verified arrival event only
v
authenticated Pi job
|
v
ROS 2 + VSLAM + obstruction safety
|
v
stationary pulley checkpoint
|
v
ESP32 moves DOWN
|
v
navigate to gate pickup
|
v
package secured on robot
|
v
reverse route to pulley
|
v
ESP32 moves UP
|
v
package reaches owner
Every transition is persisted and reflected in Telegram and Mission Control, from clarification and approval through delivery, pickup, return, cancellation, and completion.
- Telegram is the private owner interface for requests, clarification, the Prava approval link, payment results, delivery progress, and robot updates.
- The Chintu workflow keeps the quote, approval, payment, checkout, order, and robot lifecycle connected as one mission.
- Swiggy Instamart provides live product and order data through
get_orders/track_order; only the correlated arrival event dispatches Chintu. - Prava binds owner approval to the exact purchase before checkout.
- The Raspberry Pi agent connects outbound to the backend, reports hardware health, receives authenticated jobs, and synchronizes the pickup lifecycle.
- ROS 2 and RTAB-Map provide visual SLAM, measured odometry, AprilTag route checkpoints, obstruction handling, motor watchdogs, and emergency stopping.
- The ESP32 pulley controller moves the platform down and up through a BTS7960, with normally-closed limits, keepalives, timeouts, and latched faults.
Chintu has completed this flow as a physical system. Secrets, OAuth sessions, route maps, GPIO assignments, and calibration values are specific to each Chintu installation and stay outside the repository.
OpenAI interprets the owner's request; the persisted workflow owns authority. The backend decides when an order may dispatch, while the Pi decides whether local motion is safe. Payment, delivery arrival, navigation, and pulley movement each advance only from their corresponding verified state.
Agent API → · Telegram deployment → · Mission Control →
Swiggy-to-Pi bridge → · Navigation → · Pulley firmware → · Physical setup →
Chintu treats commerce and physical fulfilment as one continuous mission. The same state connects the purchase its owner approved to the order being delivered and the robot carrying it home.
Built for the Agentic Commerce Hackathon.
First-time dependency setup:
./scripts/setup.shAfter configuring .env, Swiggy OAuth, and the dedicated checkout browser:
./scripts/dev.shRead the complete setup, test, restart, and troubleshooting guide →
Commission and run the physical autonomous demo →
Scripts: setup · start/stop development
apps/
├── api/ # Chintu agent, mission workflow, persistence, integrations
│ ├── max_api/
│ ├── migrations/
│ └── tests/
├── web/ # Mission Control dashboard
│ └── src/
├── robot/ # Raspberry Pi ROS 2/VSLAM, safety, and pulley integration
└── blinkit-mcp/ # retained unofficial experiment; not part of the Chintu flow
firmware/
└── pulley_controller/ # fail-closed ESP32 pulley controller
docs/ # shared project and operating documentation
scripts/ # dependency setup and local process launcher
