Sunday, September 13, 2015

Working on MD code a bit

Well,  I worked on my detector coding a bit this weekend.  Finally.

Using the Teensy is pretty fun, I will have to admit.

In less than a page of code, I had the PWM set up for the TX pulse at the frequency and duty cycle I wanted, and I then had the interrupt service routine set up to sample with the A to D, after the end of the TX pulse.

I really like the libraries available for the Teensy.  Even though it's still Arduino sketch coding, it can do what a  normal Arduino just can't.

I have the main sample pulse at 15uS past the end of the 50uS TX pulse.  I then delay 20uS past the end of the main sample pulse, and sample again for the Ground balance sample and average the two before exiting the ISR.

All in one page of code.

No setting up ISR registers, no setting up A/D, no setting up PWM, other than a few simple defines.

Screenshot of TX pulse, Main Sample, and Ground balance sample.

Monday, September 7, 2015

Fully Assembled board

Here's the fully assembled board.  I have the Pi sandwiched between the Base board and the Grove Pi.  I like this setup, since it gives me more I/O and adds two more serial channels for me to use, even one straight from the Pi.  I also might like to try my Logi-Pi Spartan 6 board this way with the PMOD ports, if I can figure out the FPGA side.

The Grove is just another I2C address to the Codesys.  It has a simple little command protocol mechanism that I can talk to any of the Grove Modules via the on-board ATMega 328 mcu.

I intend to use the Grove I/O mainly for the Operator Interface that won't exit the enclosure, and use the industrial 24V out on the external I/O.  It could be a really good fit in my opinion.

I am seeing weird performance from the Grove Temp/Humidity sensors though.  Seems like a bug in their firmware, since I get the same readings in Codesys as I do the Python test code.

Base Board with Grove Pi+
Base Board with Logi Pi

Sunday, September 6, 2015

Board is done and it works!

Ok.  It's done, and it works, but I had to do some jumpering to make it work.  I originally designed the board with 2 I2C buses, but with the Teensy I had to step back a bit, and not use the 2nd I2C bus.  Turns out the I2C bus library that supports 2 I2C buses, is not compatible with the Adafruit libraries for the IMU.

This just means one I2C bus with all of the I2C traffic control from Codesys and my custom driver profile (actually 2).

I had to mount a riser to the IMU so that it cleared the Pi ribbon, and the DAC adapter did indeed turn out to be horrendous.  But it works, which for a prototype board is good.  I didn't even have to cut traces, which to me is a win.

There are are a lot of milestones I met with this board.

  1. Board layout software (Eagle 6.6.0) worked well, and generated good Gerber files.
  2. OSHPark did a phenomenal  job on making the board.  I can't say enough good things about them.
  3. The design worked.  Yes, I forgot some missing jumpers, but the design is now proven to work.
  4. Through hole is still king for me right now for ease.  That single SSOP16 to DIP adapter for the DAC  has proven the most work.  I know I should have checked, but I would ASS U ME, that the nice, wonderful, super cheap adapter you bought, isn't screwed up right? **cough Sparkfun**.   I will avoid SMT until I get my reflow oven built, and get setup for it.
  5. My several parts I made were perfect, and I am very happy with the overall look and layout of the board.
  6. I last designed a board using Ultiboard in 2002.  Ultiboard and Ultirouter cost $10000, and getting a board made cost between $1000 tooling and setup and $50-$100 each per board.  Now I use Eagle at $200, and it cost me $95 for 3 boards.
Brand new PCBs from OSHPark

Assembled Board running.

FAIL SSOP to DIP adapter fix


Thursday, September 3, 2015

Finished Board design for Pi and Teensy Controller

Ok.  I've finished my board design I've been working on.  This board will provide the following features:
  1. Interface from Teensy 3.1 to Pi (I2C) from Codesys
  2. Adafruit 10 DOF IMU
  3. RS485 Serial Connection
  4. Pluggable Terminals
  5. 24V isolated digital inputs
  6. 24V isolated digital outputs
  7. 4 ch analog inputs, buffered
  8. 4 ch analog outputs, buffered
  9. Real time Clock
