Your first stop for electronics hardware and software implementation.
We have expertise in both hardware and software/firmware design. We are familiar with tightly integrating the two — all our programmers are experienced hardware designers, and vice-versa. We can come in right at the beginning of a project to consult. Or to take on the entire project. Or to carry out any task(s) in between. You can also engage us later, or indeed at any stage, to help you out. We can give you a “reality check” by working as your independent design review team. We can author requirements and verification documents, and do circuit board design from our schematics or from yours.
After the project is complete we can provide installation and commissioning services - whether it’s “ours” or “someone else’s”. And we can provide after-sales service: we can be your engineering troubleshooting and diagnostic services.
No task is too small - though one or two might be too big! And you only pay for what you use - keeping down your fixed costs.
We can’t make an exhaustive list of all our projects, but the following should give you some idea of our capabilities.
We re-engineered a swimming pool water quality meter measuring pH, hardness, alkalinity, and other parameters. We dramatically reduced the cost and complexity over the predecessor, making it pocket-sized and portable. Our client won an industry award for it!
In other consumer projects we have produced wireless battery chargers, a small domestic induction heating module, and a shoulder bag for carrying baby accessories that featured real-time monitoring of contents and smartphone connectivity.
We have designed threat detection devices for biological, chemical, and nuclear threats. We have taken laboratory devices and transformed them into field-deployable equipment, both stationary and hand held. If you have been through a security screening at an airport the chances are good that you have been ‘scanned’ by equipment we have had our hands on.
We’ve worked on fire control for advanced individual weapons, and critical aspects of mine-resistant personnel vehicles. We’ve used military grade GPS for target identification. And we’ve worked on improving the comfort and safety of troops using fast boats. In these roles we have been part of set-aside sub-contracts from major defense contractors.
We’ve designed critical sub-systems and complete devices. We’ve worked on electro-surgical units and medication dispensing devices. We’ve been involved with sterilizing and disinfection equipment. And we’ve implemented several diagnostic and rehab devices. We’ve even looked at devices for accelerating bone fusion after surgery.
We’ve worked in the fields of infusion, ophthalmics, general surgery, endoscopy, orthopedics, and electro-magnetic stimulation.
We have worked on a number of different prototype systems for measuring beer and liquor usage in bars with a view to better inventory planning and waste control. These systems were generally wireless, though in one case we developed an innovative, robust, hot pluggable, serial link that self-re-configured dynamically.
Rather than develop a user interface for a device, adding cost and complexity, it may be preferable to use a smart phone to control, configure, or retrieve data from your new product. We have designed and implemented a number of such special purpose ‘apps’ running on both Apple (iOS) and Android smart phones.
Robo Systems has designed a large number of electronic circuit boards. Some were to prove a concept, some were stand-alone prototypes. Others went through extensive testing and transferred into volume production.
Let’s take a look at a typical hardware design project.
The first step in the design process is a meeting with the client. We’ll work together to develop a list of features (requirements and specifications), and we will agree how we are going to test or verify that each feature has been successfully implemented.
Further client meetings will take place as agreed: Typically each of the following milestones will conclude with a client review before starting work on the next.
This board, typical of many we have designed, has features that find their way onto many a client’s wish list. It measures several inputs, both analog and digital, communicates over a USB link, and controls two 1000 lbf actuators.
Developing a block diagram gives visibility to the architecture and ensures that the desired functionality can be achieved within the constraints of the initial implementation. Problems found result in agreed changes to the requirements or in making different implementation choices.
The schematic represents one implementation of the architecture developed in the block diagram. This is where we address a multitude of details - and it is indeed where the devil is. Questions might include: What should be done in hardware, and what in software? Is a processor chip appropriate? Which one? Do we use battery or ‘wall’ power? Is a backup battery appropriate? What power supplies are needed? Do we have all the inputs and outputs? Any additional features needed to support development and testing?
If the design calls for a microcontroller, we will start firmware development as the schematic is being devised. Firmware will have its own requirements and testing, drawn from the overall requirements. This is reflected in the firmware architecture. Initially code development is limited to what can be run on available development hardware - some implementation features will have to be held in abeyance until the target hardware is available.
Even just a few years ago it was usual to verify the schematic by constructing a breadboard circuit, avoiding the cost of making a printed circuit board. Many modern parts are now so small and so difficult to handle that a breadboard is no longer practicable. System development boards - like the Zigbee wireless mesh network module shown here - can sometimes help. But often the first printed circuit design is considered a ‘throwaway,’ and takes the place of a breadboard.
The schematic is converted into a series of files commonly known a ‘Gerbers.’ There are usually several of these: copper layers, board outline, solder masks, and so on. Although the board design software can do some things automatically, much of the layout is driven by hands-on design engineers. This ensures that things that should be together are kept together, things which should be separated are kept apart, and hot things have somewhere to dump their heat into.
The board design is sent out to be manufactured and assembled. Then after initial checks, we apply power - possibly one section at a time. Now it’s time to install the firmware - there usually is some - and implement target platform specific code. We work our way through the system verification tests - and if it’s just a prototype, we’re done. Although prototype designs are often done with a view to meeting standards and agency requirements, lab testing - if required - and remediation, are follow-on tasks.
The prototype process will produce one to five or so units. What if you want to make 20, or 100, or many more? It is extremely rare for a prototype to be ready for production. If that’s your goal much additional work will be needed. Documentation, design for manufacturing, standards lab testing, and agency approvals - if needed - are all time consuming and costly. Robo Systems is happy to quote and manage these processes for you.
Robo Systems has designed and developed a large number of firmware (software) programs. Some were to prove a concept, some were to exercise popular off-the-shelf hardware. Most were an integral part of an accompanying hardware development project.
Let’s take a look at a typical firmware design project.
An initial meeting with a client will allow us to develop a list of requirements - what the firmware is supposed to do. For each requirement we will have a corresponding test which says how we will verify that it does it. Sometimes it’s just a question of looking at something. Other times a measurement is needed. Requirements may be changed, but only in a controlled manner. Research has repeatedly shown that the two biggest causes of software project overruns are uncontrolled changes to requirements and missing verification criteria.
If the first thing you do in a firmware project is start to type program code - you are not going to like the way we work. The first thing we do is to author the firmware requirements. We involve other members of the project team, as decisions will need to be made about what is done in hardware and what is done in firmware. Micros are now so affordable that it costs less to implement a timer with a processor than to use a legacy 555 dedicated timer chip. The fact that the micro contains millions of transistors whereas the timer contains less than 30 is irrelevant. But if we need to change the time interval, using the processor will avoid re-working components on inventoried boards.
From our initial client meeting we will develop a list of requirements. As well as broad-brush statements about what the device is expected to do, there are other things to consider. We need to state what is supposed to happen when power is turned on … or off. What happens if a button is pressed … once, several times, or pressed and held down? And held for how long? How do we respond to a dying battery? Is meeting some set of standards an eventual goal? Which ones? How long should the device wait for something to happen? What does it do if it does - or does not - happen? And as well as what it should do, requirements can include things it should not do. Generally for every requirement there will be a test to determine if the implementation meets that requirement.
Having the requirements in hand it’s now time to establish the architecture. We’re not talking about gothic and roman arches here, but about writing down what the firmware needs to do to satisfy the requirements - without getting into the important details of how it is to do it. The very act of writing this architecture down forces consideration of things which could otherwise be glossed over or be hidden assumptions.
With requirements and architecture documented, future changes will leave an audit trail and be visible to all in the project.
Using the agreed architecture as a road map, we can think about how the firmware code is to be written to fulfill its mission. Most firmware is originated on commonly available desktop and laptop computers (hosts) running Windows, MAC OS, or Linux. The target microcontrollers are usually very different hardware architectures and often are better off having no operating system software*. An interactive development environment (IDE) running on the host allows origination, editing and saving the target firmware. It also converts it to the target format, and downloads it to the target through programming hardware.
*The KISS principle, which will be handsomely rewarded if agency approvals are later needed.
Having selected a target microcontroller we’ll need to know some things about it in considerable detail. The data sheet (yes, they call it a sheet!) for these parts is typically a few hundred pages. A few thousand is not unknown… We are some way off from having a target to try our software on so we will start with a development board. This will enable us to write some code and see how it interacts with the processor hardware. We may have to use a different pin-out part, and some pins may not be available or be committed to other functions. But much can be done to prepare.
This is one of many such pieces of code written to verify that the target device does what the data sheet leads us to think it does. Putting the basics on a firm footing early in the project retires risk and maintains schedule.
The microcontroller on this board drives a motor. It manages converting low voltage from AA batteries to 20 volts. Then it controls timing, measures how much power the motor is taking, looks at the output position, and a few more things besides. All this magic happens because it is running specially developed firmware. Unlike personal computers - and phones - it has neither keyboard nor screen: it can’t display “Windows has a problem and needs to stop” or similar messages, and it can’t ask the user for help. It has to be self-reliant. This underlies the need for a different approach than that used for ‘computer’ applications: embedded programming.
The firmware is loaded on the target and running. Now we do a formal step by step verification: for each requirement can we carry out the verification test and satisfy it? If all the answers are yes, we are done — on time, and within budget. If it satisfies the requirement, and passes the verification test - but you don’t like it, or want it to do something different, we’re always happy to talk about taking on additional work.
Robo Systems has successfully designed and implemented control systems from the simple to the complex. Applications include temperature control using thermocouples, RTD, and pyrometers; aluminum anodizing (high power) control; waste water treatment; and ion-exchange column management and regeneration. Temperature, pressure, flow and level are just a few of the parameters we have measured and controlled.
No, we don’t do the entire thing. But we do carry out modifications and incorporate additional features such as new measurements or signal conditioning.
Sometimes twentieth century “steam” solutions still have merit. In this case the pre-existing technology was relay based, and it was important that the additional equipment be familiar to the current maintenance staff. We designed this system to control switching two sets of ion exchange columns between ‘standby’ and ‘on-line.’ Magnetic latching relays were used as memory during power failures, and the hardwired logic ran at 120 vac.
We partnered with the supplier of metal finishing equipment to design and implement a stand alone control system for a new aluminum anodizing technique. Targeted towards type 3 hardcoat, it can meet stringent naval specifications. We selected programmable logic controllers as the technology best suited to this environment: The anodizing process uses up to 3,000 amps at 75 volts - over 200 kW - which generates a lot of electrical noise. We engineered, programmed, and installed the entire system. The energy savings are so significant that we continue to get repeat orders for the system.
A major electro-plater was facing environmental difficulties with chrome in waste water - the Erin Brockovich syndrome. We partnered with an environmental solutions research and development company to design a system that removed both chromium and nickel ions from the waste stream. We designed, developed, implemented and installed a system that dynamically switched the waste stream through a variety of ion-exchange columns, controlling pH, temperature, and ionic composition to strip the metals and regenerate the ion exchange columns as necessary.
A schematic translates into a program which reads pushbuttones and controls output power with solid state switches, relays, and motor starters.
