I'm thinking in something like:
https://decibel.ni.com/content/groups/labview-interface-for-arduino
http://vishots.com/getting-started-with-the-labview-interface-for-arduino/
Would anyone support me?
Francisco
I'm thinking in something like:
https://decibel.ni.com/content/groups/labview-interface-for-arduino
http://vishots.com/getting-started-with-the-labview-interface-for-arduino/
Would anyone support me?
Francisco
While we would be happy to host relevant information/code on how to use Labview with the Aseba technology, we are not interested in doing any work on our side for Labview compatibility as Labview is not an open-source technology.
I strongly support this attitude; open-source technology is the way to go for soft- and hardware! Support and reliability is what should be payed for… :)
Having said that I still would like to insist in LabView - or even better - general support for all programming languages other than (just) aseba. What about e.g. python (as mentioned
here already) which is open-source…?! To make this clear I am working on a LV integration but only in a way portable to any language which includes
open-source. In my opinion this is just 1 task! :)
Starting with (Aseba-thymio) Thymio (II) LabView drivers and the discussions hereafter I tried hard to get a very simple and basic interface. What I have in mind is a serial interface (which can be used from any language). I was able to get it running after I found thymioreflexpapier as well as asebaswitchremap and desperately tried to write a popen interface using pipes to asebaswitch (but I need the local events form thymio and can just dump the global ones) which then unhid the serial port settings of ThymioII to me:
After knowing them and using Wireshark (with USBPcap) I was able to reverse engineer the initial communication of AsebaStudio. It sends 4 times 2 bytes (word) with ~1ms delay in between, in hex:
02 00
00 00
00 A0
04 00
then I was rewarded with 12 packets of bytes in return, resulting in a total of 4549 bytes. This string contains e.g. "thymio-II" and a lot of other useful looking data. As it appears to me afterwards AsebaStudio is essentially just updating values with some small and simple blocks of data but I am not that far yet.
Generally my concept is given in the following, but I will need support for this:
May be there are other interesting approaches, like e.g. mentioned in Re: (Aseba-dev) aseba/thymio ii communication/command protocol specification but to be honest; I do not understand whether D-Bus, CAN or something else would be of big value here. I just try to keep it simple but if somebody explains the advantages to me I will happily support other approaches also.
By the way I would like to release all my findings and code if possible - I could do it e.g. on sf.net but I don't know whether this is appropriate? May be here would be better?!
What I would love to see here (and may be is a MUST HAVE) is a documentation of those basic protocols mentioned before. I am thinking of something by far simpler than the papers mentioned above. Just like I did:
essentially similar like in Programming Interface but more technical and detailed. I am willing to help writing this stuff - but I definitely need support for this… ;)
Greetings, thanks for all support so far (!!) and good job with the ThymioII !
Ursin Solèr
Mwwwaahahaha, reverse engineering an open source protocol. I'm impressed !
Read the source code, it's the documentation. The protocol on the PC side is plain C++. The protocol on the Thymio side is plain C. In the aforementioned mail I've put pointer on where to look in order to understand it.
Btw, you clearly do not understand what's a shared object (.dll/.so) and how to write one, so please do your homework before ranting/sending private emails to developers about it.
Here are some info about your remarks:
We have tcp/ip support.
You have the source code + articles + me saying the tcp/ip or serial protocol is just a serialisation of the others one. You have ALL THE INFO NEEDED.
sensible moderation note: please remain polite AND curteous. This is a public forum
Dear Ursin,
The Aseba protocol consists of packets exchanged over a transport that is assumed to keep data in order and not to loose any of them. These transports (for instance UART or TCP/IP) are abstracted by Dashel (http://home.gna.org/dashel/). On top of Dashel, the message serialization library (in common/msg/ subdirectory of the source code) provides the logic to serialize/de-serialize C++ objects into byte streams. These objects are used by the client applications such as asebastudio or asebadump. It is true that this protocol is only documented by the source code and the doxygen documentation in it. I do not have time right now, but as soon as possible I will make an example of a client using it to access an Aseba node. In the mean time, you can have a look at switches/medulla directory in the source tree, as it contains an Aseba/D-Bus bridge which should give an example of any feature your LabView interface might require.
Regarding the example; may be this python example could be a starting point?
Greetings
As I explained in a private email communication, the Aseba protocol is message-based. Here I will copy the content of the mail for archiving purpose:
The Aseba protocol is based on messages, and the place to see these messages is the directory common/msg in the source tree. The best place to start understanding it is Message::serialize() in msg.cpp:138. You will see that the Message superclass (parent of all Aseba messages) will use the virtual method serializeSpecific() to request subclasses to add their data to the rawData vector through the templatized add<T>() methods. Then, it will write on the destination stream the following informations:
Words are 16-bit integers in little endian. Message types are defined in common/consts.h in the source tree (prefixed with ASEBA_MESSAGE_).
The add<T>() method accepts any basic scalar type, for which swapEndianCopy<T>() is defined, plus strings (limited to 255 characters as the length is written as one unsigned byte in front of the string (Pascal-style string)). You can see the code of add in msg.cpp:214. swapEndianCopy<T>() (defined in endian.h) uses a ByteSwapper class on big-endian architectures (not common nowadays) that will only depends on the size of the scalar type.
Note that the whole point of the common/msg library is to abstract the low-level details (serial protocol) so that users of Aseba can use a more convenient C++ interface.
Thanks for this summary! As it was very helpful for me - I am sure it will also be for others - therefore thanks for archiving this here!
Following to the python examples I was finally able to implement LV-serial. Now despite the fact that it is still in very early stage (can retrieve 'GetDescription' and 'GetValues' messages only at the moment), it is able to recieve sensor values from Thymio2 by serial port! I am quite happy about that! ;)) Thanks for all help I got!!
I have to mention that also the chosen LabView implementation might not be ideal (or IS not ideal since it is not the same design as aseba source). But it is a starting point for a working LabView implementation - every improvement is very welcome - please contribute! ;)
Important to mention is that asebastudio has to be installed in order to get the needed Thymio USB port drivers.
Again thanks for all your support!!