A proposal for an alternative form of Arduino Dock



  • This post makes a proposal for an alternative form of Arduino Dock

    The current Arduino Dock is effectively an Arduino with which the Omega communicates via I2C but the Arduino still needs programming to communicate with the Omega (which itself needs programing to communicate with the Arduino).
    The Arduino on the dock also needs programming to access any Arduino Shields etc. as required.

    My main rationale for using an Omega was to have access to a system more powerful than the Arduino but to still be able to have access to the large range of Arduino Shields and hardware.

    What I would like in an Alternative Arduino Dock is something that in basic terms:

    1. Had the physical form factor of the Arduino
    2. Effectively connected the Omega GPIO pins to the Arduino pins
    3. That allowed control of the Arduino pins directly from the Omega without having to write separate Arduino code or Omega/Arduino communications code

    While I am not an expert in circuit design I have some abilities in this area and intend to commence on some basic design that accomdates the more detailed characteristics that I describe below.
    However, I am most certainly NOT an expert in any sense in PC board layout design.
    If any one has any interest in these ideas I would be keen to hear. If not, I will probably proceed the best I can wiring up something on an Arduino prototype board.

    In more details, the characteristics of my suggested Alternative Arduino Dock are:

    1. Physical form factor of the standard Arduino UNO board layout
    2. Socket to take the Omega
    3. Mini and standard USB connectors connected to Omega USB pins
    4. Power supplied as follows:
      • External power supply socket (as on current Arduino Dock) that feeds to a 5v regulator
      • 5v pin on Arduino header (and the above 5v. regulator output) feeds to a 3.3v regulator to power the Omega
    5. All Omega GPIO pins (but see notes below about Arduino analog pins and I2C pins) connected to Arduino IO pins via level shifters such as http://www.ti.com/lit/ds/symlink/txb0108.pdf or similar. The actual levels on the Arduino output side will be settable to 3.3v or 5v via links/solder jumpers.
    6. Analog input will be handled via an A/D converter something like http://www.analog.com/media/en/technical-documentation/data-sheets/AD7997_7998.pdf controlled via the Omega I2C output. The Arduiono Analog pins (A0 - A5) will be selectable via links/solder jumpers as either just standard IO pins connected to Omega GPIO or to this A/D converter. There will also be an additional header to connect signals directly to the A/D converter
    7. I2C signals from the Omega will be connected to either (or both of) the Arduino A4 and A4 pins or the SDA and SCL pins via links/solder jumpers
    8. ICSP/SPI header - there will be an ICSP header connetcable via links/solder jumpers to specific GPIO pins (details still to be decided).
    9. Anything else I can think of as work progresses 9or as others contribute ideas) - I will update this post as relevant.

    EDIT 1
    Some additional things to think about:
    A. Connection of Omega Serial TX/RX to standard Arduino Pins 0 and 1 - normally used by Arduino for Serial
    B. Exposure of Omega USB D+/D- pins on a separate header
    C. Exposure of Omega Ethernet TX+/TX- and RX+/RX- pins on a separate ethernet header (with any necessary supporting circuitry)



  • Have added some additional comments marked as EDIT 1 in original post



  • Hey Kit,

    I've been disappointed with the board also. I was hoping the functionality would be like a YUN. I use a YUN shield with an UNO. What is needed is some good libraries like the YUN (or clone). After I flashed the Arduino board, I just haven't had time to work with it.

    Russ



  • @Kit-Bishop @Russ-Terrell I don't have an Arduino dock but saw your post....

    The Yun (and some other dual boards) communicate similar to what you would have to do with the omega. On the Yun, the linux part is not meant to be powerful and just really a gateway to the internet, but more can be run there. The communication is over a library called Bridge. This is also similar to if you purchased an Arduino wifi shield based on a ESP8266 or had one not in a shield. There are GPIO pins that are there, but not connected directly.

    I am not sure how the GPIO pins would get connected directly. Are you wanting an input pin on the Arduino to register as an input pin on the Omega? In that case I suppose a board that didn't have an Arduino but just accepted the shields would accomplish that, but you would have all kinds of software issues then. The Arduino and the Omega are quite different in terms of timers, interrupts, multi-talking, etc.

    It is an interesting issue that likely needs a hardware/software bridge - the dock being the hardware. I would be nice to have something where any Arduino shield could be plugged in and just work. Just not sure how that would work. You need to use specific libraries on a shield to work with it. I can see someone writing a I2C wrapper around a library for the Arduino so that the communication to the Omega is easier, but that would be on a per shield/library basis.

    Who knows, maybe I don't understand well enough and the Onion folks have some cool ideas that would simplify the programming with Arduino shields.

    PS. Several times I referred to Arduino, the Board, and Arduino when I should have just said Atmel Atmega AVR.



  • @Kit-Bishop This is something we've been thinking for sometime as well. We think the requirement to write two sets of code (one on the Omega and one on the Arduino Dock) is a terrible experience. Our tentative solution right now is to create a default firmware on the Omega that has a few functions pre-programmed in, and the Omega can communicate with it via I2C to trigger these functions. These functions would include reading from analog sensors, sending PWM signals, etc. However, it is hard to predict what kind of features users would want the Arduino Dock to perform, so it's difficult to come up with a firmware that encompasses "all" the features, including support for all the shields, etc.

    Can you give me an ideal workflow that you envision working with the Omega + Arduino? Perhaps we can come up with a solution to make it happen.



  • @Boken-Lin @Chris-Ward @Russ-Terrell
    Perhaps I should have been clearer :-(
    I am NOT proposing an alternative Arduino Dock with an Arduino processor on it.
    Rather what I propose can be considered more like an equivalent to the existing Omega Expansion Dock but in an Arduino physical form factor,
    Thus:

    • No need to worry about any Omega/Arduino communications - there is nothing to communicate with
    • Permits the use of the multitude of existing Arduino shields to connect directly to and be controlled directly by the Omega

    The only significant issues to deal with are:

    • IO pin signal levels - Arduino shields typically use 5v though some use 3.3v and some are adaptable.
      Hence the need for level changers between the Omega pins and the Arduino shield pins
    • Lack of analog input on the Omega
      Hence the proposal for an A/D converter accessible by the Omega via I2C

    There are a few other issues that should/could be addressed as in my proposal



  • Yea, that makes more sense. The big issue I see though is that the libraries are not going to work that have been written for the shield. Onion won't have time to write those. I am sure that some people could handle that code just fine (ie. you) . I have found that most of the things that exist as shields exist as a separate board. You might even find 3.3v boards that way. You would have to wire all the connections yourself, so I get the idea, just not sure how worth it would be to Onion.



  • @Kit-Bishop Arduino shields are usually more expansive Omega expansions, so the advantage of having an Arduino shaped dock is really to take advantage of existing libraries already made for the Arduino shields. But if there isn't an AVR on-board, then all the libraries for the Arduino shields will need to be re-written. In that case I think it will make more sense to create a dock with an ADC that's in the same form factor as the current expansion dock. This will allow you to use the existing Omega expansions as well as taking analog input from sensors, etc.

    What do you think?



  • @Boken-Lin You make some valid points and I see where you are coming from.

    From my perspective, I already have significant investment in Arduino Shields and in the hardware they are mounted in.
    My main problem is that the Arduino is lacking in resources and computing power compared to the Omega.
    My hope has been that I could effectively drop an Omega mounted on an Arduino Dock (or something similar as per my proposal) into my current hardware set up.
    To me the time/cost of programming the Omega to access the Arduino hardware is relatively small. However, having to code both the Omega and the Arduino Dock and the communication between the two to achieve what I want does add something to this and would also reduce the overall system performance.

    I am however, attracted by your suggestion of an Omega ADC dock and would be interested in it and would consider it if it were available.



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

    1. What kind of computationally intensive tasks do you usually have the Arduino delegate to the Omega to do?
    2. What are some of your frequently used shields for the Arduino?
    3. 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.



  • @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):

    1. Ultra sound an Infra Red range detectors
    2. Drive motors with quadrature speed feedback
    3. Servo motors to orient the range detectors
    4. Limit switches needed to control postion of sensor servos
    5. Infra red (or other - still to be decided) remote control for sending commands
    6. Obstacle detection switches
    7. Obstacle detection pressure pads
    8. Inertial movment detectors
    9. Magnetometers for orientation detection
    10. 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
    11. 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)
    12. 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



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



  • @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



  • @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?



  • @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:

    1. Need to sort out responding to interrupts on GPIO pins - something I am working on as in separate posts
    2. 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
    3. 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.


  • @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. :)



  • @Boken-Lin Again, Thanks :-)



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



  • @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:

    1. Small - comparable in size to the Omega
    2. More powerful than the standard Arduino UNO - though nowhere near as powerful as the Omega
    3. Has interrupt capability on ALL digital IO pins
    4. 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
    5. 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)
    6. Has two sets of I2C on separate pins - which greatly simplifies communication between separate devices
    7. Additionally, standard Arduino libraries are available for it and it can be programmed using an add on to the Arduino IDE
    8. 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.



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


Log in to reply
 

Looks like your connection to Onion Community was lost, please wait while we try to reconnect.