search

davidjsherman / aseba

Aseba is a set of tools that allow beginners to program robots easily and efficiently.
http://aseba.wikidot.com
GNU Lesser General Public License v3.0
3 stars 2 forks source link

asebahttp make Segmentation Fault on a sensor request with many nodes connected #27

Open show0k opened 8 years ago

show0k commented 8 years ago

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.

davidjsherman commented 8 years ago

When you say "many," do you mean several robots connected at the same time, or do you mean that this happens with whatever robot you connect, and you have tried more than one?

If you have connected several robots, with the request /nodes you can see all of them and their unique ids. Instead of thymio-II you can address each robot by numeric id, for example to measure the ground color seen by robot 34016 you would use /nodes/34016/prox.ground.delta.

show0k commented 8 years ago

Sorry, I wasn't clear. By "many" I mean it happens if I connect more than one robot (I tried with one, two, and three together).

I use also their unique id, but the "thjymio-II" node is convenient to reduce the number of HTTP requests. I expected as output a list of list of values, but I think that the SegFault come because it is not implemented to fetch sensor values for many robot's at once.

davidjsherman commented 8 years ago

Asebahttp doesn't multiplex results from several robots, it only allows you to query one at a time. If there are several with the same symbolic name, then the choice is indeterminate. This is actually wrong: asebahttp should return 300 Multiple Choice (issue #28).

If you can invent a clean API for multiplexed results, I would be interested, please add it as a new issue tagged 'enhancement'.

However, it is a bug that the query /nodes/thymio-II/prox.ground.ambiant produced a segfault. Internal errors should be caught and return 500 Internal Server Error or 501 Not Implemented. When you try with two robots, does the fault happen immediately, or after some time? Are you loading an Aesl program?

show0k commented 8 years ago

The segfault happen just after the response of the server, which is the result for the first node (I think).

So it is also a bug to be able to control multiple robots at a time with requests like /nodes/thymio-II/motors.target/42 ?

davidjsherman commented 8 years ago

The short answer is that I only guarantee queries that unambiguously address single robots.

It's a bug that multiplexing works partially. I've tracked back to my commit eb4509583e8b81159714657a2970f9d554dc76f1 from 2016-01-25: it looks like I explicitly get a list of ids, HttpInterface:getIdsFromURI, but don't know how to use them. The bug is that HttpInterface::evVariableOrEvent calls finishResponse after every success, but doesn't break out of the loop. It should stop after the first one. There are two problems.

  1. The code works fortuitously for writes (SetVariable and UserMessage), at least as far as the robots are concerned, because each one is sent the correct Aseba messages. However the HTTP response is potentially wrong since only the last status code is returned.
  2. The code breaks horribly for reads (GetVariables), because HttpInterface::incomingVariables tries to finish the response as soon as the first variable value comes back, and won't wait for the others.

The difficulty is that Aseba is asynchronous: GetVariables is a request, the value is returned later in a Variables message. So HTTP requests for variables values are put on the pendingVariables list, and the HTTP connection is blocked until the answer arrives from the robot. If we add the semantics that a name refers to all robots with that name, then the HTTP response should wait for all of them, and return a JSON object with a response array for each robot. This limits the throughput to the slowest robot, so at a minimum we would need a timeout and be willing to send partial responses.

I would be interested in defining a clear semantics for multiplexing. One might use the the Promise API for inspiration. There is a performance advantage for write multiplexing, especially when you write the same program to several robots. Read multiplexing could be a synchronous poll of all the robots. An application could mix the two, sending multiple robot writes and making single robot reads.