Closed ryoshu closed 9 years ago
Is this also on the latest IoT kit image? Can you provide the version? Really sorry all of these errors are getting in your way and I'll work on addressing them ASAP
It's the latest version: http://software.intel.com/iot. Let me know if you need anything else. Thanks!
I just updated the mraa bindings used by Galileo-IO to the latest release and tested digital pins 2 through 13 to confirm digital writes and all pins worked correctly. Please run the following and post back the output, thanks!
node -e 'console.log(require("mraa").getVersion());'
I've hit this problem as well on both Galileo generations. Not sure how to debug this, but:
GALILEO GEN1 FW 1.0.3
This is while using a fresh install of the current IoT Devkit image 1.1 [1].
[1] http://iotdk.intel.com/images/1.1/iot-devkit-201409031152-mmcblkp0.direct.bz2
$ node -e 'console.log(require("mraa").getVersion());' v0.5.0-12-g3898182
Package: libmraa0 Version: 0.5.0.12 Provides: libmraa-dev, libmraa-dbg, libmraa-doc, libmaa-dev, libmaa-dbg, libmaa-doc, libmaa0 Replaces: libmraa-dev, libmraa-dbg, libmraa-doc, libmaa-dev, libmaa-dbg, libmaa-doc, libmaa0 Conflicts: libmraa-dev, libmraa-dbg, libmraa-doc, libmaa-dev, libmaa-dbg, libmaa-doc, libmaa0 Status: install user installed Section: libs Architecture: i586 Maintainer: Intel IoT-Devkit MD5Sum: 473e2b3092bf293045acbebf640286dc Size: 189072 Filename: libmraa0_0.5.0.12_i586.ipk Source: https://github.com/intel-iot-devkit/mraa Description: mraa built using CMake Installed-Time: 1411900482
GALILEO GEN2 FW 1.0.2 (Not current!)
I'm not sure about the version of the IoT Devkit image version on this board, but judging by the libmraa(3) version I assume it's 1.0:
$ node -e 'console.log(require("mraa").getVersion());' v0.4.4
Package: libmraa0 Version: 0.4.4-r0 Depends: libgcc1 (>= 4.8.2), python-core, libpython2.7-1.0 (>= 2.7.3), libstdc++6 (>= 4.8.2), libc6 (>= 2.19) Status: install user installed Architecture: i586 Installed-Time: 1408097108
...didn't need to sanitize any of that, it's the exact output of command line.
An important clue is that while using the Intel XDK [1](latest version with IoT components) to upload and run a blink example similar to ryoshu's code, it actually works (the light blinks) on the Gen2 board with 1.0.2 firmware (the identical configuration as indicated in the previous comment [2].) Since the XDK uploads NodeJS projects to the Galileo, this clue could be useful in narrowing the problem scope.
[1] http://xdk-software.intel.com/ [2] https://github.com/rwaldron/galileo-io/issues/16#issuecomment-57081965
Sorry, but I've never used the XDK. When working directly on Galileo-IO or using it as an IO Plugin for Johnny-Five in projects, I just SSH to the board and use rsub to open files from the board for editting in Sublime Text.
Despite the obviously negative tone of this deleted part of your comment, there were some valid questions:
If you're feeling generous, then please share how you fix these things so that we can learn and do it ourself,
- SSH to board
touch test.js
rsub test.js
- Write out the code in test.js that will hopefully produce the error. In best cases, the code has been provided in the bug report.
- In terminal:
node test.js
- Make best possible assertion about observed behavior.
I have a script for files in galileo-io/lib/*
that will scp the files to the board when changes are made locally.
If problems can be reproduced, write tests in test/*
and work towards making them pass as well as observing the correct behavior of the original test case program.
Are most problems resembling this one in the bindings of libmraa(3)? Source file?
I'm not sure how to answer this since I haven't been able to reproduced the bug. It's still unclear to me how this bug was encountered—no one has provided an actual "steps to reproduce".
As I mentioned in my email response, the following must be confirmed before a Galileo-IO version is published to npm
root@quark016d09:~/projects/coral-test# cat /etc/version 201409031130
root@quark016d09:~/projects/coral-test# node -e 'console.log(require("mraa").getVersion());' && node -v v0.4.5 v0.10.28
Sorry about the delay!
@ryoshu thanks! Can you update the libmraa0 bindings to the latest version (will be easier for us to coordinate)
echo "src mraa-upm http://iotdk.intel.com/repos/1.1/intelgalactic" > /etc/opkg/mraa-upm.conf
opkg update
opkg install libmraa0
'# opkg upgrade' Upgrading libmraa0 on root from 0.4.4-r0 to 0.5.0.12... Downloading http://iotdk.intel.com/repos/1.1/intelgalactic/libmraa0_0.5.0.12_i586.ipk. Upgrading upm on root from 0.1.6-r0 to 0.1.8.28... Downloading http://iotdk.intel.com/repos/1.1/intelgalactic/upm_0.1.8.28_i586.ipk.
When I tried upgrading on Gen2 it didn't help.
And possibly related, setting GPIO pins manually seems to be defective:
-sh: echo: write error: Device or resource busy
Maybe the problem we're seeing is not even in user space?
That looks like a pretty serious issue. As a software engineer, I've spent 15 years assuming that the code I wrote was the source of the bug and so I sometimes forget when dealing with hardware that this is not always the case.
root@quark016d09:~/projects/coral-test# echo "src mraa-upm http://iotdk.intel.com/repos/1.1/intelgalactic" > /etc/opkg/mraa-upm.conf root@quark016d09:~/projects/coral-test# opkg update Downloading http://iotdk.intel.com/repos/1.1/iotdk/Packages. Updated list of available packages in /var/lib/opkg/iotdk. Downloading http://iotdk.intel.com/repos/1.1/intelgalactic/Packages. Updated list of available packages in /var/lib/opkg/mraa-upm. root@quark016d09:~/projects/coral-test# opkg install libmraa0 Upgrading libmraa0 on root from 0.4.5-r0 to 0.5.0.12... Downloading http://iotdk.intel.com/repos/1.1/intelgalactic/libmraa0_0.5.0.12_i586.ipk. Removing package libmraa-dev from root... Removing package libmraa-doc from root... Removing obsolete file /usr/lib/libmraa.so.0.4.5. Configuring libmraa0. root@quark016d09:~/projects/coral-test# node -e 'console.log(require("mraa").getVersion());' v0.5.0-12-g3898182
Same issue. PWM pins don't blink, but non-PWM pins do.
Let me reimage some another SD card with the default Yocto image, rather than the IoT Devkit. That could help isolate where the issue is.
Side note: I've never been able to blink the on-board led by writing to pin 13's gpio via sysfs (on gen 1). I have a thread on the intel community forums that was never answered in any helpful way: pin 13 is not actually connected to the onboard led, so how does the gen 1 galileo know to control the onboard led when a user uploads the blink.ino program via the IDE (which uses pin 13)?
(Note, this is unrelated to our current issue)
By any chance, do you have a sketch running?
Not currently. I've had a sketch running before, but now I remove it and reboot, just in case there's some pin exporting strangeness (I've also killed the process before, but I haven't checked to see if that causes pin exporting weirdness).
Let me reimage some another SD card with the default Yocto image
Just a heads up, this doesn't ship with the libmraa0 bindings and apparently cannot be installed either: https://github.com/intel-iot-devkit/mraa/issues/2#issuecomment-54199201, which means this bug can't actually exist there. Galileo-io will fall back to filesystem gpio/sysfs when libmraa0 isn't present, so your code will be in an entirely different path.
Hrm. Thanks for the heads up. What OS/version are you using? I've tried a few Gen 2 boards now and two fresh installs of the latest IoT devkit.
iot-devkit (Intel IoT Development Kit) 1.1
201409031130
Very strange! I'll do a step-by-step unboxing tomorrow and post the steps + results using a brand new board and brand new download.
I'm having similar issues with the PWM pins (digital works well). Using the latest IOTDK image and having updated with opkg
root@quark0171ae:~# node -e 'console.log(require("mraa").getVersion());'
v0.5.0-12-g3898182
I ran servo-write.js
with a servo motor on pin 3 (power on 5v, and ground pin on ground) and then analog-write.js
with an LED just to be sure.
It flickers for a second and then there is no output. I'm going to look at running the python examples that come with MRAA to help narrow down what the issue is next.
I pulled the MRAA repo and went into the examples/python folder.
Both the cycle-pwm.py
and blink-io8
examples are working well for me.
There are four javascript examples in the directory as well:
AioA0.js Blink-IO.js GPIO_DigitalRead.js GPIO_DigitalWrite.js
I tested all four with my build and they work. Analog read from A0 and writing out to pin 5 which is a PWM pin - but there is no PWM examples included with MRAA - or servo examples as far as I can tell.
@sethismyfriend thanks for doing this research, super helpful :) I'll focus my attention on PWM for Servo controlling
Step-by-step from this morning - https://gist.github.com/ryoshu/b3a59142c46e5081704f
@ryoshu - can you try running some of the examples in MRAA to confirm if they work?
@sethismyfriend I have a big changeset coming, will ping when ready
@sethismyfriend Blink on pin 9 and analog read on pin A0 confirmed in the MRAA examples.
About to push this release, just waiting for new tests to run through travis
@ryoshu @sethismyfriend v0.3.2 is now on npm
This is the most relevant commit: https://github.com/rwaldron/galileo-io/commit/389c91e806ab935b79274060c419ea79601993a7
Actually... v0.3.3
sweet - will try this before the end of the day
Servo example confirmed to work on my build!
Digital write on PWM pins still not working for me. Confirmed digital write works through Arduino IDE. Confirmed still working using MRAA.
Can you paste the JS code?
var board = new Galileo();
var pin = 9;
board.on("ready", function() {
console.log("ready");
var byte = 0;
this.pinMode(pin, this.MODES.OUTPUT);
setInterval(function() {
board.digitalWrite(pin, (byte ^= 1));
}, 500);
});
I'm going to assume that includes: var Galileo = require("galileo-io");
?
I'm wondering how you are running this code? Specifically, do you ssh to the board, then type something like node file.js
? Or is this controlled by some other means?
What is the output of the program run?
You mentioned trying sketches again, are you certain those sketches are properly removed after testing them?
What is the current installed version of Galileo-IO?
The require is in there. Sorry about that!
I've used iTerm with screen, ssh from Terminal and Putty on Win 8.1. I use vi to create and edit the files while logged into the board.
The output of the program is "ready".
re: sketch, "kill -14 {pid}" of the sketch and rm'd it from /sketch. I've also rebooted after removing the sketch. kill left the pin high, so I used node and MRAA to turn it low.
I've tried running some examples in /eg. Still no luck. Version is 0.3.3 according to package.json.
I'll retest all pins on digital write (PWM and regular) as I only tested pin 9 and 13 this time. I'll also hook up another Gen 2 and go through the tests again. And I've got some Gen 1s lying around so I'll try one of those and let you know if any of them work.
Are you in Brooklyn today?
Alas, no. Sent you an email.
I feel completely insane right now... I've using existing code that was "basically the same" as your examples, but operating on pin 3 (also PWM) and everything works correctly—I just tried your code exactly as is—on pin 9—and reproduced the issue. Hold off on testing until I ping back.
Also, I created a scoping mistake when I introduced IS_TEST_MODE
that was causing the fallback path to be taken.
Here's what I think happened...
@ryoshu can you try v0.3.4
I had an issue where if I had another instance of node running somewhere else the servo example was not working.
BTW - @rwaldron the servo is humming that I am using, a HiTec HS-425BB. That means that the frequency calculation for the motor might not be right. I'll play around with the code a bit to see if I can reduce the humming.
analog_write.js is working well.
I tried running analog_read and encountered this error on my board:
root@clanton:~/galileo-io/eg# node analog-read.js
READY
/home/root/galileo-io/lib/galileo.js:84
processRead(board, report, board.pins[report.index].read());
^
TypeError: Object #<Pin> has no method 'read'
at /home/root/galileo-io/lib/galileo.js:84:61
at Array.forEach (native)
at Object.read [as _onImmediate] (/home/root/galileo-io/lib/galileo.js:82:15)
at processImmediate [as _immediateCallback] (timers.js:336:15)
I had an issue where if I had another instance of node running somewhere else the servo example was not working.
Are they both controlling pins? That's probably an issue with the mraa
bindings—presumably the pin state management expects only one process to be controlling at a time. I'll look into this a little more, but I'd consider refactoring my system to run in one process...
BTW - @rwaldron the servo is humming that I am using, a HiTec HS-425BB. That means that the frequency calculation for the motor might not be right
Did you mean pulse width? There is no code changing the frequency. What kind of hum are you hearing? Light hum? Gear grind? Can you record the sound? The HS-425BB is a pretty low end servo (bottom of the barrel for Hi-Tec). I always experience a bit of hum with these:
Additionally, the HS-425BB is a 90° stock rotation, but can support a 180° modified rotation; since Firmata based systems default to the Servo.cpp's default of 0-180° degrees (mapped to 544-2400μs pulses), then external code is responsible for setting sub-180° ranges—which is why this is built in to Johnny-Five's Servo
class:
// initialize a servo that has a physical limit of 90° (centered)
var servo = new five.Servo({ pin: 9, range: [ 45, 135 ] });
For Galileo-IO, I found that 544-2400μs range would result in the servo arm over extending past 0° to ~-5°, 90° to somewhere between 80-87° and 180° falling short at about 160° (measured with http://www.servocity.com/html/servo_protractor.html#.VC9HuyldVZM or plain protractor for models that don't fit). For continuous servos, the result was a stopping point that wasn't 90°.
For each μs range I worked through, the following was tested:
In the end, the most consistently accurate range was 600-2600μs. This was a lot of work ;)
If using analogWrite
on it's own is resulting in gear grinding at the ends, then I suggest using Johnny-Five with Galileo-IO to have at least software-level control over the servo range. I never intended Galileo-IO to be used a stand-alone library—but only because that would make for a crummy programming experience. I strongly encourage the use of Johnny-Five, coupled with Galileo-IO (this is how I use it in my own projects).
I tried running analog_read and encountered this error on my board:
This is a duplicate of #17
I just pushed a patch that should address this error, but if there is no read
method there, then something is wrong with mraa
bindings.
Apparently the Intel XDK runs a node process on boot, so I killed that per @sethismyfriend. Now I get a different behavior after upgrading to v0.3.5.
I run blink.js sketch on pin 3 and it goes high, then never goes back to low. I retested all digital pins using the same script from above. Other than 3 going high and staying high, no other PWM pins blink. All non-PWM pins blink.
Running the Blink-IO.js example in MRAA works fine on pin 3.
MRAA Version: v0.5.0-12-g3898182
Apparently the Intel XDK runs a node process on boot, so I killed that per @sethismyfriend.
- What is the node process?
- What does it do?
- Where is the source?
- Is this process only run when working from the XDK?
I have never used the XDK, which means that Galileo-IO has ever been tested under those circumstances. I'm concerned that it won't matter what I do, there is no way to account for this other node process in Galileo-IO (because there is now way to safely know about other processes).
I run blink.js sketch on pin 3 and it goes high, then never goes back to low.
Here are some demonstrations of the correct behavior, along with the code used to produce them...
Blink, all pins, Galileo-IO
https://www.youtube.com/watch?v=mihxl7DNJOY
var Galileo = require("galileo-io");
var board = new Galileo();
board.on("ready", function() {
console.log("ready");
var start = Date.now();
var byte = 0;
var pins = Array.from({ length: 12 }, function(_, i) {
return i + 2;
});
var toOutput = function(pin) {
this.pinMode(pin, this.MODES.OUTPUT);
};
var highOrLow = function(pin) {
this.digitalWrite(pin, byte);
};
pins.forEach(toOutput, this);
setInterval(function() {
byte ^= 1;
pins.forEach(highOrLow, this);
}.bind(this), 500);
});
https://www.youtube.com/watch?v=Kn9dfdAJ9QM
var temporal = require("temporal");
var five = require("johnny-five");
var Galileo = require("galileo-io");
var board = new five.Board({
io: new Galileo()
});
board.on("ready", function() {
var leds = new five.Leds([ 3, 5, 6 ]);
function fader() {
temporal.queue([
{
wait: 1000,
task: function() {
leds.fadeIn(500);
},
},
{
wait: 1000,
task: function() {
leds.fadeOut(500);
}
},
{
wait: 1000,
task: function() {
fader();
}
}
]);
}
fader();
});
Fade in/out, all PWM pins, Johnny-Five + Galileo-IO:
https://www.youtube.com/watch?v=SdQr7RKZDow
var temporal = require("temporal");
var five = require("johnny-five");
var Galileo = require("galileo-io");
var board = new five.Board({
io: new Galileo()
});
board.on("ready", function() {
var leds = new five.Leds([ 3, 5, 6, 9, 10, 11 ]);
function fader() {
temporal.queue([
{
wait: 1000,
task: function() {
leds.fadeIn(500);
},
},
{
wait: 1000,
task: function() {
leds.fadeOut(500);
}
},
{
wait: 1000,
task: function() {
fader();
}
}
]);
}
fader();
});
Same: v0.5.0-12-g3898182
root@quark016df6:~# ps | grep node 157 root 34656 S /usr/bin/node /opt/xdk-daemon/main.js 181 root 78244 S /usr/bin/node /opt/xdk-daemon/current/appDaemon.js 192 root 2488 S grep node
That's on the Gen 2 Galileo running the IoTDK latest. It loads on startup. Do you not have those processes running on your Galileo with the IoTDK build?
Expected behavior: Digital write should send HIGH on all digital pins.