A proposal for an alternative form of Arduino Dock

Boken Lin

@Kit-Bishop I've got a few questions for you:

What kind of computationally intensive tasks do you usually have the Arduino delegate to the Omega to do?
What are some of your frequently used shields for the Arduino?
In addition to the real-time stuff and interaction with Arduino shields, are there other code that you can think of that should only be run on the Arduino?

There are many users that come from the Arduino background. So it'll be awesome if we can figure out a way to make it easy for these users to drop the Omega into their existing projects. ADC dock is really just for users who use analog sensors.

Kit Bishop

@Boken-Lin It would probably help if I described what I am trying to achieve and also give some sort of list of Arduino Shields etc. that I am trying to use to achieve it.
As will become apparent, my main issue to date with the Arduino is that it really does not have the computing power and resources to do what I want - but there is a lot of Arduino related hardware that can help me achieve my goals. My main concern is that using the current Arduino Dock means having to go through a potential bottleneck in Omega<-->Arduino communication in order to access the Arduino hardware - I would like to be able to access such hardware directly from the Omega.

I would add that I have written a significant amount of the code in C++ to run on the Arduino (and this is seriously hitting the computational and resource capabilities of the Arduino - hence desire to move to Omega). I will have no problem in writing similar code for the Omega (so long as I could access the hardware direct) - either in C++ or (as I have been working on with some success - yet to be posted) in Java.

To come to what I am attempting to produce.
I am trying to create an Autonomous Robotic Vehicle that can orient itself in the environment and which can move in the environment avoiding obstacles.
Via various sensors, it will "discover", record and maintain a map of its environment. When placed in the environment it will attempt to locate and orient itself in that environment by comparing sensor input with previously recorded maps. It will also be capable of moving within the environment on command while avoiding previously detected obstacles and detecting as yet un-detected obstacles.

Some of the specific hardware features I am using (or intent to use) are listed as follows. (NOTE: I have most of them working individually on an Arduino but it doesn't really have the recources to cope with them all or to hanlde the map related processing):

Ultra sound an Infra Red range detectors
Drive motors with quadrature speed feedback
Servo motors to orient the range detectors
Limit switches needed to control postion of sensor servos
Infra red (or other - still to be decided) remote control for sending commands
Obstacle detection switches
Obstacle detection pressure pads
Inertial movment detectors
Magnetometers for orientation detection
Possibly - though not decided on yet - use of GPS positioning - though the scope of the system under design is small scale and GPS probably isn't appropriate
Self powered by on board power packs with power level monitoring (I am alread powering my Omega on an Arduino Dock using an Arduino Shield Lithium cell power pack)
On board status etc. display - currently using an Arduino LCD display but am contemplating using the Omega OLED

The Arduino related hardware I already have for much of this comes in several forms- largely (but not exclusively) as Arduino Shields.
The main forms of intrface to these cover:
A. I2C - on the Arduino, the Arduino is the I2C master and the device is the slave
B. Analog input - for which A to D conversion is needed - standardly available on the Arduino
C. Digital pin output
D. Digital pin input - but it is highly desirable and probably essential that digital pin input be able to trigger quick interrupt responses - this is essential for the drive motor quadrature speed detectors and highly desirable for the obstacle detection sitches and servo limit switches

Boken Lin

@Kit-Bishop Ok. Now I have a much better understanding of what you are trying to do. From what I can understand, what you are trying to avoid is 1) having to rewrite all the logic you've already written on the Arduino once again on the Omega, and 2) having the potential Omega <-> Arduino communication bottleneck. These problem will be encountered if you are trying to create a model where you put all the logic in the Omega, and using the Arduino Dock simply as a bridge between the Omega and all the sensors.

Here's an alternative model which I think might work. I think the main resource constraint on the Arduino is encountered with the storage and processing of the virtual map of the environment. What if, as opposed to using the Omega as the master and Arduino as the slave, you use the Arduino as the master, and merely pass the mapping data to the Omega for processing. In this case the Arduino will still contain the majority of the control logic (which you have already gotten to work), and you will simply use the Omega as a "server" that's accessible via some kind of I2C API. In this case, there won't be a huge amount of communication between Omega and Arduino, and you will be able to offload some of the computationally/storage intensive tasks to the Omega.

Let me know what you think.

