search

rwaldron / johnny-five

JavaScript Robotics and IoT programming framework, developed at Bocoup.
http://johnny-five.io
Other
13.3k stars 1.77k forks source link

Support for GrovePi #971

Closed moodybass closed 8 years ago

moodybass commented 8 years ago

I think I may have answered my own question, but wanted to confirm. Is there support for GrovePi with Johnny-Five? I note there is support for Edison etc, but can't find anything specifc for the GrovePi unit attached to an RPi?

I've attemped but Johhny-Five does not detect the board as per:

johnny-five/lib/board.js:83
      ports = result.filter(function(val) {
                    ^
TypeError: Cannot read property 'filter' of undefined

Which I understand means my board is not being detected?

rwaldron commented 8 years ago

I'm not sure, it looks like it's just a shield, which means it's supported implicitly. Where are you running this code from? If you're running on an RPi, you'll need to use Raspi-io. Let's also ping @nebrius

nebrius commented 8 years ago

I haven't used the GrovePi myself, but I think @rwaldron is right, it's an expansion board. To use with raspi-io, you may have to do a bit of reverse engineering to figure out what type of communication protocol each sensor uses, and what pins they are connected to. Most of them seem to be I2C sensors, which should be straightfoward to use, but some of them seem to be GPIO, which is where you'll have to figure out which pin goes to what. Not being familiar with the GrovePi documentation, I can't tell you if this will be easy or hard to figure out, but I hope it's easy. The GrovePi system looks pretty nifty!

moodybass commented 8 years ago

Many thanks for the feedback @nebrius and @rwaldron, I'll continue to try and figure it out - yeah it is pretty nifty, nice and simple for quick prototyping. I shall report back as I learn more ;-)

rwaldron commented 8 years ago

@nebrius it may require io expanders? looks like analog and pwm chips on board http://www.dexterindustries.com/GrovePi/engineering/port-description/

nebrius commented 8 years ago

@rwaldron you're right, good catch.

rwaldron commented 8 years ago

@nebrius I will dig in and see what I can learn. Here's my rough plan:

That's it for now ;)

moodybass commented 8 years ago

Hey guys - I found this: https://github.com/O-Hahn/node-grovepi-oh Not sure if it's of any use?

rwaldron commented 8 years ago

Thanks, that confirms that we need to write expanders, which is easy—I just don't see what chips are being used.

rwaldron commented 8 years ago

The I2C stuff should work out-of-the-box though

rwaldron commented 8 years ago

Ok, I had to look through this: https://github.com/DexterInd/GrovePi/blob/master/Hardware/GrovePi%2B_2.2.sch, but I've learned that the GrovePi actually has an ATMEGA168 on board. That has a few important implications:

  1. The ATMEGA168 is a full μC which means...
  2. Grove wrote their own firmware for it, which means...
  3. We can't make a generic Expander for the chip.

So, we'll make a "GrovePi" Expander. I'll post an update as soon as I have something to try out.

rwaldron commented 8 years ago

An update, I can work with this https://github.com/DexterInd/GrovePi/tree/master/Firmware/Source/v1.2 to get support started

moodybass commented 8 years ago

This is amazing @rwaldron thank you and awesome. Obviously more than happy to help with testing. I shall confirm the I2C stuff tomorrow. I also thought same once I'd seen the post from @nebrius.

moodybass commented 8 years ago

As an aside, I also ordered and arduino Grove shield as well, I think this acts more "standard".

rwaldron commented 8 years ago

This is super rough, but I have to do some family stuff now: https://github.com/rwaldron/johnny-five/commit/6b51c73c43ecf5129c53e295b1d84f63bd6b1520

I will keep working on it tomorrow.

rwaldron commented 8 years ago

I've been working on this a bit more today and found a few major issues with their firmware and I'm not sure what to do now—need to think it through a bit :\

1.The firmware attempts to be an I2C slave, but implements no register.

  1. The cmd buffer and index is not cleared until another command is received, which means that things you only want to do once will actually repeat every loop iteration. I'm going to try to send dummy data to avoid that.
    • affects ultrasonic: it always this process blocking code to repeat infinitely, which appears to prevent receipt of future writes to the I2C bus (still an issue)
      1. ultrasonic fails after a 3-4 reads

The good news:

  1. Things that are working:
    • Analog read
    • digital read
    • digital write
    • ping read
rwaldron commented 8 years ago

When testing > 1 component in use simultaneously, I discovered that my note from above is not just a "problem", it's basically a non-starter right now.

1.The firmware attempts to be an I2C slave, but implements no register.

This firmware was designed to for a completely synchronous interaction by a client that's also completely synchronous. It assumes that every "read" sequence:

  1. command: what do I want to read?
  2. request a response: what was the value/values read?

Will happen back-to-back and step 1 and 2 will be exactly sequential. There is no benefit to writing program code like this for Node.js. The alleged-Node.js libraries that the creators of GrovePi created, are just wrong: all reads are synchronous (0, 1) without being wrapped in a process.nextTick or setImmediate—and even more disturbingly, they are using a process blocking "sleep" (these can be useful for program state initialization, but not acceptable after the first execution turn is complete). Johnny-Five embraces Node.js IO programming paradigms as much as possible and as often as possible. In practice, you can imagine an implementation that does multiple step-1-like tasks before any step-2-like task is executed. They may even be mixed or out of order: 

command A
command B
request response A
request response B
command A
command B
request response B
request response A

But this firmware will only work if the client only does this: 

command A
request response A
command B
request response B

Which is not how asynchronous IO, execution-turn, event-based programs are expected to behave. Most of the problems created by this terrible design could be mitigated if the read request responses included some kind of identification, ie. "what pin was this value read from"? I actually think that might've been intended, since most of the responses look like this: [ unused, msb, lsb, unused ] (maybe the leading byte was supposed to be pin number?); but then you look at digital read, which just responds with a single [ byte ] :(

I have to start over.

nebrius commented 8 years ago

Will happen back-to-back and step 1 and 2 will be exactly sequential. There is no benefit to writing program code like this for Node.js. The alleged-Node.js libraries that the creators of GrovePi created, are just wrong: all reads are synchronous (0, 1) without being wrapped in a process.nextTick or setImmediate—and even more disturbingly, they are using a process blocking "sleep" (these can be useful for program state initialization, but not acceptable after the first execution turn is complete).

Eww eww eww eww eww eww eww

rwaldron commented 8 years ago

@nebrius no kidding :\

I was able to completely rework support by taking the same approach that I've used with multiplexer chips. Unfortunately this is resource intensive because it requires constantly requesting new read operations, instead of just sending a single instruction and then handling continuous async delivery of values.

rwaldron commented 8 years ago

https://github.com/rwaldron/johnny-five/tree/grovepi-expander I'm going to sit on it for the night

moodybass commented 8 years ago

@rwaldon - please excuse my noob ;-) I assume that this is specific to the Rpi implementation, because the shield is also interpreting (other than the ports identified that don't)?

The arduino shield turned up today, from what I can tell it simply exposes all the pins for Grove "plugins", which I guess theoretically means it will work with Johnny-Five (I have set aside time tomorrow evening to take a look).

Thank you for this, proves what a wonderful place this community is! :-)

On Tue, 8 Dec 2015 22:24 Rick Waldron notifications@github.com wrote:

https://github.com/rwaldron/johnny-five/tree/grovepi-expander

— Reply to this email directly or view it on GitHub https://github.com/rwaldron/johnny-five/issues/971#issuecomment-163037281 .

rwaldron commented 8 years ago

please excuse my noob ;-) I assume that this is specific to the Rpi implementation, because the shield is also interpreting (other than the ports identified that don't)?

It's specific to GrovePi firmware, so yes.

The arduino shield turned up today, from what I can tell it simply exposes all the pins for Grove "plugins", which I guess theoretically means it will work with Johnny-Five (I have set aside time tomorrow evening to take a look).

Yes, in fact, this is how I worked on the Expander until my GrovePi arrived. I flashed a regular Arduino with their firmware and then connected it to another Arduino: