EV3 I/O library

[jpouellet]

Yesterday, after months of waiting, I finally got my hands on the hardware.

There is great need for a library for the EV3 with a decent API that wraps all the hardware-specific stuff people would want to do in a nice convenient library that people either just link with or create bindings for in their preferred language.

Xander briefly mentioned that such an effort might be in-progress in his talk at ohm 2013; if that's the case, I'd like to avoid duplicated effort.

Is anybody already working one? If so, care to share? If not, I'll start.

[afanofosc]

My preference would be to produce a standard API library which I think could be called brickOS/EV3, i.e., after the original brickOS for the RCX. My approach so far to this API has been to model the functions after the NXC API so that in C/C++ and Pascal you could write code that looks a lot like NXC code and have it run natively as an arm-linux app. If you have been following my progress with respect to BricxCC support for the EV3 you may have seen some videos I posted on YouTube showing off some bits of the API that I have working already. Of course, a higher level object oriented API for C++ and Pascal would be nice to have as well and there would be no reason to base that off of NXC API function names.

In any case, what I have working either completely or partially is support for the EV3 buttons, the EV3 LEDs, the EV3 LCD screen, and the EV3 motors. Xander has some API functions working for EV3 sensors, which I have not yet merged into my API library. I have all of these working both in C and Pascal except for the LCD screen support which is currently ahead on the C/C++ side of things.

My work can be found in the BricxCC test releases folder at http://bricxcc.sourceforge.net/test_releases/. Look here for lms_api.zip and lms_api_pascal.zip. Also have a look at readme_1st.txt for instructions regarding how to configure your system so that BricxCC can work with the CodeSourcery Lite cross compiler.

In case somebody here is not completely aware, BricxCC currently supports compiling, downloading, and running native arm-linux executables on the EV3. There are a lot of things with respect to this support that need work/improvement but I used BricxCC to compile and download the snapshot binary which is what enables BricxCC's Screen Capture tool for the EV3 and you can launch that and other arm-linux binaries via the Explorer tool as well as via the Run toolbar button/menu option.

David Gilday has used the libev3.so shared library along with his C++ code to build his latest cube solver. To successfully run C++ binaries on the EV3 you will need to configure the runtime path via an LD switch to look in /media/card/lib in addition to the standard library paths configured on the EV3 and you will need to copy the C++ shared runtime library from the CodeSourcery folder to a lib folder at the root of your micro SD card which you then would place in your EV3. A future test release of BricxCC will update the makefile template to include the required flags to enable this - and I may try to automate the shared library download.

John Hansen

[HaWe]

John,
please make your API more C-identical (than it was formerly done for NXC) by keywords and commands which are already C standard commands in ANSI syntax and/or widely used C-libraries (e.g., stdio.h, stdlib.h, strings.h, math.h ).
E.g., sleep() instead of Wait(), beep() instead of PlayTone(), strlen() instead of StrLen().
There always should be preferences for ANSI compatibility, aliases like for NQC of course could be defined via #define macros (not other way round in order to be able to pass expressions to standard C functions).