Kit Bishop

@Boken-Lin Thank you for your thoughtful reply.
First, I don't really have any real problem with rewriting code for the Omega. Coding is my forte and I tend to do it in a fairly portable manner - isolating the hardware dependencies in separate modules and the rest can be pretty common - in the Arduino, all the code is in C++ and with care is fairly portable. Also, i pretty well have Java (which is by far my preferred language) running on the Omega and converting C++ code to Java is pretty easy (once any hardware dependencies are handled via JNI).

Your suggestion of using the Arduino for all the sensor handling and doing the hard processing in the Omega may well be the way I go. Before I became aware of the Omega I was working on schemes to use multiple Arduinos (actually Teensy 3 https://www.pjrc.com/teensy/index.html) that would communicate with each other to share the load.

While I would still much prefer a system whereby the Omega did everything (I'm sure it has the resources to do so) - I think it is a tidy system solution, I may well end up with something along the lines you suggest.

The most significant issue I think (at this stage) I will need to resolve is how the Omega<-->Arduino communications work.

The Arduino needs to be the I2C master to communicate with the I2C devices etc.
Thus, the Omega will need to be an I2C slave, yet will from time to time need to ask for information from the Arduino. I don't want to set up some sort of polling system on the Arduino that continually checks to see if the Omega has any request so will probably need some way by which the Omega can signal the Arduino that it has a request - haven't figured out the details for this yet

Boken Lin

@Kit-Bishop Hmmm, would it be possible to setup a system where both the Omega and Arduino can temporarily switch between I2C master and slave? We can potentially setup a system synced by a GPIO pin that determines at any given moment if the Omega should be master or if the Arduino should be the master. When the Omega needs to send information to the Arduino, it will switch the pin HIGH, and Arduino will switch over to the slave mode temporarily to receive the information and switch back as soon as the information is received.

This is a messy solution. Like you said, it would be ideal to have everything running on the Omega. With the way the Omega is connected to the Arduino Dock now, the Omega should be able to detect any Arduino shields that are connected to the Arduino Dock directly (because I2C is a bus). So now it's just a matter of finding a way for the Omega to control these shields directly. Perhaps it's just a matter of porting over the libraries so that they work on the Omega?

Kit Bishop

@Boken-Lin Yes - I am considering something like you suggest with a GPIO pin signalling switch over. It will be easy to get the Arduino to switch between Master mode and Slave mode and though I haven't delved into Omega I2C code yet, I wouldn't imagine there would be any major problem.

Regarding porting Arduino libraries to run on the Omega - I really don't think this would be a major problem. As it is, I have re-written several of the Arduino libraries I use because I wasn't 100% happy with the way they worked.

As far as I am concerned, the only things that I am currently concerned about if the Omega was to access Arduino Shields direct are:

Need to sort out responding to interrupts on GPIO pins - something I am working on as in separate posts
Lack of analog input on Omega - though could be covered if you guys produced and A to D dock - failing that, I could wire something up on a Prototype Dock
Possible concerns about logic levels on Arduino - there is quite a bit that uses 5v though many also use 3.3v or are changeable to use required logic levels.

Boken Lin

@Kit-Bishop Yeah, We should be able to solve points 2 and 3 with the ADC Dock. And we'll also help you to sort out the irq issue.

Kit Bishop

@Boken-Lin Again, Thanks

Chris Ward

@Kit-Bishop Robot to take over the world? I am working on a a couple of simple robots before I start the master plan. My thoughts are a distributed system, and I contemplated I2C as wll. I still think I want to try that direction, but the limitation of one master is frustrating. Trying to switch with a single pin is an idea. My other idea is to leave the I2C to the sensors and what not, but have the AVR's, communicate over something else. There must be something that allows two way communication.

I did some looking around, and there are some other solutions that simply map gpio ports to the host WRT based system without an AVR, so it must be working. In the mean time, I suppose you could wire up a prototypeing system to test it. I don't have many shields, just a couple of cheap motor controllers, so I don't have as much invested - yet.

Have you considered using a ATMEGA or a Arduino Zero? They are faster with more memory, right? I don't have either, but have considered it, because I keep running out of timers and independent PWM signals on the basic Arduino. That list is a lot of things to control. I wouldn't want to do all that in one program loop either.

Kit Bishop

@Chris-Ward Not quite take over the world
But my idea has had a very long gestation.I first came up with the general concept when in my teens in the mid 1960s. Observing a popular toy at the time - an electric vehicle that changed direction at random when it hit an obstacle. I tried to figure out how to make such a vehicle that could learn its environment and so avoid obstacles automatically - I came up with the broad principles that would be needed. But at the time:
a. I did not know much about computing - which was very much in its infancy any way
b. The technology was nowhere near what was needed

Since then:
i. I have gained an education in science
ii. Had a career in computing - hardware and software
iii. Technology has made the necessary hardware available

Hence I think my long held design could actually now be brought to fruition.

Coming to some of the specific comments you made. I did consider alternative Arduino derivatives. Most I considered to be too large - I wanted to tr to keep to a small physical form factor. Before coming across the Omega, I was looking to use multiple Teensy 3 devices.
The benefits of the Teensy 3 are:

Small - comparable in size to the Omega
More powerful than the standard Arduino UNO - though nowhere near as powerful as the Omega
Has interrupt capability on ALL digital IO pins
Has similar A to D capability on some oins as for standard Arduinos and additionally has a dedicated proper D to A (not just PWM) output pin
An Arduino Shield is available to house a Teensy and expose its pins in a standard Arduino Shield format - and hence give access to Arduino Shields directly (as per my proposal for an alternate Omega Arduino Dock that started this post)
Has two sets of I2C on separate pins - which greatly simplifies communication between separate devices
Additionally, standard Arduino libraries are available for it and it can be programmed using an add on to the Arduino IDE
Amongst the available libraries for the Arduino is a Soft I2C library that performs I2C communication on general IO pins using bit twiddling - though it would probably be relatively straight forward to port such a library to the Omega. Such a library could open up more complex communication between multiple devices.

However, my main concern about the Teensy 3 is that it still has relatively limited processing power -in terms of speed and memory as compared to the Omega.
My ideal solution would still be to be able to mount an Omega on an Arduino form factor dock as per my original proposal - this (I believe) would give me all I want without having to compromise (I have no qualms about porting code that I have developed along the way from Arduino to Omega)

Finally, regarding your comments about running out of timers- this has always been a concern that I have too. To help address this, I have built an I2C programmable hardware timer device for the Arduino and written support libraries for this that I believe handles what I need.
This could probably be adapted to the Omega, though I don't think this would be necessary. Given that the Omega runs a variant of Linux and supports usage of Posix Threads, timers are relatively easy to implement using the Posix Threads thus obviating the need for multiple hardware timers. I have done this for PWM output in the code I have produced for my new-gpio library which I posted some time ago on this forum.

Chris Ward

@Kit-Bishop I had no idea about the soft I2C - cool.
I need to get a Teensy 3 to play with it - looks cool.
Found a Teensy shield adapter on Sparkfun - interesting. I can see where you are coming from for sure now.
Do you have your I2C hardware timer/library somewhere? Would be interested to look at it.

Kit Bishop

@Chris-Ward For your reference, the Soft I2C Library for Arduino can be found here: https://github.com/todbot/SoftI2CMaster
The circuit diagram for the Timer Oscillator I have built is shown in this pdf file:I2C-Timer-Oscillator.pdf
The I2C-OSC referred to in the diagram is this: http://www.gravitech.us/i2c1kto68pro.html
Note also:

Jumpers J1/J2 set the divisor used for the output signal frequency
Jumper ENABLE is an enable jumper - would normally expect this to be permanently installed
Jumpers I2C_PU select whether or not pull ups are used on the I2C pins
Jumpers I2C_ADDR set the I2C address allowing up to two such timer oscillators to be used with different addresses

The following zip file contains my own Arduino library sources related to this (I think I have included all relevant files) : ArduinoOwnLibs.zip - let me know if you need info on how to use these.

Just for further information, I too use a Spakfun Shield adapter for the Teensy (https://www.sparkfun.com/products/13288 _ assume this is the one you refer too) though I have made some modifications to it to expose the second I2C interface that the Teensy has which isn't otherwise exposed on the Sparkfun shield.

My original proposal for an alternative Arduino Dock in this topic was intended to reflect something like this Sparkfun Teensy Adapter but for the Omega