PIR sensor problem still

It is amazing how hard it is to get some things to work in MRL.

My PIR code works on the bench using a mega board on digital pin 12.

You see on a mega board and using pin 12:

14:38:43.836 [COM8.portListener 1] INFO  class org.myrobotlab.service.Arduino - Publish Pin: {

  "pin": 12,

  "type": 2,

  "value": 0,

  "source": "arduino"

And when the PIR is triggered you see:

14:38:45.397 [COM8.portListener 1] INFO  class org.myrobotlab.service.Arduino - Publish Pin: {

  "pin": 12,

  "type": 2,

  "value": 1,

  "source": "arduino"

Channing to pin 30 it does not work and you see :

14:09:09.874 [COM8.portListener 1] INFO  class org.myrobotlab.service.Arduino - Publish Pin: {

  "pin": 30,

  "type": 1,

  "value": 0,

  "source": "arduino"

Pin 30 is the pin open on the mega board for Inmoov’s for the PIR sensor. The type comes up wrong!

I almost never give up…

So I thought pin 12 on the UNO board for the right arm is not used.  I will use that pin. Pins 2 through Pins 11 are for fingers and arm leaving 12 free.

Using Uno board and pin 12 you see:

16:30:05.824 [COM10.portListener 1] INFO  class org.myrobotlab.service.Arduino - Publish Pin: {

  "pin": 12,

  "type": 1,

  "value": 0,

  "source": "arduino"

So using an UNO board the type is wrong.  This is the same problem I was having on Sat. when Kevin and Claamity were helping me. They changed the MRL32.ino so the mega board could figure out analog or digital pin mapping correctly. We need to fix it for the UNO board, I think.

Harland

calamity's picture

Hi harland the arduino only

Hi harland

the arduino only send back pin and value. pin.type do not seem to be use (at least for digital polling) so you probably see undefined value.

What i'm not sure in your post if you are using the nervo board. On my nervo board, PIR sensor is attached to pin 23. I have also get confuse about it because gael use pin 30 in his script, but I had to use a voltmeter to figure it's on pin 23 on my.

Christian

 

kwatters's picture

pin mappings

Ahoy Harland,

  I think maybe the pin mappings are off for the Uno board.  Also, I know the uno has less memory on it.  If you use Arduino IDE 1.6.x it return a low memory warning.  If you program the Uno with Arduino IDE 1.0.5 it seems to be better.  

  Either way, the debugging of this kicked off a huge amount of refactoring of the MRLComm and all of the mrl java code.  It was getting very difficult to debug.  I didn't test digital pin polling, but I was seeing analog pin polling working as expected. 

  Long story short,  I think the code wil start getting more stable soon, but we still have a situation where there are bad messages/ garbled data getting sent to the arduino.  It seems to be a race condition.  Stay tuned...

-Kevin

  

GroG's picture

Why is return pin "type"

Why is return pin "type" critical ?  My feeling is it is being used as a bandaid for some other problem.

A solid refactoring would remove type & source from the publish.

A new publishPinDescription should be used to get the full list of details of all the pins for any board.

After the subscriber has a pin description, recieving type would be redundant.

Pin number and Pin value would only be needed when a pin is actively publishing..

Less data is faster...

GroG's picture

Ah .. now I remember some of

Ah .. now I remember some of the Goofyness ..

Arduino uses the same numeric identifier with 2 different sets of pins..  A5 != D5 .. and of course the constants get mapped to completely different numeric values in other contexts...

harland's picture

pin mapping important

I think Kev found that the type changes how the value is reported, analog or digital on Sat. 

So the wrong type results in the wrong answer.  Digital should be a 1 or 0 as shown with the mega bd and pins below 20. Why does pin 30 show the wrong type on the same board and the same code?

I like the idea of new features in MRL, but are old code should still work with some changes. the PIR sensor is in early code from Gael and many more users.

And why I am at this: MRL  version 1300 attaches my mega and uno board and runs Azul. Moving to 1372 version the mega board never gets attached. Running same code! I have to issue the command "detach everything" then issue the "attach everything" when running the script and then it works. Other people have reported problems with connections when starting.

GroG's picture

I agree pin mapping are

I agree pin mapping are important. There is even more complexity with the ESP8266 which has a completely different pin mapping.

In regards to the "new features" and "old code" - sometimes the situation occurs where its more detrimental to support "old code", and given that we have very limited resources, things will break.

We try to mitigate this as much as possible, with unit tests with every build, and refactoring.
Kevin and I have discussed some of these strategies at length.  Including refactoring Gael's old monster script.  

Old Script Refactoring:

  • Should be modularized for portability and readability - all gestures in a folder, add a gesture file to the folder and it becomes accessable to InMoov.
  • Configuration & connecting in a separate file - details on what services (Acapela vs MaryTTS) are used and configuration (com ports, servo mappings, custom sensors etc)

 

In regards to future pin publishing ...  I think the "identifier" of a pin should not be dependent on 2 separate fields (type + pin#).  Internally this should be handled differently, along with how it would be published ...  simply pinId & value.

harland's picture

just one of the elves

Just frustrated that I am having trouble getting it to work…

thanks for the reply

harland

 

harland's picture

added pir code to gihub folder

the code i have been using i listed

pir input testing with time.py

harland

moz4r's picture

Hi harland i had problems

Hi harland i had problems sometime to start arduino too with some MRL versions. This is my working configuration maybe can help you :

i01 = Runtime.createAndStart("i01", "InMoov")
right = Runtime.start("i01.right", "Arduino")
right.setBoard("mega2560")
right.publishState()
right.connect(rightPort)
sleep(1)
i01.startRightHand(rightPort,"atmega2560")

 

 

harland's picture

thanks

I will give it a try

calamity's picture

I know it may be frustrating

I know it may be frustrating to have stuff not working, but sometimes it need a step back to progress further

Kevin is working on improving the stability of the communication with arduino. He have a great solution for the problem now, but it's a bit tricky to implement and have it work good.

Right now, it takes a few second after a connect(port) call for the arduino to be ready. I have notice that it must return the mrlComm version number before the arduino start listening to commands.

moz4r have a good work around while kevin finish the fix, but to be sure to have it work, you should use in place of

sleep(1)

do

while right.mrlCommVersion != 33:

    sleep(1)

harland's picture

with the help

i added Moz4r's code and it solved my problem with not attaching the mega board when starting.

appriciate the help

elves at work