New Aseba Switch

[MobsyaBot]

Issue by stephanemagnenat Thursday Jan 11, 2018 at 14:54 GMT Originally opened as https://github.com/aseba-community/aseba/issues/777

---

This issue is the place for the general discussion on the new Aseba Switch to be released in 1.7.

[MobsyaBot]

Comment by davidjsherman Thursday Jan 11, 2018 at 15:53 GMT

---

Design

• Aseba HTTP v1 API.
• Documentation of HTTP APIs #526
• Aseba HTTP Switch as mDNS broker #764
• Aseba connexions over Internet #545

Features

• New switch always resolves names #546
• Support for websocket #626
• Add support for pseudo-terminal in asebaswitch #629
• Do not advertise targets being used #690
• Complete asebahttp integration #400

Bugs

• Support unicode names for variables, constants and events #609
• No error page in asebahttp2 #643
• Exception recovery in asebahttp #657
• In asebahttp, missing OPTIONS for PUT request #658
• e2e http tests do not stop #661
• asebahttp sometime do not connect in mac osX #718

[MobsyaBot]

Comment by ypiguet-epfl Monday Feb 05, 2018 at 11:49 GMT

---

New feature:

• http-level support for sendBytecode (message ASEBA_MESSAGE_SET_BYTECODE) to open Aseba Switch to alternative compilers

[MobsyaBot]

Comment by stephanemagnenat Monday Feb 05, 2018 at 12:36 GMT

---

http-level support for sendBytecode (message ASEBA_MESSAGE_SET_BYTECODE) to open Aseba Switch to alternative compilers

We discussed that with @davidjsherman in the initial design, as this is interesting but also makes it much easier for people to create and send broken bytecode through HTTP. For that reason we decided not to implement it in the first version, but we have an open mind I would say. The best would be to have a bytecode verification mechanism, but of course this is a major work in itself.

[MobsyaBot]

Comment by ypiguet-epfl Monday Feb 05, 2018 at 13:20 GMT

---

But we want to send bytecode you might consider to be broken, without your permission. We want multitasking. We want coroutines. We want local variables. We want recursion. We want 2D arrays. We want more types, booleans obviously, fixed point, floating point, structures, whatever. We want some freedom, we want it quickly, and we'll have it.

[MobsyaBot]

Comment by davidjsherman Monday Feb 05, 2018 at 14:42 GMT

---

@ypiguet-epfl concerning https://github.com/aseba-community/aseba/issues/777#issuecomment-363062467, the method API PUT /nodes/{node}/program in the v1 API being implemented suggests

A future extension will accept application/json requests containing a Symbol Table and a Bytecode

Would this meet your needs.

Note that both a Symbol Table and a Bytecode need to be supplied, in order to not break reflection (see GET /nodes/{node}/program).

[MobsyaBot]

Comment by ypiguet-epfl Tuesday Feb 06, 2018 at 10:01 GMT

---

Thanks, David. Yes, it would, unless the uploaded bytecode and symbol table are needlessly constrained by a strict validator.

[MobsyaBot]

Comment by davidjsherman Tuesday Feb 06, 2018 at 12:31 GMT

---

My fondest dream is that someday this API would be burned into the robot firmware, where practically speaking there would be no processing power for the compiler, much less a validator.

In a microservices architecture, compilation and validation would be the responsibility of a service, possibly even two different services. If a guarantee of validity were needed, I expect that they would be provided by a small certificate as part of the payload. For example a JSON Web Token (JWT) claim as defined in RFC 7519. The certificate would be the “proof” that the program was valid.

A validating compiler in the switch, like the one being implemented now, would trust itself and wouldn't need to provide a certificate.

[MobsyaBot]

Comment by mbonani Tuesday Feb 06, 2018 at 12:55 GMT

---

Hello, before going in perhaps complicated thing (excuse me if I understand wrong) what are really the need? @ypiguet-epfl what is the minimum to have for your development plan? can we perhaps have more details?

@all could we imaging a two phases plan for external compilation, one just sending bytecode without symbol table and validator and a second with a good implementation with perhaps also a certificate?

[MobsyaBot]

Comment by stephanemagnenat Tuesday Feb 06, 2018 at 12:58 GMT

---

The symbol table should go with sending the bytecode (otherwise there is a missing piece for building web-based IDEs), but actually it is not a lot of work to implement. The validator should be a further refinement, if we need/want it.

[MobsyaBot]

Comment by stephanemagnenat Tuesday Feb 06, 2018 at 13:00 GMT

---

And to clarify for people who accuse us of not being open-minded: as pointed by David we did think of the bytecode and we did put it in the specification. What I said is that we decided to not implement it in the first version, that is, the bare minimum for running properly Blockly, Scratch and co.

[MobsyaBot]

Comment by davidjsherman Tuesday Feb 06, 2018 at 14:43 GMT

---

I want to accept responsibility for not doing a good job in broadcasting the API and asking for public comments. I propose that I add a repository aseba-community/aseba-rest-api for the specification, with a CI job to format it properly, and issues for comments.

[MobsyaBot]

Comment by ypiguet-epfl Tuesday Feb 06, 2018 at 14:45 GMT

---

@mbonani I don't have yet frozen development plans. I'm trying to understand what's possible inside aseba-community, or outside with some friendly support (hooks to benefit from existing parts), or outside without support. Of course the limits are fuzzy. I understand very well that the contributors have different needs, priorities and constraints, but sometimes I feel there must be something else. My question about bytecode wasn't gratuitous, it's well within the options we might consider and asebahttp looks like the easiest way to interface with the Thymio, as corroborated by Blockly and Scratch. It isn't a matter of days, but when I see that local variables were discussed in 2012 #111 and I don't see much progress, maybe welcoming more external contributions could be beneficial. For me, clearly PR aren't an option anymore for anything significant.

To be more concrete, should we wish to develop an alternative textual language (let's say with coroutines and less emphasis on events), or an alternative graphical language implementation (let's say web-based), could we do it easily without the risk that Studio, asebahttp or the Thymio firmware locks what's possible now because it's deemed improper or bad for the children?

[MobsyaBot]

Comment by stephanemagnenat Tuesday Feb 06, 2018 at 16:27 GMT

---

I am very much in favour of making the Aseba technology open to new languages, and that is why @davidjsherman and I designed the Symbol Table and Bytecode interface in the HTTP protocol. I also think it makes a lot of sense to do it through the web, and we designed the new Switch with an interactive HTML-based IDE in mind. I also added the websocket wish #626 as a way to bring message-level communication on the web.

Regarding aseba-community and outside, we are working towards letting the continuous integration build pull requests including binary packages. That way, third parties can make a pull request with their own needs and take advantage of our build infrastructure, even if their changes are not planned to be merged into master.

Regarding local variables, I would be very happy to have them. Just they are not trivial to implement, as the necessary support is not required only in the compiler but also in Studio as the variable display tree needs to be synchronized. I am very sensitive to half-implemented features, because currently Aseba is a promise of a consistent experience and I think that it is a strength to keep.

Finally, the reason it went slowly is that there was little dedicated funding for Aseba for years.

[MobsyaBot]

Comment by ypiguet-epfl Monday Feb 12, 2018 at 15:14 GMT

---

New feature:

• Basic support for static files in the http server (option to specify a root directory and simple suffix/mimetype mapping for at least html, css, js, png and other common types) #642

I can provide a patch for asebahttp if it helps.

[MobsyaBot]

Comment by stephanemagnenat Monday Feb 12, 2018 at 16:46 GMT

---