E.g., screen output normally uses (0,0) as the most upper left point of the screen, so does Delphi/Pascal IIRC, and RobotC also does it this way (AFAIK there actually is no ANSI std for this but for graph libs of Borland or MS C++, and RobotC - no idea about how C# or even Java handle this issue).

E.g., absolute motor position control and PID control are much better resolved by RobotC API functions than in NXC functions (the whole output field is really weird and extremely hard to understand and to handle).

Compatibility to existing standards and popular/convenient solutions should really be top priority in every respect.

[afanofosc]

Doc,

All the standard C library functions will be available via the standard C libraries. My EV3 API functions will not have anything to do with those. I don't plan on writing a "printf" function that can draw to the LCD. Instead, I plan on having a TextOut and a NumOut function. I am far more interested in an API that makes it easy to transition between VM programs and native programs than I am in creating an API layer that is named like the standard C API functions but act differently (i.e., draw to the LCD instead of stdout).

At the moment the NQC and NXC APIs are the standard APIs for programming LEGO MINDSTORMS robots in C (from my perspective).

John Hansen

[tabbycatrobots]

I'll bravely jump in with my 2 cents about a 'C' for EV3. I have megabytes of NXC code for my NXT robots -
functions, libraries, BT comms, RS485 comms, sensor code, multitasking code fragments, header files, etc.
I hope to be able to easily reuse this code for my EV3 robots. So for me, the ideal EV3 'C' is NXC with support
for the new sensors, and USB comms to replace RS485 comms for hardwired P-Brick to P-Brick communication.
I have several 2 P-Brick robots where I want to add new features, so if I can simply replace the 2 NXTs with
2 EV3s I get 2 additional motor ports, 2 additional sensor ports (no RS485 comms), without days of translating
code from one version of 'C' to another version of 'C', (and adding bugs).
I suspect there are many more robot builders who would like a simple way to reuse their NXC code in
an EV3 P-Brick.
Well, maybe this is 3 cents worth of opinion rather than 2 cents. Thanks for considering.
Howard

[HaWe]

John,
your print example is a really good one.
Having 1 single-parameter TextOut function which only can print 1 string at the screen and additionally 1 extra NumOut function which can print just 1 number at the screen is good for backwards compatibility, but on the long run it's like driving a Bugatti Veyron in reverse gear with the handbrake and the footbrake on.
Instead, 1 universally usable command like printfxy which can print multiple parameters at any point of the screen via function overloading , just like printf can (1 or 2 or 3 or how many of them will currently be needed) and supporting multilple parameter types (like strings and numbers at the same function call, if desirable: all at once) and maybe even by different font types: that will meet the new opportunities of the new C compiler, and that would fully exploit the given possibilities of the new language features.

In this special printf issue I'm thinking of something like
printfxy( 0, 20, "alpha-beta search");
printfxy( 0, 30, "move number: %4d", count);
printfxy( 0, 40, "%2d ply, %9d searched, %6d by (%2x,%2x)\n",d-1,N,m,X,Y&0x77);

similar it's about sensor initialization and reading:
instead of legions of different sensor read and set commands for all existing single sensors (like in NXC) it would be better to have 1 universal GetSensor or SetSensor command to pass the sensor type/mode to (it already was this way in NQC and still it's roughly similar in Java and in RobotC ) .

( from time to time it might not be wrong to look outside the box)

[afanofosc]

I guess you have not looked at SetSensor in the NXC API which works exactly like NQC's SetSensor API functions?

http://bricxcc.sourceforge.net/nbc/nxcd ... c028b.html

http://bricxcc.sourceforge.net/nbc/nxcd ... modes.html

There is no such thing as GetSensor in NQC or in RobotC. There is no such thing as SetSensor in RobotC.

John Hansen

[HaWe]

you're right, I didn't look to the API because I didn't expect that there already was anything really finished yet, but I'm glad to see that the SetSensor command has revived, that it's really somewhat like I proposed and that it's no longer just NXC-like.

By GetSensor I meant nothing else than just the formerly
Sensor(port)
but providing an array of sensor values to be returned like
int * sensval[] GetSensor(int port)
or
(void) GetSensor ( int * sensval[], int port,)
or
(void) GetSensor ( int * sensval[], int port, int NetBrickID)
or what ever instead of SensorTouch(port) and SensorUS(port) and SensorLightActive(port) and SensorRaw(port)

So if there's plugged to port S1 a touch sensor, to port S2 a 3D Accelerometer and to port S3 a PCF8574 muxer this design would enable to poll by
GetSensor(S1) <=> retrieve just the touch sensor value
GetSensor(S2) <=> automatically retrieve an array of all 3D acceleration values all at once
GetSensor(S3) <=> automatically retrieve an array of all 8 muxer values all at once.

(I don't recall exactly how RobotC was once polling sensor values at least in the early releases, IIRC it was reading sort of a similar array (provided by the API) by a port index number instead of a function call passing the port number), and I'm quite sure that there was kind of set sensor command additionally to that horrible automatic "RobotC configuration wizzard" which I always disabled and erased - but I might remember wrong.)

why I'm posting this:
IMO the EV3 C/Linux thing is currently at a crossroad like many other companies and their products before:
e.g., where would the Apple Computers company be today, where were all the Macs, MacBooks and iPads if the company had stuck to 6502 backwards compatibility in the early 1980s (regardless if there existed many users who cried out "please Mr. Jobs, I got so many old programs running on my Apple II, please make no Macintosh thing which won't support all that software any more") ?

[mrblp]

Hello all,

I just want to thank you John to commit yourself to the compatibility of ncq / nxc / evc And of course for the efford you put into this project at all! As long as the robots are doing nearly the same operations that is a straight forward way. Even a ivy bridge cpu has an i386 / virtual mode, hasn't it?

doc-helmut I like the idea of making an ANSI C library for the EV3 hardware so you can use printf to write things on the display and so on. The great thing about the EV3 is - it is even more like a computer than the NXT; it has the linux base so I am sure YOU can make this easily with your knowledge. That would be perhaps the successor of http://lejos-osek.sourceforge.net/.

The great thing of an open plattform is the availability of alternatives to the original. In this case it also seems very easy to customize it.

So feel free to do it

[HaWe]

as you addressed me personally:
I am no Linux programmer, I didn't work with any Linux PC ever, I have no idea of this operating system and it's commands, I am no hardware programmer, I never learned anything about information technologies or computer science, and I never used gcc or gpp or eclipse so far (and probably never will use this monster), I am just a simple API-end-user who uses a C-based programming language instead of Lego icons. From my point of view, programming an API would be more the business of people who have learned and/or studied programming and computer science.

IIRC, I was the 1st one who posted the idea of establishing a real ANSI C compiler for Linux executables at all, just in the moment as it has been published that the EV3 will be Linux-based; but this was only a rough idea not knowing anything about the details. Indeed at that time many people were very sceptical if that would be realizable at all (even Java developers, and even Xander doubted that at the beginning) . So of course I'm glad that John made it possible.
And so my ideas should not lessen this success - it's only written from my personal "logical and intuitive" point of view.
And knowing at least the basics about C syntax of course it's clear to me when having an ANSI C99 compiler that printf can be used, the example given above was just about a new "forward-looking" universal multi-variable-multi-format printfxy (capable to pass expressions to it) instead of backwards-compatible TextOut and NumOut.