4

I am trying to print in python the messages from the web console using a callback on a onConsoleMessage event. Pepper (Edit: version 1.6) is running naoqi 2.5.5.5. I've modified the executeJS example as a test. The problem is I keep getting null for the message in the callback. Is it a bug that has been fixed in a newer version of naoqi ? I've had a look at the release notes but I didn't find anything.

Here is the code I am using:

#! /usr/bin/env python
# -*- encoding: UTF-8 -*-

"""Example: Use executeJS Method"""

import qi
import argparse
import sys
import time
import signal

def signal_handler(signal, frame):
        print('Bye!')
        sys.exit(0)

def main(session):
    """
    This example uses the executeJS method.
    To Test ALTabletService, you need to run the script ON the robot.
    """
    # Get the service ALTabletService.

    try:
        tabletService = session.service("ALTabletService")

        # Display a local web page located in boot-config/html folder
        # The ip of the robot from the tablet is 198.18.0.1
        tabletService.showWebview("http://198.18.0.1/apps/boot-config/preloading_dialog.html")

        time.sleep(3)

        # Javascript script for displaying a prompt
        # ALTabletBinding is a javascript binding inject in the web page displayed on the tablet
        script = """
            console.log('A test message');
        """

        # Don't forget to disconnect the signal at the end
        signalID = 0

        # function called when the signal onJSEvent is triggered
        # by the javascript function ALTabletBinding.raiseEvent(name)
        def callback(message):
            print "[callback] received : ", message

        # attach the callback function to onJSEvent signal
        signalID = tabletService.onConsoleMessage.connect(callback)

        # inject and execute the javascript in the current web page displayed
        tabletService.executeJS(script)

        print("Waiting for Ctrl+C to disconnect")
        signal.pause()

    except Exception, e:
        print "Error was: ", e


if __name__ == "__main__":
    parser = argparse.ArgumentParser()
    parser.add_argument("--ip", type=str, default="127.0.0.1",
                        help="Robot IP address. On robot or Local Naoqi: use '127.0.0.1'.")
    parser.add_argument("--port", type=int, default=9559,
                        help="Naoqi port number")

    args = parser.parse_args()
    session = qi.Session()
    try:
        session.connect("tcp://" + args.ip + ":" + str(args.port))
    except RuntimeError:
        print ("Can't connect to Naoqi at ip \"" + args.ip + "\" on port " + str(args.port) +".\n"
               "Please check your script arguments. Run with -h option for help.")
        sys.exit(1)
    main(session)

Output:

python onConsoleMessage.py --ip=192.168.1.20
[W] 1515665783.618190 30615 qi.path.sdklayout: No Application was created, trying to deduce paths
Waiting for Ctrl+C to disconnect
[callback] received :  null

Did someone face the same issue?

Thanks

beetix
  • 99
  • 9

1 Answers1

2

I have the same issue. You can easily reproduce it by opening two ssh consoles on the robot, and on the first one executing

qicli watch ALTabletService.onConsoleMessage

and on the second

qicli call ALTabletService.showWebview
qicli call ALTabletService.executeJS "console.log('hello')"

... and instead of "hello", you will see "null" appear in your first console.

HOWEVER - if your goal is to effectively test your webpage, what I usually do is just open the page on my computer and use the chrome console (you can set chrome up to act as if the page was a tablet of the right size, 1280x800); you can do this while still connecting the page to Pepper, as if it was on her tablet, using the method described here. This is enough for 99% of the case; the remaining 1% is things where Pepper's tablet is actually different from Chrome.

Emile
  • 2,946
  • 2
  • 19
  • 22
  • Thank you for this workaround. It's true that most of the testing can be done on the computer's browser. I noticed that you are working at Aldebaran. Do you have any insight on whether this will be fixed? Thanks – beetix Jan 12 '18 at 22:14