Serving static files makes sense indeed. Note that the basic HTTP example in Dashel does it (see https://github.com/aseba-community/dashel/blob/master/examples/dws.cpp).

[MobsyaBot]

Comment by retornaz Friday Feb 16, 2018 at 17:48 GMT

---

@ypiguet-epfl with a such feature list, you might want to consider using another VM than the aseba one. Such as: micropython ( https://github.com/micropython/micropython/tree/master/ports/pic16bit ) or lua/elua (plain C, would work on pic24).

[MobsyaBot]

Comment by ypiguet-epfl Saturday Feb 17, 2018 at 07:00 GMT

---

Thanks, @retornaz. For the moment I want to keep the stock firmware. From a technical point of view, a lot can still be done by the compiler.

[cor3ntin]

Here is what I propose

• The switch would expose devices (tcp, usb serial, bluetooth, etc ) through either a tcp socket or web socket. It would also provide discovery through both a rest api and zeroconf.
• Mutation of a robot state would only be possible through a persistent connection (tcp, websocket, dbus). That let us handle nicely the "busy" state of a robot and prevent concurrent access while still having the robot visible.
• There would however be a rest API to reset / reboot a robot. Long term this api access should be protected (teacher only)
• The switch will still provide a means to compile a program to bytecode, for web app that do not have a compiler (but you could send bytecode directly too).
• Given that the protocol used by Aseba isn't easy to use from JS, I suggest that we make a protocol based on Flat-buffer. The switch would translate the protocol from flatbuffer (faster than protobuf, has a first-class JS library and generator) to aseba's protocol (and back)
• Thymio v3 would use that new protocol directly.
• The rest api could still expose read-only data such as event streams and variable values
• The whole thing could be driven by a configuration file for port remapping, access restriction, etc

Desktop, mobile and web-based apps can then rely on the switch to handle the tedious discovery/connection aspects and just use a single uniform socket interface. We will then be able to remove dashel from everywhere.

We would still need to add discovery on the new thymio as well as Bluetooth support in vpl mobile for seamless connection from a tablet. On desktop, the switch will be always running ( controlled by the launcher )

@ypiguet-epfl Would that answers to your needs ?

[ypiguet-epfl]

@cor3ntin thanks for this proposal. Some remarks:

• A typical use would be to have a single http server (one port) for both static content (html, js etc.) and rest api for communication with multiple Thymio robots. There should be a way to allow multiple http clients to mutate the node they control (one client for one node), and maybe even multiple clients for the same node if you want a teacher to stop the robots of their pupils.

• I don't have experience with Flat-buffer. Is it simple enough? Can we expect it to still be relevant in, let's say, 10-15 years? It isn't difficult to build binary packets in Javascript, and for web stuff, JSON is extremely common and well supported if marginally less efficient. What would be nice to add to the Aseba communication protocol is some kind of checksum and a way to synchronize on packet boundaries to recover from transmission errors.

[cor3ntin]

Sorry, I forgot to reply

A typical use would be to have a single http server (one port) for both static content (html, js etc.)

Yep. that's actually the trivial part but it's important nonetheless

and rest api for communication with multiple Thymio robots.

Yep

There should be a way to allow multiple http clients to mutate the node they control (one client for one node),

Yep

and maybe even multiple clients for the same node if you want a teacher to stop the robots of their pupils.

Yes, but with restriction. We want:

• The teacher to have full control over all robots - maybe. At the very least they can stop/reset them
• Students should not be able to hijack each others robots
• We may want (I think) ? a read only access to all robots states for everyone
• We may want a way to interact with non-busy (aka non connected through a persistent socket) in order to identify them ( make them make a noise or flash some leds)

I plan to have access restriction later, it's not a priority.

I've started an implementation based on libusb/asio/beast - it should be rather straight forward - but will still keep me busy for a while :)

[cor3ntin]

I've been thinking about it some more and in the end I think it would still be beneficial to have the notion of nodes and to see multiple nodes. So, we would only one server for all nodes on the switch ( well, one server per protocol : tcp, ws, etc ). But, to mutate a robot state, we would first have to explicitly lock / connect to a specific robot. the lock would remain until explicitly released or the connection is closed.

[cor3ntin]

@ypiguet-epfl So, given I'm working on that and that, do you have a list of requirements / wishes for the new switch ? I'd rather incorporates some specific needs you may have from the start

[ypiguet-epfl]

@cor3ntin I think the primary goal should be to be as robust as possible for the current Aseba software and multiple node, and for the protocols to be stable. If Aseba Studio could use the compiler of the switch (by connecting via http instead of the lower-level aseba protocol) instead of its own version, mixing software from multiple origins would be easier, which would be great for tests and for general quality improvement.

Some flexibility for simultaneous access to the same node, including to control it, should be considered for cases like classrooms with young kids where hacking is not a major concern and direct, easy assistance by the teacher is important. It could be an option when starting the switch.

In my wish list, I'm not sure everything belongs to a generic switch, but more to a general-purpose http server; for instance file uploads for server-side storage, or https support. A reverse proxy would probably be a more practical solution.

[cor3ntin]

@ypiguet-epfl robustness is a given. We (at Mobsya) see the switch (which you could also call a device manager) as central. I'm more looking at adapting existing applications to the new switch than the other way around.

I'm hoping that we can, in a reasonable time frame have all existing application depend on the new switch.

Some flexibility for simultaneous access to the same node, including to control it, should be considered for cases like classrooms with young kids where hacking is not a major concern and direct, easy assistance by the teacher is important. It could be an option when starting the switch.

I'm not concerned about hacking, but more about concurrent access to a given device that is poorly handled by thymio. We also don't want students to overwrite each other's program. I'm sure we can figure out something for teacher though. But is there a use case for teacher pushing a new program on a thymio ? That wouldn't use the student. I'm not sure what administrative control a teacher would want beside reset/shutdown/blink the led.

In my wish list, I'm not sure everything belongs to a generic switch, but more to a general-purpose http server; for instance file uploads for server-side storage, or https support. A reverse proxy would probably be a more practical solution.

There will be a (configurable) web server for static content serving.

Storage is probably best left to something else - ideally we would be able to plug into existing school infrastructure, it's a huge can of worms if you ask me. But probably worth discussing about :)

HTTPS support... I'm open to suggestion there. Of course it can (and should) be supported, but there is the issue that self-signed certificates triggers nasty warnings in all major browsers

I'd be tempted to say no ssl for now ? but it's really not ideal...

[davidjsherman]

In my wish list, I'm not sure everything belongs to a generic switch, but more to a general-purpose http server; for instance file uploads for server-side storage, or https support.

In that case, wrapping the Aseba-specific functions as a module for an existing server (nginx, uhttpd) is the smart move.

[cor3ntin]

Current state

• USB connection to a robot is working

• That includes graceful connection / re-connection

• Parsing of the aseba protocol ( using existing code stripped of dashel, as for vpl2)

• Some avahi/bonjour (aka zeroconf) support.

  • Exposes each node in a text record. Each record includes the node id and status - I need to add node name
  • Status include : connected, ready (description received), busy(used by someone else), disconnected

• The switch does implicit, random node-id mapping. The idea being that with N nodes on M devices, it's not useful to use the actual ids ( there is an almost certain risk of collision with the wired thymio)

[cor3ntin]

@ypiguet-epfl I'll probably settle on protobuf as the socket/websocket protocol

Something like: [message_size:uint32][protobuf_payload]

• RequestListOfNodes <- List of nodes -> RequestLockNode(id) <- NodeLocked ( ok / error node not ready) -> RequestDescription <- NodeDescription ( one message, containing the full description)

// Rest of the protocol will be similar with the current one, but I will try to keep things specific to the aseba vm clearly defined so we can add more vm if we want too.

Ok for you ?

[ypiguet-epfl]

@cor3ntin I'd rather have protobuf than flat-buffer. But it isn't self-describing like json, so backward compatibility in future versions will be more complicated to support. Why not starting with json, supported natively in Javascript, to validate the architecture and evaluate its performance, and implement an alternative binary format like protobuf later in case json is too slow or consumes too much bandwidth?

[cor3ntin]

@ypiguet-epfl To be clear, I'm talking about the websocket/socket protocole, HTTP will be json.

I'd like to avoid doing this protocol translation thingy with thymio 3 if I don't have too, So thymio 3 will send the same protocol as the switch, and in embedded context, doing json is unnecessarily cpu heavy.

I'm not too concern about the bandwidth. Alternative could be bor/bjson... but on the plus side, protobuf does the parsing for us, and you can make it backward compatible easily.

[ypiguet-epfl]

Won't http be supported directly by Thymio 3? Will its firmware be developed in c or c++?

[cor3ntin]

@ypiguet-epfl it should, yes - but maybe not the whole protocol (sending all the variables at every step on http/json may not be a good idea) - @mbonani is more qualified to answer, I'm not sure what king of load the cpu will be able to handle.

My guess is that the firmware will be a mix of c/c++ ? That should have no bearing on features tough !

[ypiguet-epfl]

So some json support would be required anyway. For continuous updates, I agree json wouldn't be optimal.

For the language, I asked because Google doesn't seem to support c for protobuf.

[cor3ntin]

There are options

https://github.com/protobuf-c/protobuf-c https://github.com/nanopb/nanopb

[ypiguet-epfl]

Thanks!

[cor3ntin]

@ypiguet-epfl @mbonani Initial protobuf scheme, feedback welcomed https://github.com/cor3ntin/aseba/blob/switch/aseba/protobuf/thymio.proto

[cor3ntin]

@ypiguet-epfl I've been playing with both protobuf and flatbuffer and... fllatbuffer is really much nicer in terms of generated code and footprint so... I really would like to use that if you don't have a strong objection.

[ypiguet-epfl]

I don't have direct experience with either protobuf nor flatbuffer. My only fears are that if someone wants to port it to a new platform (e.g. LabView or Lua), the binary format should be sufficiently well described and not overly complicated to allow a quick implementation for someone reading the specs; and that the format should still make sense in 10-20 years. Adopting a new format would be worthwhile only if the advantages wrt an ad-hoc simple format like the Aseba protocol, and json you want to support anyway on http, are significant.

For which applications do you intend to use the new protocol? From Aseba Studio? Scratch?

[cor3ntin]

@ypiguet-epfl funny you ask, I just made this

[cor3ntin]

@mbonani @cbarraud that's the whole stack from a technical point of view, the switch" ( device manager) being the whole grey box

[cor3ntin]

The TDM was implemented, this issue is no longer relevant