My little boom-gate has made it to work now and been hooked up to the test automation harness.
This pic should explain the spaghetti reference in the post title…
This may all look a very unsophisticated , but the systems behind this are industrial strength and pretty comlex.
It’s kind of humbling to think of the millions of $’s worth of system and the size of the team that has toiled for well over a year putting the system together that is controlling my dinky boom-gate here.
Tags: Arduino, Boom-gate, Control System, Model, State Machine, Statechart, UML
My project at work at the moment is a large Physical Access Control System (PACS). We have automated some of the testing of physical devices with an I/O interface and API into the control devices.
As a bit of fun I built this to hang off the controller rather than watching events and status updates at a computer console. The code very accurately simulates the behaviour programmed into the PLCs of the actual boom-gates that are controlling access on several mine-sites and ports all across Queensland.
Implementation
The implementation of this project is very simple. (Though the application is a little novel, I think.)
Inputs
- Open Request: I have a push-button switch with a pull-down on the breadboard to test (play) with the application, but in reality this digital input is connected to a (normally-open) relay output of the PACS controller board that takes its direction from the overall system after assessing things like: driver ID (RFID); vehicle ID (RFID); qulaifications; fitness for work; fatigue (external systems).
- Reed Switch: This is to simulate the operation of an induction / safety loop as the vehicle passes over it. (This is a very noisy device and really should be debounced through code or hardware.)
Outputs
- Open State: The boom-gate is considered open the moment it starts to move upward and closed the moment it starts to move down. This is used in monitoring to know whether the gate is open without the “consent” of the control system, which will then raise an alert.
- Safety: This prevents the boom-gate (locally in its PLC / control) from closing while there is a vehicle under it. This is exposed as an output so the system can determine if the vehicle granted access actually drove through the gate or not.
- Servo Position: To open / close the boom arm.
Control
- State Machine: IMHO, this concept sits really well with embedded or control system software. In my application there are only four states and simple rules / actions on the transitions. There are *way* more complex implementations for this out there and, what appears to be, a pretty solid library available for Arduino. All of this seemed a huge overkill for my little application, so I managed my states and transitions via a simple Switch / Case control structure in my code.
// incredibly simple state machine
// check for vslid transitions from the current state
switch(_state)
{
case OPENING:
// current state: Opening
// transition to: Open
// guard: Position >= Upper Limit
// action: none
if (_position >= INCREMENTS)
{
_state = OPEN;
}
// current state: Opening
// transition to: Closing
// guard: Open Request = false AND Safety = false
// action: set Closed
else if (_openRequest == false && _safety == false)
{
_state = CLOSING;
_openState = false;
}
// open boom-gate
else
{
// increment position and set servo
setServoPosition(++_position);
}
break;
case OPEN:
// current state: Open
// transition to: Closing
// guard: Open Request = false AND Safety = false
// action: set Closed
if (_openRequest == false && _safety == false)
{
_state = CLOSING;
_openState = false;
}
break;
case CLOSING:
// current state: Closing
// transition to: Closed
// guard: Position <= Lower Limit
// action: none
if(_position <= 0)
{
_state = CLOSED;
}
// current state: Closing
// transition to: Opening
// guard: Open Request = true OR Safety = true
// action: set Open
else if(_openRequest == true || _safety == true)
{
_state = OPENING;
_openState = true;
}
// internal state activity: close boom-gate
else
{
// decrement position and set servo
setServoPosition(--_position);
}
break;
default:
// current state: Closed
// transition to: Opening
// guard: Open Request = true
// action: set Open
if (_openRequest)
{
_state = OPENING;
_openState = true;
}
}
Construction
This was pretty simple.
- A small project case with a slot cutout to mount the servo motor
- A length of balsa bolted on to a servo horn for the boom
- Cutout in the wood base for the Reed Switch
- Fabricate a metal bracket for the Vehicle to mount the magnet
Links
- Fritzing Project: This is the host site for a great app for wiring up your breadboard circuit and moving through to PCB design. Fantastic piece of software too!
- Arduino Code
Tags: Arduino, Boom-gate, Control System, Model, State Machine, Statechart, UML
I am a simple creature! It made my morning this morning when I discovered a stencil download that added some of the UML 2.2 features to visio (which is floundering somewhere around UML 1.x out of the box…).
“The UML stencil for Microsoft Visio supports all symbols of the UML 2.2, specified in OMG UML Superstructure Specification, formal/2009-02-02, as well as all previous versions, UML 2.1, UML 2.0, UML 1.5, UML 1.4, UML 1.3 and UML 1.1.“
Tags: UML
With the delay from lightening to thunder, the small flash inside my CE device actually came first; followed by me wondering “what the hell was that?”; then the thunder and pretty shortly after was my realisation of what had just happened; followed by my expletive of choice.
I am SO glad that I forked out the extra $’s to get the AUS/US power adapter with the surge protector… Thank you very f*cking much Jackson!!! I should have know better and sent the power through my real surge protector as well. Thankfully all of my equipment attached to my Powersmart board didn’t even shut down.
Two days of relatively solid work to get the build process working, I had just successfully deployed my OS image to the device for the first time and I am never going to see if it actually bloody worked!
I have put too much effort into this in the last few weeks to walk away. I will get on to the competition organisers and see what my options are from here.
Tags: embeddedSPARK
Up to this point, for my embedded SPARK entry, I have been playing with the embedded sensors, actuators and micro-controllers for the Control Stations and RC Cars.
Time to get serious about the core code for the Control System (which, incidentally, is what I will largely be assessed on).
Before I can start developing in anger, I will need an IDE and tool chain to build the Windows CE OS for the device that I won. Being a novice with CE, I’m not too proud to RTFM. The manual provided with the hardware from the competition is very comprehensive and well written. A few pages in, I am confronted with the following:
Recommended Software Installation Sequence.
It’s important to install the software in their proper sequences. Here is the recommended software installation sequence, in numeric order.
- Visual Studio 2005
- Visual Studio 2005 SP1
- Visual Studio 2005 SP1 update for Vista
- Windows Embedded CE 6.0 <– this wasn’t a “next, next…” install, there was a custom step to select the x86 BSP for my device (I missed that the first time and had to return to here and reinstall everything down the line!
)
- Windows Embedded CE 6.0 SP1
- Windows Embedded CE 6.0 R2
- Windows Embedded CE 6.0 R3 <– this wasn’t included in the SPARK your Imagination kit supplied by MS. No biggie, except that I live in the sticks and get 75kB/sec download speed…
- Windows Embedded CE 6.0 R3 Update Rollup <– this was omitted from the instructions that came with my embedded device
- ICOP_VDX6326_60B_BSP.msi
- VDX6326_WINCE600_SDK.msi
- CoreCon_v200_x86_WinCE600.msi
- AutoLaunch_v200_x86_WinCE600.msi
- RegFlushApp_v100_x86_WinCE600.msi
Long story short: 1.5 days later, I have the OS building successfully.I do have 12 warning(s). But hey, if they were serious they’d make them error(s).
Thankfully, now that this is sorted, it is not something that I will likely have to go through again in a hurry. I am thinking about building a virtual instance of a Win 7 machine solely for developing in CE so that I don’t have to have Visual Studio 2005 living along side VS 2008+.
Tags: embeddedSPARK, Windows CE
Physical Setup
The hardware to build a quadrature encoder is pretty simple. For the sensors, you need a couple of photo-interrupters and something to do some very lightweight logic and timing calculations (in my case the Arduino). The encoder is a slotted disk, with equal length and spacing of “light” and “dark”, which rotates through the slot of the photo-interrupters (I will post the circuit that I used in a follow-up). The photo-interrupters need to be spaced at a quarter of a wavelength (1 wavelength = the total length of one light and dark section of the slotted disk.)
For my proof of concept, I bread-boarded the components and used a piece of card, cut to mimic the slotted disk.
The Logic
Below is a table and sequential images showing the sensor outputs. Note that the reference sensor is the left one. (The phase number printed on the card when aligned with this sensor corresponds to the phase in the table.)
| Phase | Sensor A | Sensor B | Image |
|---|---|---|---|
| 1 | 0 | 0 | ![]() |
| 2 | 0 | 1 | ![]() |
| 3 | 1 | 1 | ![]() |
| 4 | 1 | 0 | ![]() |
| 1 | 0 | 0 | ![]() |
| 2 | 0 | 1 | ![]() |
| etc… | etc… | etc… | *Mongkut |
By only looking at the outputs each time Sensor A changes state, we can tell which direction the encoder is travelling.
If we step through the table rows above, when the state of Sensor A changes from 0 to 1 (phase 2 –> 3), the sensor values are both 1. When Sensor A changes from 1 to 0 (phase 4 –> 1), the values are 0 and 0.
Forward Direction
If we now go from bottom to top. When the state of Sensor A changes from 0 to 1 (phase 1 –> 4), the sensor values are 1 and 0. When the state of Sensor A changes from 1 to 0 (phase 3 –> 2), the sensor values are 0 and 1.
Reverse Direction
In simpler terms: when Sensor A is triggered, if both of the sensor outputs are the same, our encoder is travelling forward; if the sensor outputs are different, the encoder is travelling in the reverse direction.
Give or take a negation, this is the exact behaviour of the exclusive disjunction (or exclusive or ; “XOR”) logical connective.
| P XOR Q | Q | ||
|---|---|---|---|
| T | F | ||
| P | T | F | T |
| F | T | F | |
Restructured to look more similar to my sensor output table:
| P | Q | P XOR Q |
|---|---|---|
| T | T | F |
| T | F | T |
| F | T | T |
| F | F | F |
So, this very long-winded look at the sensor outputs and comparison to the “XOR” logic table gives us the following pseudo-code:
When Sensor A changes
if Sensor A XOR Sensor B then
direction = reverse
else
direction = forward
All that’s left to do is to time how long between interrupts on Sensor A; count the number of notches on your disk and calculate RPM to give you the shaft speed. Easy!
I will do another post shortly with the Arduino specifics and code. (TODO: insert link here)
NB: The forward and reverse directions of the encoder, the reference sensor and the logical states represented in each phase are entirely arbitrary. I am sure many examples will have made different assumptions around these conditions and will therefore show variations of the output tables etc. The concepts remain the same, it’s just the detail that changes.
Tags: embeddedSPARK, Sensors













