Hello
Username github: retornaz
username svn: retornaz => Philippe Rétornaz
A+
Philippe
Le jeudi 11 août 2011 16:10:46, Stéphane Magnenat a écrit :
> Hello,
>
> I am planning to switch the aseba repository from svn to git using
> github. Please create a github account a
Le jeudi 8 décembre 2011 11:22:22 Stéphane Magnenat a écrit :
> Hello,
>
> Recent discussions related to the use of Aseba/marXbot in research lead
> to the consideration that we need timestamping in messages on TCP.
I strongly suggest to timestamp the message on the source and not on the
receivi
Le jeudi 16 février 2012 15:23:26 Stéphane Magnenat a écrit :
> Hello,
>
> I have added the following things to Aseba:
>
> - math.argbounds() to stdnative library, a function that combines argmin
> and argmax. This breaks "stored in flash bytecode" compatibility because
> the indices of some nati
Hello
I'm developping a prototype of aseba over RF link (802.15.4 frame) and the RF
link has an usable payload of about 110bytes, which is less than the current
maximum packet size.
In order to simplify the protocol I would like to add the following
limitation to the aseba protocol:
- All th
Le mardi 11 septembre 2012 17:53:49 Stéphane Magnenat a écrit :
> Hello,
>
> I do not understand the asymmetry at the level of fragmentation
> handling, what is the root cause?
Let's say we have 20 RF node, each of them sending a packet of size 512. You
need 512*20 bytes to reassemble on the "PC
Hi
> > I) The maximum description packet is 110 bytes
(...)
> > II) The maximum number of argument in an event needs to be limited.
(...)
> > III) The maximum number of variables a node can send.
> > Any objections ?
>
> Yes, of course ;-)
>
> I.That is really limiting. I understand th
Le mercredi 12 septembre 2012 09:07:23 Michael Bonani a écrit :
> Le 11.09.2012 19:55, Philippe Rétornaz a écrit :
> >> more. But for instance on the marXbot Neato scanner, having more and
> >> transmitting less packets to the PC might be useful. Is 32 a hard limit
> &g
Le mercredi 12 septembre 2012 09:47:39 Stéphane Magnenat a écrit :
> Conceptually, we define a "802.15.4 profile" that limits the size of a
> packet coming out of a node to 110 bytes. We remove math.nzseq from
> stdnatives (we put it in an optnatives file for instance, not obeying
> the 802.15.4 pr
> > Ok, fine, but changing the target description breaks the protocol
> > compatibility with previous versions. We have to keep the backward
> > compatibility (at least for Thymio, which is the most used aseba target).
> > Any idea on how to do this cleanly ?
>
> There is a field for protocol ver
> >
> > Any proposition? For now, it works well with the patch in Dashel...
>
> As there are other Dashel users than Aseba (sensefly, as far as I know),
> I propose not to put this code into Dashel. I propose to put the
> protocol-agnostic part into Dashel (so that we can use CAN0 along with a
>
>
> > So you mean that now an aseba node should dynamically change the way it
> > sends the description based on the GetDescription packet ?
>
> Yes, I agree that it adds (a tiny bit of) complexity, but that's the
> price for clean backward compatibility.
Do not underestimate the potential bugs
Le vendredi 14 septembre 2012 11:48:58 Stéphane Magnenat a écrit :
> Hello,
>
> I will think about it before answering, however, some a small addition:
> > Cons:
> > - Instead of an explicit MTU, it's implicit.
>
> If you do not have a matching version of studio/compiler, you will
> accept/genera
Le vendredi 14 septembre 2012 11:54:07 Stéphane Magnenat a écrit :
> Hello,
>
> One more question Philippe: at some point you wanted to add more
> informations about routing, etc. We decided to put these in the
> bytecode, so for these there will be no change in the target description
> or will th
Le vendredi 14 septembre 2012 12:10:34 Stéphane Magnenat a écrit :
> Hello,
>
> Another solution would be to deduce the maximum event size from the
> length of "event.args", and use the same bound for sending and receiving
> events. It has one disadvantage in challenge, because we want to forbid
>
Hi
>
> The registration mechanism is simple, call:
>Dashel::streamTypeRegistry.reg("NAME", &createInstance);
> Where NAME is the protocol name, and STREAM_CLASS the C++ class of your
> new stream. You can have a look at the bottom of dashel-posix.cpp for
> inspiration.
>
Thanks, this is a f
Le mardi 18 septembre 2012 17:45:04 Stéphane Magnenat a écrit :
> > Tell me if you need something else,
>
> In particular, if you need DisconnectableStream or SocketStream
> available in dashel-posix.h
Mmm, I don't think so, I will keep you updated.
Thanks !
Philippe
Le mardi 18 septembre 2012 17:52:38 Stéphane Magnenat a écrit :
> On 18/09/12 17:49, Philippe Rétornaz wrote:
> > Le mardi 18 septembre 2012 17:45:04 Stéphane Magnenat a écrit :
> >>> Tell me if you need something else,
> >>
> >> In particular, if you ne
Hi
> I have applied your patch, tell me if you need something else.
It works fine, you can have a look at the code in
https://github.com/retornaz/aseba/commits/socketcan
Successfully tested on an omap3 board with a sja1000 chip !
Philippe
___
Aseba
Le mercredi 19 septembre 2012 20:58:07 Stéphane Magnenat a écrit :
> On 19/09/12 14:21, Philippe Rétornaz wrote:
> > Hi
> >
> >> I have applied your patch, tell me if you need something else.
> >
> > It works fine, you can have a look at the code in
> >
Hi
In the aseba source code, there is the following definitions:
ASEBA_MAX_PACKET_SIZE = 512+6 /*!< maximum size an aseba packet is allowed
to be (in byte), including all its aseba headers, but not the source and the
length */
#define ASEBA_MAX_EVENT_ARG_SIZE ((ASEBA_MAX_PACKET_SIZE-6)/2)
Le lundi 1 octobre 2012 09:48:06 Stéphane Magnenat a écrit :
> On 10/01/2012 02:47 AM, Philippe Rétornaz wrote:
> > Hi
> >
> > In the aseba source code, there is the following definitions:
> >
> >
> > ASEBA_MAX_PACKET_SIZE = 512+6 /*!< maximum siz
Le mardi 2 octobre 2012 11:12:12 Stéphane Magnenat a écrit :
> >> You are correct, there is an inconsistency. Looking at the code, I
> >> reached the conclusion that the comment is right but the define is
> >> wrong: ASEBA_MAX_PACKET_SIZE, as it is thought currently, should be
> >> 512+2. I propose
Hi
> I do not like this solution because it keeps old dirty hacks in.
Man, you have to stop this insanity. We have to keep the binary
compatibility, like it or not, we have to. So-called "specifications"
(512 packet size, etc ..) are here only to help understand the code, but
the *REAL* speci
Hi
To be clear: I was ranting (loudly ...) because I really wanted to make
clear the we should not break, nor plan to break the binary protocol in
the current aseba version just because it's "not pretty". If we break
the protocol it should be because we are forced to. In previous
discussions
Hi
The internal achitecture of aseba is explainded in the following
scientific papers:
* ASEBA: A Modular Architecture for Event-Based Control of Complex Robots
Stéphane Magnenat, Philippe Rétornaz, Michael Bonani, Valentin
Longchamp, and Francesco Mondada. In IEEE/ASME Transactions on
Le 05/02/2013 09:57, Florian Vaussard a écrit :
Hello,
On 02/04/2013 02:14 PM, Michael Bonani wrote:
Hi,
I test the latest package of nightly built release branch 1st
February some comments:
The falsher is cool and it works, I try several time and I could
flash in any-sense also with crashed
Hi
On the emulator, I have a display bug with pixmap, that needs further
investigations, and they widgets themed using stylesheets are not
properly displayed, probably some sizes that interact badly with the
HiDPI mode of Qt.
http://community.kde.org/Necessitas/FAQ
Last point, there is a way
Hi
We could always disable the view of hidden stuff when starting Studio.
It's a very good idea, let's do this.
I know that ideally the firmware updater should check such the version,
but until someone has the time to implement this feature, shouldn't we
remove this message and hope that u
Le 05/12/2013 09:24, Stéphane Magnenat a écrit :
I think that Philippe will agree with me: updating the firmware
is _not_ a normal operation. It has always been dangerous with
embedded systems. Just ask iApple about the last update that they
made...
Yet most users will do it.
You're wrong on
Le 05/12/2013 09:29, Stéphane Magnenat a écrit :
We could always disable the view of hidden stuff when starting
Studio.
It's a very good idea, let's do this.
I do not agree, I believe we should provide an IDE that is convenient
to use for both types of users : - normal users, who should never
In the context of adding an augmented reality live inspector to VPL [1],
the VPL code must generate Aseba events representing an event-actions
set, whose size depends on the content of the set. The problem is that
currently the "emit" keyword takes named events, which have a
pre-defined size. The
Le 06/08/2014 11:23, Stéphane Magnenat a écrit :
Make sure that this function:
1) Send a statically defined event ID 2) The ID is a valid user ID
[0-0x8000[ 3) The size of the event data is [0-31] words
With thoses limitations we should not be able to crash any robots.
In general I agree, alt
Le 06/08/2014 11:52, Stéphane Magnenat a écrit :
Hi,
If you want to be able to check (2) efficiently (at compilation
time) it does imply (1).
So if I understand well (please correct me if I am wrong), you
suggest to only allow to send events whose id is a constant and
corresponds to a named e
33 matches
Mail list logo
