[ANN] EMBD - Embedded Programming framework

[Karan Misra]

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

[Joseph Lisee]

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.

[Karan Misra]

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

[Govert Versluis]

Looks very cool, if all turns out well I'll be working on a project next month that needed exactly this.

Thanks a bunch!

[Erwin]

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.

[Karan Misra]

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.