So far, all the circuits should work, so I'm going to send the board off to be made.

Back with more later..

Awaiting boards to come in..

Well, I created a PCB around the Teensy, and am currently waiting on parts.  I have received most of the parts, but still am awaiting delivery of the PCB and op amp buffers.

I screwed up my DAC footprint.  Turns out Sparkfun's SSOP to DIP footprint doesn't follow a DIP IC pattern, so I will have to make a little adapter harness for the chip to plug into.

Everything has tested out so far from the design, I will make some minor changes to the next PCB rev, but for the most part, the PCB should work ok.

Yes, it's through hole, but I wanted through-hole for simplicity's sake, and the ability to cut / solder traces if need be.  It's still not too big.  I will keep the same size on the next rev, and just shrink components and add more features.  Perhaps add some more channels or something.

Here are some pictures of the PCB..



Monday, August 17, 2015

Back again again!

Ok.  It's been a while since I've posted.  I've been very busy, both at my day job, and my home projects.

The metal detector robot project is in a holding pattern, as I've been developing and testing my "infrastructure" environment.

As you know by now, I've standardized around Codesys on the Raspberry Pi.  The version for Codesys is now at v3.5sp7.  I had quite a bit of trouble updating my project past sp6, but I'm over that now.  I think.  The good thing on that is that it will make new users and easier path to start.  The biggest improvement was the addition of Ethernet/IP adapter drivers to Codesys.  With this, and the previous Ethernet/IP Scanner driver, you can now not only interface to Allen Bradley Flex IO, but the Codesys Pi can act as Generic Ethernet/IP adapter IO.  Or you could use 1 Pi with a Scanner, and 1 Pi with and adapter.  No AB required at all.  I will be testing this soon.

Here's what I'm testing right now.

I have changed over to the Teensy 3.1 platform.  I really like this little guy, it's a fantastic chip/module really.  I use TeensyDuino with it (which is an add-on to the Arduino IDE), so all the libraries that work with Arduino and sketches out there work with the Teensy.

Here's a couple pictures:
Teensy Top Pinout

Teensy Bottom Pinout

I have interfaced the Teensy to the I2C port on the Raspberry Pi.  Using a modified I2C device profile in Codesys, I can transfer data back and forth with the Teensy from the Codesys PLC environment.  My previous testing with Codesys on the Pi showed the potential of embedding the Pi Camera into a web visualization screen, and that works pretty well also.  It's not perfect, but its really pretty good.

My latest testing has involved testing the I/O capabilities of the Teensy, and the Arduino environment, which I was new to.  I have to say I am pretty impressed.  Having used Propellers in the past, I was leery about single threaded processors, but the interrupts and "software based task control", has proven very easy to use and mostly painless.  I did run into trouble getting the two I2C ports on the Teensy to work.  The libraries for the I2C modules out there are designed around Arduino single I2C modules and don't play nicely together.

This is getting me closer to my goal of a high level Linux  environment coupled with high speed low level control.  I will come back to the Prop world if the Prop2 is ever finished, but I will probably be dead of old age by then anyway.  Who knows.  Or the Xmos if they ever figure out how to make an I2C slave work.  They seem perfectly happy having USB Audio to play with.

Anyhow, here are a couple quick videos of the Teensy running interfaced to the Pi.

The first video shows the very early testing of the I2C interface between the Pi and the Teensy.  Simple 10 bytes in and 10 bytes out.  The PLC task is set at 20ms.  The Teensy seems to be able to flash the LED at that rate with no problems.



Here is the further testing setup on my PPDB breadboard.  There is a Parallax 2x16 serial LCD module, a DHT11 temp/humdity sensor, the ADC ch 0 wired to a pot on the development board, and a 2nd LED.  The LCD serial strings are generated by the Teensy, with the data from the sensors on board.



In this video, the relay board is added.  These relays are driven from the top level Codesys program, in a "Kit-Like" side pattern.



Tuesday, February 24, 2015

Updated test code with Two Raspberry Pis and embedded video on the Codesys visualization

Hi folks!

I've just tested my test project with two Raspberry Pis and Codesys with a Prop I2C board on each, and the embedded video from the Pi cameras on each visualization.

Here is a quick video showing not only the embedded video, but also a quick rundown of a project with 2 Pis, both online, and network variable producer / consumer lists passed from one Pi to the other.

Each Pi has the Propeller off the I2C bus.  The 1st Pi's Propeller is a USB Proto board, with the MX2125, SHT11, and the H55B chips.  The 2nd Pi's Propeller is the RoboPi board from Mikronaut with a few modifications to allow programming of the RoboPi from the PC versus the Pi.

Enjoy!



Monday, February 23, 2015

Embedded video in place

Good news!

Looks like the feature I've been looking for since August is finally here and working!

You can now stream video from the Pi Camera into a visualization window.  The demo with the latest version includes both a streaming window and a static window for manual captures.

I'm really stoked about this.  Up till now, I would have had to run the streaming video in a separate browser window - now it can be with the main control, so I can embed the video inside the controls.

This is an awesome feature.   The latency I saw looks very reasonable as well.

The demo Pi I used was a B+, so I imagine the Pi 2 will look even better.

Here's a quick video clip of my test...


I will post another update real soon on my latest rev stuff.  I've made good progress since the last big post.



Back to work

Well,  its been a long time now that I haven't been able to work on the machine!  I have moved around with various work (gotta go where the jobs are), and I have finally gotten to a point where I can work on the rover again.

Since returning to work on it, I have reconfigured it to be a bit easier to move around, and not be so bulky.  The previous design was approx 6 ft long, and I have since shortened it to 3 ft.  I also went from a 4 wheel, to a 2 wheel design.  Here are some pics:





This should have several benefits.  I was able to cut the weight by half, reduce the motors and drives by half.  Reduced power requirements allowed me to reduce the generator size by 50%.

Even though the mechanics have not made a lot of progress, I have made up for it in terms of the control system, especially in conceptualizing what I want the final design to look like.  A new capability had been recently introduced, and breathed new life into the project.  Originally, I had planned on DSP robotics Flowstone, but it had some issues with it for the main control system software.  As the fallback plan, I had simply decided to use Python on the Pi with Qt or Tkinter.  I had resigned myself to crafting every aspect of the control system - what I call "re-inventing the wheel".  In terms of control software in the Linux world, there are literally a million implementations of everything, but even the basic stuff can be a real pain in the ass.  Don't get me wrong, I love Linux, but I also like working, reliable software "infrastructure" to build my application on - not have to do every little thing.  This being said, I was very happy when Codesys announced plans to introduce there software to the Raspberry Pi world, since I had a lot of background with it already.  I knew that this would help me bring order to my Linux chaos, and could allow me to concentrate on the rover and not too much on Linux stuff.

Here are some links to my using Codesys with the Prop testing..








Codesys running test code in project
The control system will be mostly comprised of "control nodes" in a distributed architecture.  The Codesys SoftPLC's running on the Raspberry Pis will use Parallax Propellers for I/O controllers.  The Codesys solution has many benefits for me.  One obvious thing is my previous background working with it for industrial projects, and the other being the stability and modularity it brings to the Linux and Raspberry Pi world.  Features that are rare in the world of hobbyist controls and electronics are common place with Codesys, and the combination for me is quite incredible.  I wanted something like this even 5 or 6 years ago, but it wasn't to be at the time.

Sample Codesys visualization screen


