FAQ
Hi All,

We have been working on EMBD the last few months. We felt the need for this
when creating a Golang based firmware for a remote controlled car.
It was really awesome to work with Go on this, as the low level ability of
the language really shone through when dealing with sensors, memory mapped
I/O, IOCTLs, etc.
And, when things started getting a little hairy, Go's concurrency abilities
saved the day.

What EMBD brings to the table:
Support for most common protocols/buses (GPIO, I2C, etc.) across supported
hosts (RPi, BBB, etc.)
Support for an increasing number of sensors/controllers (gyroscope,
accelerometer, PWM generator, etc.) which will work OOTB
An API which lends itself to serious use as well as to rapid prototyping
A well thought out hardware abstraction layer which will allow you to
leverage most of the functionality in EMBD even on hosts which are not
directly supported (yet) and on custom Linux based ARM boards

Give EMBD a spin and let us know!

uSite: https://embd.kidoman.io
Blog post: https://kidoman.io/framework/embd.html
Github: https://github.com/kidoman/embd

Regards,
Karan Misra

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Joseph Lisee at Apr 28, 2014 at 10:49 pm
    Have you had any trouble with the garbage collector? That is what I always
    think about when I consider using Go for robotics. Depending on your
    application having your whole program freeze for 200-500ms while the
    garbage collector runs, could wreck serious havoc.

    -Joe L.
    On Monday, April 28, 2014 8:53:09 AM UTC-4, Karan Misra wrote:

    Hi All,

    We have been working on EMBD the last few months. We felt the need for
    this when creating a Golang based firmware for a remote controlled car.
    It was really awesome to work with Go on this, as the low level ability of
    the language really shone through when dealing with sensors, memory mapped
    I/O, IOCTLs, etc.
    And, when things started getting a little hairy, Go's concurrency
    abilities saved the day.

    What EMBD brings to the table:
    Support for most common protocols/buses (GPIO, I2C, etc.) across supported
    hosts (RPi, BBB, etc.)
    Support for an increasing number of sensors/controllers (gyroscope,
    accelerometer, PWM generator, etc.) which will work OOTB
    An API which lends itself to serious use as well as to rapid prototyping
    A well thought out hardware abstraction layer which will allow you to
    leverage most of the functionality in EMBD even on hosts which are not
    directly supported (yet) and on custom Linux based ARM boards

    Give EMBD a spin and let us know!

    uSite: https://embd.kidoman.io
    Blog post: https://kidoman.io/framework/embd.html
    Github: https://github.com/kidoman/embd

    Regards,
    Karan Misra
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Karan Misra at Apr 29, 2014 at 5:05 am
    We definitely had some tight loops running in Go (on the Raspberry Pi.)

    For example, one of the things which TheBot did was to execute an automatic
    turn <https://www.youtube.com/watch?v=iMXjkZ4B3EM#t=61> (see video) given
    the API call */swing/90*

    It actively polled the gyroscope to get an idea of the car's orientation
    while turning, and simultaneously control the front wheel servo with the
    calculated instantaneous turn angle. If there were significant GC pauses
    during the run, then the turn would not execute perfectly.

    I think the old adage that "don't generate too much garbage" holds very
    true for Go. And with the improvements being done to Go's GC with every
    release, I reckon the situation will get better. However, I do agree that
    using EMBD/Go for robotics might have a surprises in store for you
    (particularly if trying to build something like a quadcopter.) But, if you
    building the next NEST, it will perfectly fit for the job.

    -k
    On Tuesday, April 29, 2014 4:19:42 AM UTC+5:30, Joseph Lisee wrote:

    Have you had any trouble with the garbage collector? That is what I
    always think about when I consider using Go for robotics. Depending on
    your application having your whole program freeze for 200-500ms while the
    garbage collector runs, could wreck serious havoc.

    -Joe L.
    On Monday, April 28, 2014 8:53:09 AM UTC-4, Karan Misra wrote:

    Hi All,

    We have been working on EMBD the last few months. We felt the need for
    this when creating a Golang based firmware for a remote controlled car.
    It was really awesome to work with Go on this, as the low level ability
    of the language really shone through when dealing with sensors, memory
    mapped I/O, IOCTLs, etc.
    And, when things started getting a little hairy, Go's concurrency
    abilities saved the day.

    What EMBD brings to the table:
    Support for most common protocols/buses (GPIO, I2C, etc.) across
    supported hosts (RPi, BBB, etc.)
    Support for an increasing number of sensors/controllers (gyroscope,
    accelerometer, PWM generator, etc.) which will work OOTB
    An API which lends itself to serious use as well as to rapid prototyping
    A well thought out hardware abstraction layer which will allow you to
    leverage most of the functionality in EMBD even on hosts which are not
    directly supported (yet) and on custom Linux based ARM boards

    Give EMBD a spin and let us know!

    uSite: https://embd.kidoman.io
    Blog post: https://kidoman.io/framework/embd.html
    Github: https://github.com/kidoman/embd

    Regards,
    Karan Misra
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Govert Versluis at Apr 29, 2014 at 9:03 am
    Looks very cool, if all turns out well I'll be working on a project next
    month that needed exactly this.

    Thanks a bunch!

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Erwin at Apr 29, 2014 at 9:48 am
    I'm developing a robot as well using go for the control software. So far
    all is going very well, I have yet to see GC pauses that are noticeable.
    Timing behavior is also very good, even when quite some goroutines are
    active. It is probably wise to try and reuse memory as much as possible,
    avoiding too many allocations.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Karan Misra at Apr 29, 2014 at 12:48 pm
    That is exactly what I noticed. I was running all this on a single core 700
    Mhz RPi and had around 10-15 goroutines active at any given time, and no
    issues at all. The trick is not generating a lot of garbage once the
    program warms up.
    On Tuesday, April 29, 2014 3:18:08 PM UTC+5:30, notnot wrote:

    I'm developing a robot as well using go for the control software. So far
    all is going very well, I have yet to see GC pauses that are noticeable.
    Timing behavior is also very good, even when quite some goroutines are
    active. It is probably wise to try and reuse memory as much as possible,
    avoiding too many allocations.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 28, '14 at 12:53p
activeApr 29, '14 at 12:48p
posts6
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase