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.
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.
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.
