davidjsherman / aseba Goto Github PK

Asebahttp renumbers nodes when there are conflicts. This renumbering should be considered random, even thought currently there is a simple pattern. A client can identify a node by role, using aeslId.

Should we guarantee that, if there are no node conflicts, then no renumbering is done? We could then reliably remap nodes manually using attributes in their Dashel target specifications.

The e2e tests in 3004-__spec.js and 3005-__spec.js assume the renumbering scheme of asebadummy nodes, and fail on Windows XP. Is the renumbering policy wrong, or are the tests wrong?

Node-RED example alarm clock
Node-RED example with feedback loop on event stream
Node-RED example push custom bytecode
Node-RED example with feedback loop on get variable

The commonDefinitions table is returned by the compiler after analysis of the AESL file. One such table is stored in the HttpInterface hub, but since different nodes may be running different programs, we need to store as many tables as nodes. So commonDefinitions should in fact be a map from nodeId to tables (analogously to the change from asebaTarget to asebaTargets).

Asebahttp only learns about a node's variables when it loads an aesl file. It should be possible to use a node without one, so asebahttp should always at least do a dummy compilation to initialize allVariables and the node description.

Hi,
For a demo at the Colloque Robotique et Éducation, I'm trying to remote control a Wireless Thymio.
Asebahttp is working well for wired Thymio, but I encounter issues with RF communication.

With a wireless Thymio wired, it works well:
I can fetch the temperature

> GET /nodes/thymio-II/temperature HTTP/1.1
[307]

Or the ground sensors

> GET /nodes/thymio-II/prox.ground.ambiant HTTP/1.1
[0,0]

With a wireless Thymio connected with the RF key:
At first glance it seems to work

GET /nodes/thymio-II/ HTTP/1.1

{"node":34016,"name":"thymio-II","protocolVersion":4,"aeslId":34016,"bytecodeSize":1534,"variablesSize":620,"stackSize":32,"namedVariables":{"_id":1,"event.source":1,"event.args":32,"_fwversion":2,"_productId":1,"buttons._raw":5,"button.backward":1,"button.left":1,"button.center":1,"button.forward":1,"button.right":1,"buttons._mean":5,"buttons._noise":5,"prox.horizontal":7,"prox.comm.rx._payloads":7,"prox.comm.rx._intensities":7,"prox.comm.rx":1,"prox.comm.tx":1,"prox.ground.ambiant":2,"prox.ground.reflected":2,"prox.ground.delta":2,"motor.left.target":1,"motor.right.target":1,"_vbat":2,"_imot":2,"motor.left.speed":1,"motor.right.speed":1,"motor.left.pwm":1,"motor.right.pwm":1,"acc":3,"temperature":1,"rc5.address":1,"rc5.command":1,"mic.intensity":1,"mic.threshold":1,"mic._mean":1,"timer.period":2,"acc._tap":1},"localEvents":{"button.backward":"Backward button status changed","button.left":"Left button status changed","button.center":"Center button status changed","button.forward":"Forward button status changed","button.right":"Right button status changed","buttons":"Buttons values updated","prox":"Proximity values updated","prox.comm":"Data received on the proximity communication","tap":"A tap is detected","acc":"Accelerometer values updated","mic":"Fired when microphone intensity is above threshold","sound.finished":"Fired when the playback of a user initiated sound is finished","temperature":"Temperature value updated","rc5":"RC5 message received","motor":"Motor timer","timer0":"Timer 0","timer1":"Timer 1"},"constants":{"QUEUE":4},"events":{"Q_motion_started":5,"Q_motion_ended":5,"V_leds_circle":8,"A_sound_system":1,"R_state_update":23}}

I can move motors

GET /nodes/thymio-II/motor.left.target/42 HTTP/1.1

But.. any other HTTP requests (like temperature or prox.ground.ambiant) fail, no data is returned by the server, the client wait until the timeout.

@davidjsherman @stephanemagnenat Any idea where this difference between RF and wired communication come from and how to solve it ?

A stream can transmit messages for more than one node, so this should really be StreamNodeIdSetMap, i.e. std::map<Dashel::Stream*, std:set<unsigned> >.

In response to the /nodes/Thymio-II request, asebascratch reports a list of variables and events that can be used to query the node. This list is extracted from two sources: the nodeDescription returned by the node, and a parse of the AESL program that asebascratch loads into the node.

However, asebascratch defines scratch-specific routes such as scratch_clear_leds, that are hard-coded.

Since these aren't real events, they should be faked into the list. Probably the best place would be a subclass method ScratchInterface::evNodes in scratch.cpp.