As to the I/O controllers, the Propellers will be interfaced to the Pi via an I2C, and serial port interfacing scheme.  I have modified one of the default I2C device drivers provided by Codesys for my needs with this system, and it works great.  This to me is a better solution for now than to use an Arduino as an I/O controller with the Pi, which is a common feature these days.  The Propeller's 8 core, 80Mhz, 32 bit capabilities, are still better than most of the low end Arduino boards.  I intend to use Propeller's heavily in this design for now.  Later, I will be testing a Teensy 3.1 as an alternative with TeensyDuino.  There may be some advantages with this setup, versus the Prop - especially the more modern Arm Cortex M4.

For the I/O interface between the Pi and the Propellers, I have configured the Codesys I2C driver to be programmable as to the register input and output sizes, as well as the starting registers for the I/O.  This should also allow the use of the driver for even generic I2C devices, such sensors and such. I like I2C.  It's a dirt simple interface, and fairly fast, especially considering the softPLC runs at a 20ms task rate (I've even seen 1ms).  If I keep the number of I2C devices down, and spread out to other nodes via Ethernet, I think this is a great solution.  I know SPI can be faster, but its way more trouble for me, and I love the idea of being able to drop in multiple I2C devices on the same bus without too much fuss.  Perhaps I will use SPI and serial for large chunks of streaming data only, such as GPS messages and such later.  I do have a working SPI driver in Codesys, as well as access to serial ports into the Pi, in addition to all that extra GPIO available on the 40 pin Pi header.

Raspberry Pi B+ with Propeller USB Protoype I2C sensor test node


The ultimate plan is to utilize smart "control nodes" in a network, with each node controlling a portion of the rover's system.  I have designed many systems this way, and it has always proven the best in terms of capabilities.  Its a bit more complex to set up, but if your aware of the pitfalls, you can avoid them later on in the design once it grows.  The Codesys makes this dirt simple.

Now lets talk Codesys.  Not only can I use Modbus master/slaves (along with a bunch of other industrial protocols), I can also use producer/consumer network variable lists between nodes - this is a crazy powerful feature which allows tag (variable) information to be produced by a node, and consumed by another node.  These can either be broadcast to everyone, or to discrete nodes.  On top of all that, it can be entire tag lists, not just one tag, but a whole list of them, even structures.

Codesys allows the ENTIRE system to be in one project file.  Each node has its own Pi and control code,  each Pi can be programmed, debugged, and maintained, remotely over the network, either individually or multiple Pis at the same time.  Think about what I just said there.  I can do a multiple download, and it will download to every node in the system in order, and place each system online once completed.

Once you start truly using the full feature set of Codesys, it will blow your mind.  I've been programming PLCs for a very long time, and I have never seen anything like it.  I've used almost everything out there and Codesys is up there with my favorite PLC software.  Only one thing about Codesys is that it is so different than what we are accustomed to here in the US.  Most ladder logic PLC folks (which is almost everyone over here), don't know what to make of Codesys, its just so different than what they are used to.  Case in mind is the OSCAT libraries available with Codesys.  These are open-source libraries for structured text PLC code.  Super easy to use with Codesys by the way.  I've used OSCAT libraries since 2005 or so, and I have always been impressed with how polished and well documented they are.  I've never seen open source libraries available for any US PLC manufacturer.  Your pretty much limited to perhaps getting some sample code from PLC forums, or hoping your company has a big enough stable of old projects with code you can re-use.  The problem with this is there is no guarantee it's even any good.  It may only be as good as the last guy to work on it, if he didn't screw something up doing it.  The OSCAT libraries get the same benefits that the rest of the open source world gets - vetted, tested code that you can pretty easily use as is, or with very little modifications.

If you want to learn PLC's do yourself a favor and get a Pi with Codesys.  You can learn an incredible amount of useful stuff, and Codesys has made their software practically free with the Pi for learning their system.  All the extras with it are just icing on the cake.  It's a very viable platform for hobby robotic testing.

I'll get off my soapbox for now.  As you can see, I'm a big fan of Codesys.

