Using Functional Reactive Programming for Robotic Art
summary
Claims a Haskell FRP implementation separates hardware control from behavior, using Haskell FRP to emit continuous position signals rather than motor commands. The team builds a working system for a sound‑sensitive installation of 500+ panels with a web API and web API simulation that lets artists test behaviors without hardware. Simulation catches bugs and lets velocity changes occur mid‑movement; artists read the code more easily but still cannot program it directly, so improved artist‑facing interfaces are required.
AI-written summary · about
chapters (10)
- 0:00Robotic art introduction
- 3:13Artists' low-level challenges
- 6:05What is FRP
- 7:30Demo: Edge Beings
- 13:26Code design logic
- 17:03Modular architecture benefits
- 19:53Artist acceptance and potential
- 21:01Q&A: Collaboration & ownership
- 22:39Beauty and feedback loops
- 24:25Visual languages & tools
related talks
25mGame Programming in Haskell
59mReactive Java Robotics and IoT
25mFrom Fluxus to Functional A Journey Through Interactive Art
20mSoftware-defined declarative synthesizer live-coding in a jupyter notebook
35mProgramming What Cannot Be Programmed: Aesthetics and Narrative
33mProgramming as a Performance
37mDancing with Robots
08mReactronica: Music as a Function of State