Remote Operated Gate Control System

  • Context: Insights 
  • Thread starter Thread starter Greg Bernhardt
  • Start date Start date
Click For Summary

SUMMARY

The Remote Operated Gate Control System project originated in 2017 using a Raspberry Pi 3 with an Adafruit Explorer Hat module, which provided 5V tolerant digital and analog I/O channels, capacitive touch pads, and built-in LEDs. The project employs a finite state machine (FSM) design pattern to manage gate states such as onStarting, onOpen, onClosed, onOpening, and onClosing. Alternative FSM implementations using encapsulated state functions in C++ with std::function and Python were discussed, highlighting the benefits of localizing state logic within function calls. The author ultimately chose a basic polling system FSM for clarity and reliability, avoiding AI-generated code complexity and subtle errors. This approach ensures a robust and understandable control system for real-world digital I/O management.

PREREQUISITES

  • Raspberry Pi 3 GPIO programming
  • Adafruit Explorer Hat module functionality
  • Finite State Machine (FSM) design patterns
  • Python function-based state management

NEXT STEPS

  • Implement FSM using Python functions as state handlers
  • Explore C++ std::function for real-time USB device parsing
  • Study polling systems versus event-driven FSM architectures
  • Investigate AI-assisted code generation pitfalls in embedded systems

USEFUL FOR

Embedded systems developers, Raspberry Pi hobbyists, control system engineers, and programmers interested in finite state machine implementations for hardware interfacing and real-time digital I/O control.

Messages
19,921
Reaction score
10,968
This project began life in 2017 when the author had just begun experimentation with GPIO pins on a Raspberry Pi 3. At that point in time a greatly appreciated Christmas present was an “Explorer Hat” module which provided the aspirant programmer with 5 volt tolerant input and output channels (analogue and digital) , capacitive touch pads, built in light emitting diodes (henceforth referred to as LEDs) and a breadboard on which to build proto-type i/o systems. The module is apparently no longer stocked (not by Adafruit anyway) but was certainly a useful “training ground” for programs which have digital inputs and outputs from/to the real world.

https://www.physicsforums.com/insights/remote-operated-gate-control-system/
Author: @neilparker62
 
Engineering news on Phys.org
Cool project. State machines can be very effective. I find the design pattern used here kinda ugly. For certain, it works, but an alternative I've found useful is to encapsulate States as functions. In a recent project I needed to parse bytes from a USB device in realtime. In c++ states were std::function<void(char c)> objects. The state functions are members of a class and there is a class member that stores the current state. Of course, this state variable is set inside state functions. What I find nice about this all decisions are local to a function call. The main loop of the state machine just calls the State member over and over.

In python, things are even easier. Functions are data just like in LISP.
 
  • Like
Likes   Reactions: neilparker62
Paul Colby said:
Cool project. State machines can be very effective. I find the design pattern used here kinda ugly. For certain, it works, but an alternative I've found useful is to encapsulate States as functions. In a recent project I needed to parse bytes from a USB device in realtime. In c++ states were std::function<void(char c)> objects. The state functions are members of a class and there is a class member that stores the current state. Of course, this state variable is set inside state functions. What I find nice about this all decisions are local to a function call. The main loop of the state machine just calls the State member over and over.

In python, things are even easier. Functions are data just like in LISP.
Thanks for the comment(s). Re functions: Yes - the AI engine wanted to go that way but I got a little confused by all the "defs" it came up with and couldn't keep track. As I mention in the article it's so easy for AI to make subtle programming errors which you won't notice unless you know exactly what's going on yourself. So I stuck to the basic polling system which I had "invented" (and therefore understood) prior to AI extracting a finite state machine from it!
 
There should be one (and only one) def per state. onStarting, onOpen, onClosed, onOpening, and, onClosing. Anyway, a working solution is a working solution.
 

Similar threads

  • · Replies 2 ·
Replies
2
Views
6K
  • · Replies 0 ·
Replies
0
Views
3K
  • · Replies 2 ·
Replies
2
Views
3K
  • · Replies 5 ·
Replies
5
Views
3K
  • · Replies 11 ·
Replies
11
Views
4K
Replies
3
Views
2K
Replies
4
Views
5K
  • · Replies 14 ·
Replies
14
Views
7K
  • · Replies 3 ·
Replies
3
Views
2K
  • · Replies 1 ·
Replies
1
Views
13K