Current notes:

• Upload the sliced model ready for 3D printing.
• Please keep the Wiki and files updates, if you are changing things in your design.
• HeatShield specific function description.
• A worked example? (w/ feedback control).

Done
(23-24.4.2018)

External libraries have been included by the GIT submodules functionality. Compilation is problematic, because the libraries use includes without a path, therefore if compiled from the root directory of AutomationShield, it fails.

Can the CPATH or similar environment variables used to direct the preprocessor to find these?

Project finish: 15.05.2018, 14:00. Exams, Tue, 10:00 starting from 22.05.2018 (mistakes in book up to 20.05.2018, 12 PM)

• Finish hardware (Every single piece is assembled? All is complete?)
• Test the hardware / quality control
• Functions for each shield (input, output, reference functions - anything specific for the individual shield)
• Stick to Arduino API Style, stick to same naming
• Comment code well, comments in the code itself
• Finish Wiki (hardware, software, example)
• PID/Sampling are not part of the shield-specific wikis.
• Create an example for the library (PID control e.g.) This must be well documented, e.g. outputs shown etc.
• Enter the new keywords into keywords.txt (use TAB as separator, otherwise won't work).
• Return all tools and hardware loaned.

Make sure that when the user initializes sampling time for the sampler function, the variable can be used elsewhere, eg. In the PID function.

Redesign of the PID functionality to increase usability and scalability. This is, in essence a continuation of #13 .

@rkoplinger suggested (in person) to move PID functionality in its own class. This, I have initially rejected for I have thought that having something like AutomationShield.pid() would simplify the use of the library from the end users perspective. Then came all the versions for absolute and incremental inputs, then the discrepancies between the tuning constants (Kp, Ki, Kd or Kp Ti Td) and of course saturation, integration windup and all that. @rkoplinger was right, so I have changed my mind.

I think that the PID functionality needs to be redesigned for these reasons. Here are some ideas (not necessarily instructions) how to change it:

• Move PID to its own class PIDClass (constructed as PID)
• Let the PID functionality have its own .h and .cpp files for easier maintenance
• The user could set gains or time constants independently, eg, there could be functions such as PID.tuningKp() and PID.tuningKi... (Can you do PID.tuning.Kp()? that would be even better)
• The user should be able to choose (switch) between the incremental and absolute forms, for example by calling someting like PID.beginAbsolute() (Again, can it be PID.begin.absolute()`) and counterparts.
• The hard saturation and windup function should be called independently and it would not only take the boundaries, but also initialize the proper PID version and code... (PID.windup(float hi, float low) )
• These things could be a sort of an initialization, then the final call could be something like PID.compute(float error) or something like that.

These are just ideas, please contribute.

Finish PCB and parts list ASAP

This issue describes the common tasks needed for an efficient start of a thesis work. This issue is meant for bachelor's theses aimed at the AutomationShield project.

Hardware

Hardware design

• Must follow the AutomationShield Hardware Style Guide.
  This list will be changed and perfected.
• Select an idea from our own and cache or bring your own. Must be a dynamic system ready for feedback control.
• The system must fit on the Arduino R3 layout.
• What is the actuator? What is the sensor?
• Are there any extra sensors that can make the control or identification of the dynamics more interesting?
• Are there any extra actuators that can be added as a form of external and repeatable disturbance?
• Is a reference potentiometer needed?
• Identify any issues that will be difficult to realize.
• The board must not contain ugly, improvised parts. Try to use off the shelf components. Avoid custom manufacturing, 3D printed parts are to be avoided but permitted if there is no other solution.
• Can your board made compatible with the 3.3V boards, such as the Zero?
• Is there enough voltage/current on-board or is external power needed?

DipTrace

• Download and install the Freeware version DipTrace PCB design tool.
• Learn to use DipTrace by tutorials, they are recommended for a beginner. There is an official tutorial in a PDF form, but there are good tutorials on YouTube as well. I would probably recommend the this one by Bme Builds that is how I started.
• We have the editable files for the previous designs. Study, dissect and change them to learn.
• We have our own parts library for the shields. The entire Arduino is there, so you don't have to do that...

Thesis writing

Writing

• Read previous thesis works on AutomationShield.

LaTeX

• Download and install the proTeXt package. (Warning it's a 2GB file.) Alternatively you can download and install just the MikTeX package, but you have to find your own viewer and editor and possibly set up the compilation process manually.
• Read about LaTeX on Wikipedia. Try to compile the example in the Wikipedia article to a PDF.
• Download and look through the STU thesis sample. Try to change things around and work with it.
• I do not think tutorials are necessary, learn as you use it.
  Just as most of other LaTeX users I never "learned" I it, just started using it by dissecting templates and samples, and a lot of Googling.
• Do not worry, LaTeX is a lot easier than it seems. It will grow on you and you will be happy to use it for your thesis.

Software

Software design

• Must follow Arduino customs and styles.
• • Must follow the AutomationShield Software Style Guide.

GitHub

• Join the GitHub community by registering to the service.
• Download the desktop tool.
• Mess around with your own trial repository.
• Command line level Git is not necessarily needed for this scope of work.
• Don't get intimidated by the language of Git, this can be daunting at first.

Others

• Register an account on Dropbox if you don't already have one.
• Ask to join the shared folder for previous designs and DipTrace libraries.

Work style

General

• Trying hard and then failing is not such a big deal. That's how you learn.
• Don't do sloppy work, try to be precise and careful.
• Meet each week to discuss progress.
• Don't leave writing the thesis to the last minute, start to work on the text as soon as possible.
• A bachelor's or diploma thesis is actually a scientific work.

How to handle @gergelytakacs

• I am never really satisfied, but that's okay.
• I tend to blurt out a lot of things to do and issues to solve during the weekly consultation meeting. I assume you can prioritize and see what's important and what's not that important. If not, ask me.
• Ask questions. A lot of them.
• Sometimes I only have a half-assed idea, it's up to you to finish and execute. Don't expect detailed instructions on everything.
• Consult your Google Calendar for the most up-to date information about consultation times. I try to stick to a pre-set schedule, however, sometimes I am forced to move around the meetings.
• I have no clue nor interest on the administrative side of submitting a thesis and the required paperwork.
• If you think I'm wrong or mistaken, say it freely. I do not want to breed "yes-men", I want you to think for yourself.
• Respect hardware and try not to ruin it, but an occasional "magic black smoke" is not a tragedy, it happens and I consider it a part of learning.
• I do not tolerate any sort of plagiarism.
• If you have read this text up to this point, email me a picture of a raccoon.
• I expect pretty drawings and photos in your thesis done by you personally. Will haggle you until its done.

Skills you will learn

Every thesis work is a bit different, so is every student. Do not forget that you are doing this to learn, so you can eventually say (maybe on your CV) that you know

• PCB design, CAD software for PCB layout (DipTrace, but if you know one, its easy to learn others)
• C/C++
• Microcontroller programming (AVR architecture)
• Electronics
• Feedback control
• System identification
• Version management by Git
• Kanban basics
• Professional text preparation in LaTeX
• and more...

Arduino's constrain function is for integers, we need the same for floats.

Development

Put an empty .development in the root folder in order to edit the examples and while working. Don't itegrate the file into the Gi repo!

Build status

• Travis CI is used to do automated build tests, you can see the master build status here:

Naming conventions

Please stick to the Arduino API style guide that can be found here when writing the shield API's.

Namely:

• Use begin() to initialize a library instance, usually with some settings. Use end() to stop it.
• Use read() to read inputs, and write() to write to outputs, e.g. digitalRead(), analogWrite(), etc.

According to this the AutomationShield library will use:

• begin() to initialize the board.

• sensorRead() to read the outputs "y",

• referenceRead() to read reference "r" (if there is one) and

• actuatorWrite() to send input ''u".

• calibration() to perform optional calibration tasks before moving into the loop.

• bool _wasCalibrated is a Boolean flag to read calibration status.

All boards should use these basic functions so that the library remains consistent. Determine which type of input/output will be likely most used by the user and use those in these functions. If you want to use more types of sensor readings (voltage, physical units etc.) then it is suggested to get creative based on this. Such as

• sensorReadVoltage() to read the outputs "y" in V,
• sensorReadCelsius() to read the outputs "y" in degrees Celsius, etc.

Pins locations for the inputs and outputs should be stored as #define tokens. Use all capitals and begin the token with the name of the device, continue with an underscore, variable symbol of the quantity and the word pin. So, for example the output pin of the Opto shield will be OPTO_YPIN. Other examples of these tokens are:

  #define OPTO_RPIN 0   // Potentiometer runner (Reference, r)
  #define OPTO_YPIN 1   // LDR (Sensor)
  #define OPTO_YAUX 2   // Auxiliary LDR
  #define OPTO_UPIN 3   // LED (Actuator)

Header files for hardware API are named after the hardware, contain capitals. For example for the Magneto device the full name will be MagnetoShield, thus the API for the device will be initialized in the MagnetoShield.h header not magnetoshield.h. Similarly, the API will have the class, methods and other things in the MagnetoShield.cpp source file.

The API for the particular hardware will use the common header AutomationShield.h, which in turn will load other basic headers such as Sampling.h and PID.h. Thus, in the end, the user should just load the particular header in the example file, such as MagnetoShield.h.

The header (*.h) should just contain forward declarations of programming entities (e.g. void function()) but not the actual functions, these go into the source (*.cpp)

For naming functions use camel case, not snake case. Avoid underscores, if possible. Thus, you should use - myAwesomeFunction(), instead of my_awesome_function(). This is a thing of preference and consistence.

3.3 V compatibilty

• New shields (except some older ones) have been designed to be 3.3V compatible. Thus, you have to compensate for the AVR devices, which have a 5 V logic. This can be done by setting the reference of the ADC to the external pin, which in turn should be connected to the 3.3 V pin on hardware. To do this, you can call in the begin() method: analogReference(EXTERNAL). See more here.

MATLAB

If you want to include experimental measurements, use the following naming conventions for the mat files:

• C_ - from control
• ID_ - from identification
  use any other information next and finish with the sampling rate. Thus a control experiment by PID sampled at 3000 microseconds will be C_PID_3000us.mat.
• Careful of file naming and letter case. Windows doesn't care, Linux does. myFile.mat will work on Windows if you refer to it with lower case myfile.mat, it won't on Linux (e.g. when testing CI).
• In MATLAB examples instead of clc and clear use startScript in the beginning, otherwise the continuous integration will fail, since the clear command clears those variables needed for CI. (startScript defines some exceptions for clear).
• The variable to signify a CI run is CI_Test. You can test its existence with exist() to run CI specific parts of your code.
• Algorithms that are expected to run for long times need to be curbed in CI. For example use an existence test for the variable CI_Test, which will limit solver iterations, optimization runtime, etc. (this is really specific to your application).
• All scripts for examples must be self-contained. Script B should not need Script A to be run since a) the user does not know this and b) neither does CI. If you want to split examples, that is fine - but save the results to a *.mat file. For example modeling runs, but the model is saved and loaded in control examples. Don't just assume that a variable exists in the workspace.

Library file and folder structure

• Details on the include paths and library structure are found here.
• All *.h files must have an include guard macro, according to the FILENAME_H pattern.

Printing to serial
The primary point of any example is to output dynamic measurements to the plotter or for logging. Therefore any kind of diagnostic data is subject to conditional compilation, enabled by flags of the user. This functionality inside the header and cpp files is realized by the
AutomationShield.serialPrint("Message");
method. Please DO NOT USE the regular Serial.print() function inside header and realization files.

Shield releases

• If there are more hardware versions of particular shield being developed, in software use token #define SHIELDRELEASE n to distinguish between different versions. The n should represent release order of specific version.

ATSAMD Compatibility

• Assume 10 bit ADC resolution in order not to complicate things. ATSAMD has configurable resolution.
• Assume 3.3 V ADC reference, boards should be compatible with the R3 for non-AVR boards.
• Serial works without changes. The board does not reset upon accessing serial link, unlike in the case of AVR. Push reset button manually.
• analogRead works without changes (but tolerates only 3.3 V!). Unless changed, the resolution is still 10bit. So by default 1023 level is 3.3 V.
• If necessary use preprocessor directives to use different portions of code for different architectures. See more here, however, this seems not to work for the Arudino Zero, since its environment variable is ARDUINO_ARCH_SAMD and not ARDUINO_ARCH_SAM. So the following example works

#if defined(ARDUINO_ARCH_AVR)
  // AVR-specific code
#elif defined(ARDUINO_ARCH_SAMD)
  // SAM-specific code
#else
  // generic, non-platform specific code
#endif

or to a more C standard

#ifdef ARDUINO_ARCH_AVR
  // AVR-specific code
#elif ARDUINO_ARCH_SAMD
  // SAM-specific code
#else
  // generic, non-platform specific code
#endif

in this case of course you may employ #ifndef etc. preprocessor directives.

You may consult this tutorial for a decent start on C preprocessor basics for the Arduino IDE.

Others

• Include a description as a comment at the beginning of files
• Comment line-by-line in great detail
• Do not initialize Serial and do not use Serial within the source code, only in examples.
• If your board uses a servo do not create a separate header (.h) and implementation (.cpp) file. Since the IDE tries to build every implementation file in the library, this will cache the Servo library, which will then conflict with other AS devices. The solution is, in this case, just use a header file - it will not be included anywhere else but the examples.
• Commit to Git more often then once a week.
• Only commit when you've actually tested that things work or at least they build correctly.
• Use commit messages that are sensible and descriptive enough. Do not comment messages like "New" or "Latest" or "My changes" etc.

Useful Arduino API environment variables

• VARIANT_MCK Clock speed in Hz for ATSAMD, does not seem to work for AVR

Just for fun

• Each header file shall from now on include the pre-processor token TIME_WASTED_HERE that shall express the time in hours wasted in finding bugs. :) (Thanks @AnnaVargova)

Not very well documented!

@Gabor7697 has found out that the LED in the OptoShield is too bright, causing resolution and calibratin issues. At 5/255 analogWrite levels the sensor ouput is 900/1023; reducing resolution. Moreover according to him:

• The 10 k resistor for the LDR divider is not optimal, he calculated 2.3 kOhm (see below).
• A different colored LED can also help to reduce output.
• Larger LED resistor could reduce power.

All of the solutions above should be possibly tested.

@Gabor7697's calculations on a possible change in the LDR voltage divider.

The feedback process (because of the bad ranging) is not very nice, looks something like this:

Design the clamp. The clamp holds the beam.

• It must be cheap, simple.
• Prefer off-the shelf clamps and mechanisms.

It needs an evaluation of the current needs of the SMA wire.

• What is the resistance / m of the various SMA wires we have?
• What is the maximal current one needs for a 70 mm SMA wire and Joule heating at 12 V?
• At what thickness?
• What sort of voltages?

There could be a function solving differential equations with a single input and a single output.

This would be excellent for trying control without the actual hardware, representing the hardware as models and possibly serve as a basis for further functions, like tf() in Matlab.

The function could:

• take a float representing the input, say u,
• take two arrays of arbitrary size as the constant, say a and b
• output a float for the next input say y

y = difference(u, a, b);

Some challenges:

• how can past inputs (and outputs) be stored if we only know the order of the equation at call time? You cant just create an array on the fly in C, can you?
  Possible solution: here
• should initialization (for sizing) be separate from actual computation, like

Difference.begin(a,b);
y=Difference.compute(u);

Others

• array size in bytes is sizeof() then divide by type size in bytes
• the coefficients are not really dynamic, they do not change at runtime, only the internal variables should be sized once at the beginning.

This issue details the style guide and practices for writing the AutomationShield Wiki. The current best practices are seen in the HeatShield Wiki.

Wiki Pages

General guidelines

• English only.
• Do not host images or files outside the Wiki (or the repository).
• Please push images and files to the Wiki repository through Git and use the existing folder structure to keep order.

Necessary elements of a hardware wiki

Downloads

• Include a download for the production-ready PCB (Gerber format) files in a ZIP container.
• Include a download for the editable PCB-design file (DIP Trace).
• Include a download for the editable schematic-design file (DIP Trace).
• If there is a 3D assembly of the device, include it in a downloadable format.
• If there are 3D printed components, include these in a universally accessible format.

Images and illustrations

• Include at least one top view and isometric view of the hardware.
• The photos must be color and distortion corrected, with the background cut-out. (e.g. catalogue-like images).
• If you have a 3D illustration, include renders of the device.
• Include the schematic view from DIP Trace
• Include the PCB of the device: top and bottom
• Screenshots, Simulink schemes, and line drawings (e.g. CAD) must be saved and included in the PNG format.
• Include a screenshot of the process in the Arduino IDE. Use a relatively small (not full-screen) window, so that the line widths and annotations are still visible. Leave the window elements intact. Use the PNG format. Aim to achieve a 4:3 side for the window. This is a representative of a good screenshot:
  

Table of components

• The table must include a short description of the item (e.g. MOSFET), a long description (BUZ11, N-channel power MOSFET, 50V, TO-220 THT), designation on the PCB (Q1) a quantity needed (1), a unit price and a total price.

Tips and hints

• Tables will not be rendered, unless you insert a new empty line between the text and the first row of the table.

Videography

General guidelines

• English only (captions, text, voiceover)
• Video editing: DaVinci Resolve. Use the 16.0 version of DaVinci Resolve which can be found for Win, Mac and Linux for free here.
• Screen grab OBS Studio. You can download it here.
• Resolution Use HD resolution (1920×1080), nothing less nothing more. 4 k at the moment is just too much, however HD is expected.
• **Framerate use 24 FPS. We do not own professional cameras etc. and 24 FPS is to be expected from everything. So it is good enough.
• Maximal time for "intro" 5 s, otherwise viewers lose interest (backed up by hard evidence). Intro includes AutomationShield generic logo and some sort of title slide too
• No tacky and flashy effects, keep it simple.

OSB Studio

• You will need a fairly good computer, the process is surprisingly hard on the machine.
• If you can use dual-screens so you see OSB Studio while you work with the target window.
• When you set it up, optimize for recording not streaming. Choose 30 FPS not 60. This is still not good enough, you will need to change the framerate to 24, this way you maximize resources.
• Go to File>Settings>Video and set the Base (canvas) and Output (file) resolution to 960 x 640 pixels, as the grab will be used as overlay anyways, you do not need full resolution and the grabbing process is CPU intensive,
• Go to Sources, click + and find Window Capture. Un-check Capture Cursor so the cursor is not to be seen.
• Go to File>Settings>Hotkeys and set a key combination that you will you to start and stop recording. You can try something like Ctrl+Alt+R, just click into the field and push the key combo you picked.
• Adjust the bounding box on the canvas to e.g. top left than resize your window to match the canvas size as close as possible. You see this by the changing red (bounding box) rectangle in relation to the background (black).
• If you wish to export only one window, click on the bounding box, left click and select Resize output (source size) to get a 1:1 export of the pixels. This will change the outptut size to something other than your setting, but the result will not be resampled.
• Remember you may add more windows and elements to a canvas, even a Webcam.

DaVinci Resolve

• Beginner's tutorial here. Includes information on how to do picture-in-picture, keyframes and add text.

We will need to perform matrix computations to calcualte LQ gain and to implement other "modern" control methods. For this floating point matrix algebra needs to be implemented on the Arduino, which raises questions of memory efficiency (ROM, RAM) and computational efficiency (time). It is a question whether we should implement

• Own methods?
• Libraries? Which one?

To test solutions, a standard test program for matrix computations should be created, this should include matrix-matrix multiplication, matrix-vector multiplication, transposition and inverse. The standard test program should evaluate memory efficiency (RAM, ROM; e.g. by consulting compiler output relative to a known reference, like an empty program) and timing (e.g. by using micros()).

A good motivation to have our own routines would be to have control over the methods and to use application-specific requirements to make them more efficient, e.g. a module that implements "control theory" specific matrix algebra.

Opto.sensorRead should be in percents as well.

The reason is, that the Arduino SerialPlotter will not play nicely with values that are an order of magnitude different. Eg. If input runs to 100, you wont see anything on the screen from output.

This of course means, a calibration function is needed.

Create Wiki entries for the PID function

The Sampling Wiki needs improvement.

• Small language mistakes

Old and new shields should have a self-test function that tests hardware capability and gives diagnostics data.

Tibor updated the scheme for the opto Wiki. Please also

• update the file on the wiki
• update the picture of the schematics on wiki

Add (fill) the component table in the Opto wiki.

Comment and document the Sampling functionality to Wiki.

There should be an error handler function that can be turned off. Say there is a #define at the beginning and if it is true, the error handler is called, otherwise not. the message could be passed to the error function, which then starts an infinite loop... We could also say that LED13 on the 'duino will be an error led.

The readme.md should be brief and simple. Nobody reads it anyways. A longer description for the library should be inlcuded in the Wiki instead.

If we start to replicate the same ideas and thoughts in both, it will be a nightmare to maintain it.

The readme should tell how to isntall and where to find more info, that's about it. (Maybe verison number, authors etc.) but no detailed description of functions etc.

Please include all hardware design ideas and "bugs" that can be improved upon in the next revision. Provide ideas for upcoming work.

Create a step( ) function that will drive the inputs to the floating point input u, and list the input-output in a CSV format to the serial port.

• Unify the sampling code (push two versions)
• Test the sampling code
• Push to master

Include the Keywords for Arduino IDE for all your functions.

• A short (2.2") resistive flex sensor should be built in.
• An accelerometer should also be mounted to the end of the beam. Mounting with thin cables? Flexible PCB?
• What's the minimum sensing distance of TOF sensors? What's the sampling rate? Could it be also used?

Ideas to be implemented in the next iteration of the MagnetoShield

@TiborKonkoly please fill out the table with the components required to make an OptoShield

Implement and use an anti-windup function for the integral component. Have a stand alone-function for this. Use function overloading to differentiate between versions with and without anti-windup

Create various versions of the PID function with or without anti-windup etc. by function overloading

Find a good name for the heating thingy. HeatShield? HotShield? etc?

Tagline: "Burning your fingers has never been so easy. Introducing the HotShield" :)

The Optical.begin method should also initialize the auxiliary LED and LDR pins.

Select baseline pid implementation, this case "PID1". that shall be the basis from further on and renamed to "pid"

Current naming scheme is pid() for the absolute and pidInc() for the incremental version. There are now two competing versions for the absolute, these need to be unified. Anyone with a better idea for naming the pid() functions (mainly differentiating them) let us know here.

Here is the version of the digital PID controller that you could implement, see attachment.
If you needed help/ideas with the code, let me know.

Think of what will be the inputs/outputs of the function, whether it shall internally contain anti wind-up, saturation, pre-filtering, etc.

A future release of the Opto hardware could include another weaker LED, mounted at the middle of the tube and acting as a disturbance signal.

Find a cheap piezoceramic film transducer that can be used in (relatively) low cost shields.

• MIDÉ is way too expensive.
  We have the MIDÉ PPA 1021 transducers, made from PZT5A. We have two pieces, they cost over 200 EUR.
• What alternatives do we have?
  There are a lot of manufacturers for piezos, a good search is needed.
• Any Chinese manufacturers?
• How about the cheap PVDF ones marketed as sensors? (For Arduinos too) They are called MEAS, such as the ones made by MEAS-SPEC.com. Has anyone used it as an actuator? Can we try it?

• How to clamp the wire down?
• The clamp must be non-conductive, so it doesn't short the wire.
• Will the FR4 board deform? Will we need larger thickness?
• The clamp must be simple, cheap and use mostly store-bought parts.

This sticky issue and the post summarizes some hardware design practices for the AutomationShield devices. The current list is quite randomly organized, make sure you read it all. Please comment any other ideas that are generically valid.

Creed
The creed of an AutomationShield hardware device are, that it shall be

• open source
• low-cost (so universities with low budget and even students can afford it)
• standardized (use components that ere easy to obtain anywhere in the world, off the shelf)
• simple
• well documented,
• compatible with the Arduino R3 electrical layout; furthermore it
• shall fit on a single Arduino shield,
• use off the shelf components or 3D printing
• need no ambiguous or improvised parts
• be relatively easy to replicate and assemble by the average person

Generic notes

• If there no servo motor on your shield, do not use pins 9 and 10 for PWM. The internal sampling library blocks these. Also, do not use pins 3 and 11 as these are connected to Timer2, which may be used for other purposes, such as counting signals etc. The preferred pin to use is 5 or 6, be aware that this produces 980 Hz PWM signal.
• If there is a servo motor on your shield, do not use pins 9, 10, 11 and 3 for PWM. Instead of this, use pins 5,6. The servo library messes with 11 and 3, while the internal sampling library blocks 9 and 10.
• Do not put through-hole components over the USB connector of the Arduino. This can short the part. SMD are fine.
• If a reference potentiometer is needed, use the small ACP CA9MV-10K
• Use long, so called stackable headers only.
• The PCB mask is green.
• The 4x3.2mm holes on the board copying the mounting holes on the Arduino should stay if there is space for them, but can be removed if space is needed.
• The preferred place of the AutomationShield logo on the silkscreen is top left, over the USB connector. Alternate position is bottom left.
• Header specification: 15 mm long legs female headers, 2 x - 8-pin; 1 x - 6-pin; 1 x - 10-pin
• If external power is needed, do not add another connector to the shield, use the barrel connector on the Uno (Mega etc.) and transfer the voltage via the Vin pin. Warning: the Vin pin is not corrected for reverse voltage. That being said, the barrel jack diode is rated for 1 A, and has a forward voltage of 0.7 V (less then the input voltage).
• Think about what's underneath the shield. Metallic screws may touch live electronics and create shorts. Thick plastic screws can prevent the shield from being fully inserted.
• Wood is a nice material, but not on our shields. No wood please.
• Assume that the user will employ the Programming Port when using the device. No applications for the Native Port.
• For I2C components, use the separate SDA and SCL connectors, do not use the A4/A5 pair. This is only valid for the Uno.
• The mechanical part of the design shall be relatively easy to assemble or disassemble, so try not to make any permanent joints except for the electronics. This means, that you should avoid using glue at all cost.
• If you must use glue in your design, do not use superglue. The vapors of cyanoacrylate leave a nasty stain on plastic. Your 3D printed parts, the PCB or other components will be badly stained.
• Think of how you will and should assemble several identical devices. Sometimes motors or servos need to be in a certain position so that the assumptions and the model are valid. Remember, you are not creating a one-off device, they should be as identical as possible.
• There is a good selection of mechanical parts, like tubes, profiles, balls at www.premodely.sk

3.3V Compatibility

Make the shield 3.3 V compatible at all cost: New shields and updates to old shields (especially those with fast dynamics) should be made 3.3 V compatible. Here are some concepts to consider:

• The analog sensors should put no more than 3.3 V to the respective analog pins.
• Connecting 3.3V to the AREF pin doesn't change anything, device still takes internal reference though. This has been tested on the Zero / Due / Uno without issues.
• Consider how analog measurement affects shield compatibility. The 3.3 V shields do not tolerate >3.3 V on the pins!
• Consider how PWM output affects the shield compatibility. While an 5 V signal may open your MOSFET, the 3.3 V does not have to necessarily do the same...
• The 5 V powered servos should still accept 3.3 V signals to control the motor. This has been tested on a Zero. Simply said, there is no need to adjust for logic level differences in 3.3 V boards if a usual RC servo is used.

Find a good name for the ball blower thingy. Inspire by the existing naming scheme Opto and Moto

Create a universal step() function for all shields.

• The shield specific function could return outputs to a variable. Unit step?
• The non shield - specific could work as in MATLAB.

It's impossible to reverse engineer this : https://github.com/adafruit/Adafruit_VL53L0X/tree/master/src

The keywords file needs your specific keywords for Arduino IDE.

Please include all hardware design ideas and "bugs" that can be improved upon in the next revision. Provide ideas for upcoming work.

The name of the shield is Opto not Optical, this may be confusing to others.

How to get high voltage on the board? Look for ways to step-up the 12 V source. DC-DC converters? Would that be possible?

Todo:

• Photos?
• Library functions description?
• A worked example with the software?
• Possibly a video?

Done:
17.04.2018

• Upload and provide an image of the PCB (see Opto for inspiration)
  23.04.2018
• - Link the final final PCB FloatShield_PCB.zip Also your link points to the Opto file!
• Also share the files for the scheme and gerber (see Opto for inspiration)
  [FloatShield_Gerber.zip] Also your link points to the Opto file!(https://github.com/gergelytakacs/AutomationShield/files/1916200/FloatShield_Gerber.zip)
• Please include a list of credits (who did what) in the about section (see Opto for inspiration).
• Do not use JPEGs for line drawings, use PNG - exchange schematic layout and PCB to PNG
  -Also upload the catia (?) model for the 3D printed parts for others to download
• Upload a screenshot of the 3D models
  -Upload the scheme to be downloadable. (see Opto for inspiration)
• You may inspire and copy parts of the Opto wiki. This is not a bachelor's thesis, you can use the same text and formulation if it is appropriate.