Currently asebahttp offers the option --aesl to load an Aesl program at startup on all nodes connected to the switch. A program can also be loaded onto an individual node using a PUT request. In both cases, asebahttp compiles the program, uploads the byte code, and restarts the node. But also importantly, it remembers the variable and events discovered in the Tesl program, to that it can define the corresponding URI routes for HTTP requests.

However, an Aesl program can be loaded onto the node by another client such as Aseba Studio, and there must be a mechanism for informing asebahttp about the program so that it can extract the variables and events from it.

One solution would be to separate the compiling, loading, and running operations. Thus PUT would compile the node definition (insofar as asebahttp sees it) but the uploading and running operations would be separate steps.

Since we want to do this on a per-node basis, and these operations are updates to the node's state, the appropriate change is to add a POST method to the node route, with a JSON payload describing the update. For example, {executionState="upload"} or {executionState="run"}.

Note that the REST paradigm is still followed here:

• GET /nodes/ID retrieves the robot's definition
• PUT /nodes/ID replaces the robot's definition
• POST /nodes/ID updates the robot's definition and state

Note also that retrievals and updates of variables and events with routes /nodes/ID/VARIABLE are not affected.

In addition to the simple JSON report about known nodes, asebahttp should report the exact interface it will respect using OAS.

This can be used to generate client applications, and end-to-end testing code.

Add asebascratch, with launcher and icon, to the Aseba distribution.
Add Scratch examples to the Aseba distribution in examples/.
Update Aseba wiki with some basic exercises using these examples.

Currently, there are only two ways to send an Aesl program to a node from the command line.

1. Run asebahttp --Kiter 0 (works since 873cad2).
2. Run asebamassloader, then kill the process after the program is loaded.

Using asebamassloader would be more convenient if there were a way to bound the number of nodes it expects to update. The proposal is to add three command line options:

• --nodeCount INT aka -n INT: quit after loading INT nodes
• --timeout INT: quit if no new node description arrives in INT seconds
• --pollInterval INT: ping the network for node descriptions every INT milliseconds (default 1000)

NB If asebahttp is already running, then from the command line it is better to PUT the program using curl -H 'Content-Type: application/octet-stream' --data-ascii "$(cat vmcode.aesl)" -X PUT, because otherwise asebahttp won't learn about new Aesl program in the node and can't do introspection.

Snap! doesn't use the same asynchronous protocol as Scratch.

Add an option to block on the HTTP request. For example, job 0 means block.

When asebahttp detected that the robot is not present (either dashed disconnect, or Aseba disconnected), it must:

• broadcast an SSE event that the node is disconnected
• loop looking for reconnection; note that we need to use dashed step so that the HTTP interface isn't starved

When the node is connected, asebahttp must:

• retrieve the (possibly new) description from the node
• broadcast an SSE event that the node is connected

Since more than one node of the same kind can be attached, it is necessary to provide a mechanism for resolving conflicts. The asebaswitch switch introduced two parameters, remapLocal and remapTarget, so that node id can be substituted. In commit fbcac09 these parameters are parsed from the dashel targets and stored in the idSubstitutions map, but are not actually used to substitute ids on the fly.

When there is only one node on a stream, it should not be necessary to give the remapTarget id, since we can learn it from the node description (once it arrives).

The connection dot in Scratch blinks red at 1-second intervals. It is annoying but does not seem to affect throughput. If one replaces sleep(timeout) by sleep(50) in HttpInterface::run1s, the problem goes away — but it isn't obvious why.

Scratch polls asebascratch at 30 Hz. In order to reduce latency we maintain a cache of variable values and request variable updates less frequently. Each variable is a round trip in Aseba with the corresponding overhead.

Since we know which state variables are exposed to scratch, we could package them up in a single broadcast event that is sent by the robot at a regular frequency

Three strategies seem possible.

1. Scratch blocks for sprites and Scratch blocks for robots are entirely independent
2. New robot blocks have the side effect of updating the state of a linked sprite
3. Existing sprite blocks are interpreted as robot commands, when the robot and the sprite are linked

We need to decide which blocks are most useful for young programmers, and find a mechanism for linking sprites and robots. Possibly a system of pre- and post-hooks in ScratchX would be a good approach.

https://kripken.github.io/emscripten-site/index.html

Best practice is one big js so combine common and compiler. GitHub project aseba-javascript with own CMakefile and Aseba as module

