Mindboards

I have released the Robot Navigation software for the EV3. This program implements simple Odometry and Gyro enhanced position estimation. It includes basic robot control over WiFi capabilities. The program was written in Object Oriented C++. I have added instructions for Linux and Windows users.
http://www.robotnav.com/software/

Very nice!

You seem to be using the kernel interface directly.
Do you have any plans to release a more general library?
I'm really having trouble with IIC for the US sensor.

I am not planning to create a general library. I think the code I wrote can be easily incorporated directly in usable applications, as shown in the Robot Navigation program. On the other hand, I have continued adding information that would help others creating functions as needed (http://www.robotnav.com/encapsulating-code/).
About the US sensor. There is a discussion about the NXT US (I2C) sensor at: https://sourceforge.net/apps/phpbb/mind ... =30#p17658. I have not tested the EV3 (RS232) version of the US sensor.

that's really a pity, because I don't understand your low level code and anything of the file read/write thing for sensors and motors and how to drop all the global defs and make it usable by passing port and setting parameters to the calling functions (although I tried) .
IMO this C code is stuff for kernel hackers and professional computer programmers (to my guess even <1% of the overall EV3 users).
"Daily computer users" with preference for text-based programming like me (to my guess 1/3 of the EV3 users) will need APIs like NQ/XC and/or RobotC doing without make or link or object or project or obfuscated file r/w stuff - or they will sacrifice it immediately, regrettably.
And the rest of about 2/3 of the overall EV3 audience who have just been programming by those Lego icons will be deterred in such a degree that they won't even start to try it out.

(BTW, it was quite easy for me as I once wrote NXC or RobotC code for a map-and-explore-and-navigation-robot fusioning compass, gyro, and odometry data, and additionally I already have the code for a bug2 to bypass incidental obstacles plus an astar for up to a 40x40 field map (limited only by available NXT memory) to drive guided like by a car navigation system - but had to give up because of the lack of NXT memory and the lack of daisy-chaining- and data-communication-features for several bricks by NXC.)

So finally for the ev3 there should exist 1 header for sensors (ALL (!) sensors !), 1 header for motors, 1 header for on-brick-stuff (Screen, Btn, LED, Sound, BT) - that's it.
But if one currently already despairs with simple sensor polling using gpp C by BCC or Eclipse - what about daisy chaining and data communication for several bricks?

BTW, are there any rumors about RobotC 4.0?

I wrote more details about the Robot Navigation software that I hope helps understating it. The software now also includes a high level Control class that implements self-homing control capabilities. There is a video of the program in action:
http://www.robotnav.com/software/

I have added support in the Robot Navigation software to the Lego EV3 gyroscope. This can be enabled by selecting the LegoGyro class in the main program. The results may not be very accurate with this gyro. However, users with some experience in Kalman filtering or sensor fusion could add correction algorithms to the gyro output before it is used by the positioning system.
http://www.robotnav.com/software/