For this system, even though the system Pis will be Codesys and Prop-centric, I also intend to add as a system-level tool of the ROS ecosystem.  I have an HTPC that will run Ubuntu 14.04 with ROS.  The intention is to leverage the publisher/subscriber mechanism of ROS in conjunction with the Codesys ecosystem on the Pis.  This will allow the use of Kinect sensors, navigation tools, and some other tools that ROS offers.  I have yet to get started on this front yet, I am still setting up the HTPC with it, but eventually this will bring some interesting capabilities to the system.  It gives me an additional opportunity to learn ROS, which I've always wanted to do, especially in using it in conjunction with industrial hardware.

Currently the first node will control the following sensors and devices:  (these are old sensors - I will be upgrading them to better tech later).  This node will be a "blister" that is mounted to the top lid of the control enclosure.

1) 2, Pololu 24V23 motor amplifiers for the two wheelchair motors)
2) 4, PING sensors (each side)
3) 16 SPDT relays
4) 8ch MCP3204 A/D
5) 8-10 digital IO or RC servos with what I can stuff onto the RoboPi board from Mikronauts.
6) Pi Camera streaming

The second node will run this stuff (Prop USB Proto):

1) a MX2125 dual axis inclinometer
2) a SHT11 temp / humidity sensor
3) a HM55B digital compass
4) a PMB-648 GPS sensor
5) Even more Digital IO if I need to.

Third node will be the operator interface.  I plan on using a pendant design, that uses real switches and buttons versus touchscreen only.  I want to be able use both hardware inputs and screen inputs, but the primary system will need to be hardware.

For the networking, the rover will house a Wifi router set up as a DHCP server.  The operator pendant node, as well as all of the other nodes will connect to this local network.  Local to the rover, I will try to keep everything hardwired Ethernet to minimize the Wifi traffic to the pendant only.

I will probably have at least three or maybe more nodes on the rover, for other sensors, and for the rear streaming camera views.  To keep the network traffic to a minimum, I intend on using my HTPC machine in the rover as a remote display "driver".  Any visualizations I will need, along with the streaming camera view will go to the "virtual" display.  I will VNC to this computer remotely, so that only the one network stream of the screen is being sent, with all of the views configured on the remote display.  I will try to run it from the webserver visualization, we will see how that goes though.

Another node will house the metal detector controls.  I plan on using at least 8 Propeller's for this node, in order to handle the phased array of coils.  For this node, the Propellers will be either Prop Mini's or Spin Props, of which I have several.  I may possibly even use the Tetra Prop boards if I can get a couple of those.  I am still considering XMOS for this application, since it is a much more capable chip in a lot of regards, but the Prop has proved easier for me, since the I2C slave softTip drivers of the XMOS are even now, still not fully fleshed out.

 Perhaps if I could get a working solution going for that I might use it but for now the Prop is my way to go.

For the coil design of the MD, I will utilize the coil array mounted on the front with a lever arm tilt axis, versus the rotating arm on the previous design.  I think I have a pretty good preliminary design for this, which will put my PVC skills to use.

I have narrowed down the coil design to a single large transmit coil, and 6 receiver coils, to be scanned in a phase array.   The coils will be laid out in a staggered fashion to get better localized sensing.  Each coil will overlap two others, so that hopefully, the scan area is well scanned and not overlooked.  By knowing exactly where a target lies, that information can be transmitted back to the control system as well for both data logging and target marking.  This is one reason why the coil will be front mounted versus rear pulled.  By being on the front, the lift system is needed, and I have worked out a really good lever design using my existing actuators from the old design.

There will be another node possibly for the marking system, but I may be able to use I/O from other nodes, if available.

The metal detector will still use Pulse Induction technology, with the parallel array of Propellers looking at the coil.  Hopefully, I can get some really good results.

Well,  I guess this is it for now.  It's a long post, and I'll be surprised if anyone trudges through the whole thing, but at least you can get a feel for where I'm going with this.