cmake -DCMAKE_TOOLCHAIN_FILE=$EMSCRIPTEN/cmake/Modules/Platform/Emscripten.cmake --bind -s -Wno-warn-absolute-paths --memory-init-file 0 -s DISABLE_EXCEPTION_CATCHING=0 -s ALLOW_MEMORY_GROWTH=1 /your/source/dir/mylibrary

Looking up the stream for a nodeId is assumed to work, but nothing guarantees that the nodeId found in the URL is valid; getStreamFromNodeId should raise an exception instead of simply printing an error message.

The standard Windows error ERROR_STACK_OVERFLOW defined by MingW32 in /mingw32/i686-w64-mingw32/include/corerror.h masks the one in compiler/errors_code.h

• compiler/errors_code.h
• maintainer/translations/02_sync_compiler_translation.py

Jenkins declarative pipeline syntax changed in version 1.0.

See enki-community/enki@79b91aa for an example of what changes need to be made to the Jenkinsfile.

Asebascratch creates boolean variables for certain state changes, so that Scratch's polling can pick them up. In the same way that davidjsherman/inirobot-scratch-thymioII#5 proposes to propagate local events like button presses to the Aseba bus as user events, these boolean variables should also generate user events.

Candidates are: b_touching/front, b_touching/back, b_touching/ground.

This AESL file defines the basic Scratch-like movement events, and should be the default program loaded by asebahttp.

The testing scripts introduced in 827cc04 need to refer to compiled targets, but the file names of the targets aren't known until generation. So the testing scripts are template files, rewritten by the compile targets create-run-test-asebahttp, create-run-e2e-http, create-run-e2e-switch. The script rewriting from d28c6d1 uses Perl.

We should use CMake instead.

Asebahttp uses -p for the HTTP port number, which conflicts with asebaswitch's use of -p for the Dashel target port.
Proposed options:

• -v, --verbose : makes the switch verbose
• -d, --dump : makes the switch dump the content of messages
• -w, --http port : listens to incoming HTTP connections on this port
• -p, --port port : listens to incoming Aseba connection on this port
• -a, --aesl file : load program definitions from AESL file
• -K, --Kiter n : run I/O loop n thousand times (for profiling)
• -l, --loop : makes the switch transmit messages back to the send, not only forward them.
• --rawtime : shows time in the form of sec:usec since 1970
• -h, --help : shows this help
• -V, --version : shows the version number

Le script apidoc-to-stubs.perl a un petit bug : quand il génère les définitions générales (la première partie du fichier généré), il y a une } de trop à la fin, avant ");". C'est un cas différent que lors d'un appel à REGISTER_HANDLER, car on ne fait qu'initialiser une variable.

HTTP requests should consistently succeed with 200 OK or fail with 400 Bad Request, 405 Method Not Allowed, 410 Gone, or possible 500 Internal Server Error or 503 Service Unavailable. Not all errors are handled (as of commit 5649ea1). When they are, the logic is scattered in the handlers.

We should probably use exceptions for these error conditions, and add a try/catch in HttpInterface::routeRequest to finish the request with the proper response code when an exception occurs.

In dæmon mode, we want asebahttp to add or remove streams (and thus their nodes) based on connection status. Dashel can enumerate ports, but needs to be called. Dashel notices disconnects and asebahttp is informed.

However, port enumeration needs to be triggered when a new device is connected. The proposal is:

• Add a command-line argument --watch could specify the name pattern to look for.
• Add a signal handler for USR1 that triggers port enumeration
• Add a udev rule to send this signal when a USB device is connected

Asebascratch works reliably when connected to the robot over USB, even when daisy-chained behind switches (asebaswitch, asebahttp, or asebaswitch). However, when connected to a robot using the wireless RF connection, its behavior is unreliable.

To separate this problem from job control (issue #22), commits 5914ea2 and 3fce454 introduce message generators that consistently reproduce this behavior.

• examples/clients/scratch/e2e-scratch/run-generate-messages.perl imitates Scratch to generate a set of HTTP messages, for a simple scenario with repeated movements and LED changes.
• examples/clients/scratch/e2e-scratch/run-record.sh uses asebaswitch and asebarec to record the Aseba messages produced by this scenario, as well as the SSE stream produced by asebascratch. To simplify analysis, different filtered versions of the human-readable log files are extracted.

The attached file traces.tar.gz shows two runs of a newly powered-on Thymio RF robot reacting to the generated messages, either connected using USB (*.wired.*.txt) or connected using the RF dongle (*.rf.*.txt).

An Aseba node has a unique id and a text name. The HTTP routes defined by Asebahttp include a node specification, which can be a name or (since eb45095) the numeric id. If more than one connected node has the same name, then HttpInterface::getIdsFromURI arbitrarily returns the first one found in the nodesDescriptions map.

This is wrong, a request for such a name is ambiguous. Asebahttp should return 300 Multiple Choice with a JSON array of the specific queries it could accept. Each of these queries is the original query, with a node id substituted for the name.

It is possible that the handling of _busy is not reliable, since Scratch does not seem to block reliably on the move and turn wait blocks.
This simple Scratch program should repeat a simple set of movements four times, beeping in between each:

It will overrun the size 4 Qid buffer, even though we would expect that Scratch can't add more movement requests while it is waiting for the first move to complete.

Even increasing Qid to size 8 in thymio_motion.aesl, next dial and play system sound are interspersed with the movement commands. Scratch generates the following set of HTTP queries (/poll queries removed for clarity):

http://localhost:3112/reset_all 9
http://localhost:3112/nodes%2Fthymio-II%2Fscratch_set_dial/0 11
http://localhost:3112/nodes%2Fthymio-II%2Fscratch_clear_leds 11
http://localhost:3112/nodes%2Fthymio-II%2Fscratch_move/95/50 7
http://localhost:3112/nodes%2Fthymio-II%2Fscratch_turn/96/50 10
http://localhost:3112/nodes%2Fthymio-II%2FA_sound_system/5 6
http://localhost:3112/nodes%2Fthymio-II%2Fscratch_next_dial 4
http://localhost:3112/nodes%2Fthymio-II%2Fscratch_move/97/51 2
http://localhost:3112/nodes%2Fthymio-II%2Fscratch_turn/98/51 4
http://localhost:3112/nodes%2Fthymio-II%2FA_sound_system/5 9
http://localhost:3112/nodes%2Fthymio-II%2Fscratch_move/99/52 15
http://localhost:3112/nodes%2Fthymio-II%2Fscratch_next_dial 15
http://localhost:3112/nodes%2Fthymio-II%2Fscratch_turn/100/52 6
http://localhost:3112/nodes%2Fthymio-II%2FA_sound_system/5 5
http://localhost:3112/nodes%2Fthymio-II%2Fscratch_move/101/53 4
http://localhost:3112/nodes%2Fthymio-II%2Fscratch_next_dial 4
http://localhost:3112/nodes%2Fthymio-II%2Fscratch_turn/102/53 3
http://localhost:3112/nodes%2Fthymio-II%2FA_sound_system/5 9
http://localhost:3112/nodes%2Fthymio-II%2Fscratch_set_leds/0/7 7
http://localhost:3112/nodes%2Fthymio-II%2Fscratch_next_dial 12
http://localhost:3112/reset_all 13

Asebahttp is not yet equivalent to asebaswitch because it doesn't provide a Dashel target that can be used by Aseba clients such as Aseba Studio. Thus the only way to interact with the network of nodes is through the HTTP interface, which is not always convenient.

Essentially, in the constructor we need to execute
connect("tcpin:port=" + port);

If I have more than one wireless robot connected, a request on something like /nodes/<Id>/motor.left.target/150 works perfectly to control the target of one motor. But every request on local events are not dispatched according to the id, they are sent to every robot connected.

-> /nodes/<Id>/M_motor_left/150 will send the query to every nodes, in the same way I would have use "thymio-II" instead of the id.

It should be related to #28.

Use CUMSUM to detect sensor or position changes, send events only when necessary. Throttle to 10 Hz.

Button, tap events on demand.

Convergence with headless Enki?

Although asebahttp requires the node name in the HTTP request route, it doesn't do a good job passing this name around, and doesn't provide a way to distinguish between several nodes that have the same name. The route rules should be modified to also allow the Aseba id as well as the name.

Libjson is not a standard package. It is only used sparingly by asebahttp for JSON input and output and could be replaced by simple code.

• It is used for output of arrays of integers, in HttpInterface::incomingVariables, and for the description of the node, in HttpInterface::evNodes.
• It is used for input of arrays of integers, in HttpInterface::evVariableOrEvent, when assigning values to variables.

These limited uses don't require a full JSON parser and formatter.

Minimally:

• connection state
• vbat
• target description

Ideally:

• animation for reconnection
• shell-like answer-response for event
• log of SSE events

If a make an HTTP request on /nodes/thymio-II/prox.ground.ambiant when I have many Thymio connected (with RF module), asebahttp make a Segmentation Fault. I got this Segmentation Fault for every requests that expect an output.