Bounty for complete EV3 C/C++ API

[HaWe]

ps,
as I already posted on fb to this issue:

...anyway what is involved or not or whatever - I prefer BCC and appreciate that it's open source.
I would even appreciate it, John, if you started a crowd funding project for BCC/C and all it's C lib modules and features which would be wishful (and well ... actually ... if you yet needed some tipps...)^^

[afanofosc]

Let's start with the API for outputs. Are you satisfied with the state of the latest of my API versions? I can put the NXC doxygen headers on that code and generate documentation for it.

What about an API for sounds, LCD, button input, and LED outputs? All of those are in place, with the exception that the LCD API needs some additional work to provide a few more NXC-like high level API routines as well as fully implementing support for the NXT's RIC file format. Can you give me some feedback regarding your satisfaction with these API functions?

After looking over Xander's input code, I will start from scratch there and see what I can get working over the next few days. My plan will be to create functions as close to those found in the NXC API as possible. See

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

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

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

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

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

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

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

As you can see from the above URLs this is no small task.

John Hansen

[tcwan]

Let's start with the API for outputs. Are you satisfied with the state of the latest of my API versions? I can put the NXC doxygen headers on that code and generate documentation for it.

What about an API for sounds, LCD, button input, and LED outputs? All of those are in place, with the exception that the LCD API needs some additional work to provide a few more NXC-like high level API routines as well as fully implementing support for the NXT's RIC file format. Can you give me some feedback regarding your satisfaction with these API functions?

After looking over Xander's input code, I will start from scratch there and see what I can get working over the next few days. My plan will be to create functions as close to those found in the NXC API as possible. See

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

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

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

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

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

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

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

As you can see from the above URLs this is no small task.

John Hansen

I feel that there should be some mid-level API that is applicable to all sensors, and then a high level sensor-type specific API (which may apply to the same type of sensor from different vendors?) would be ideal. Otherwise, supporting a sensor device from a different vendor would require writing device specific user code.

For example,

Code: Select all

Sensor *OpenSensor(Port, SENSORTYPE)
InitSensor(Sensor *)
ResetSensor(Sensor *)
CloseSensor(Sensor *)
ReadSensor(Sensor *, void *)
...

would be what I mean by mid-level API (as opposed to the low level kernel driver API using fopen(), fclose(), sysctl(), etc.).
These functions are generic to all sensors to provide a consistent interface for accessing the devices (similar to the File I/O routines in C).
Whereas, for more specific functions, users would be able to make use of functions such as:

Code: Select all

int GetColorRaw(Sensor *);
COLOR GetColorEnum(Sensor *);
...

targeting a color sensor. Unfortunately support for new color sensor from a different vendor (for example) would require modifying each of these mid level and high level API routines for a given sensor type since C does not support virtual methods in the language.

Edit: New sensor support affects both Mid and High level API routines
Edit2: virtual method dispatch can be simulation in C using Function Tables but that would incur a performance penalty for every function call. In addition, the table of function calls would still need to be maintained and updated manually.

[HaWe]

I already sent John a PM about just this issue, but it was about the high-level APIs, so just for completion:

My proposal was, e.g. for a raw ADC sensor, or a Color Sensor of either kind, or an acceleration sensor there also could be used commands sort of

SetSensor(char port, SensorADCraw )

SetSensor(char port, SensorColorEV3)
SetSensor(char port, SensorColorNXT20)
SetSensor(char port, SensorColorHTv1)
SetSensor(char port, SensorColorHTv2)

SetSensor(char port, SensorAccelHT)


and for reading we would need then just 1 universal command for either sensor:

GetSensor(char port, int &values[]) or instead maybe ReadSensor(char port, int &values[])
// containing an ADC raw value (values[0] ) when port was set to ADCraw
// - or - r,g,b,colorID,... (values[0...3...] ) accordingly when port was set to a color sensor depending on specific sensor value adjustments
// - or - x,y,z acceleration values (values[0,1,2]) when port was set to a acceleration sensor

[pepijndevos]

In my limitted testing, I'm quite happy with the ouput API (when it doesn't panic the kernel )
I have not yet tested rotating multiple motors synchronously at different speeds, but I assume it is properly supported.
I have not seen anything like absolute position regulation, but that's not too important.

As tcwan said, a midlevel API that more directly exposes the hardware instead of providing NXC abstractions would be valuable, but maybe not essential.

Frankly, I don't care about sound, buttons, LCD and NXC compatability much. All that matters to me is a simple API for motors and sensors. But as Doc noted elsewhere, a way to printf to the screen would be sweet, basicaly just using it as a text console.

I'm looking forward to what you come up with for sensors over the comming days.

I agree supporting all third-party sensors will be a lot of work. I'll just note that I only required support for the standard EV3 sensors.

[HaWe]

IMO, absolute postion control is absolutely necessary, IMO wishful if we had it like already described here:
https://sourceforge.net/apps/phpbb/mind ... 862#p16646
or already implemented for NXC (!) here:
https://sourceforge.net/apps/phpbb/mind ... f=3&t=1850
the latter implementation demands featuring preemptive multitasking.

Most ev3 users already got NXT parts (sensors, multiplexers even of 3rd party companies) which were too good to be scrapped.

[HaWe]

are there any plans about the release date of a sensor API ?

[devirex]

Hello,

I'm playing around with the EVC Api. I've written a thread which prints the position of motor A [MotorTachoCount(OUT_A)] every 100ms. Also there are two functions which should do the same (spin motor 1 second and don't reset the count).

Code:

Code: Select all

#includes ....

void tsDrive(int Power){
      printf("Drive1 \n");
      OnFwdEx(OUT_A, Power, RESET_NONE);
      Wait(1000);
      OffEx(OUT_A, RESET_NONE);
      printf("Drive1 End \n");
}

void tsDrive2(int Power){
     printf("Drive2 \n");
     SetPower(OUT_A, Power);
     Fwd(OUT_A);
     Wait(1000);
     Off(OUT_A);
     printf("Drive2 End \n");
}

int main(){
  tsDrive2(30);
  Wait(1000);
  tsDrive(30);
  Wait(1000);
  tsDrive2(30);
}

But the output looks like this:

Code: Select all

root@EV3:/mnt/ramdisk/prjs# ./test
Drive2
Position: 1
Position: 22
Position: 53
Position: 83
Position: 115
Position: 146
Position: 178
Position: 209
Position: 240
Position: 268                    
Drive2 End                           // Everything ok here 
Position: 2                           //But why did Off(OUT_A) reset the TachoCount?
Position: 1
Position: 0
Position: 0
Position: 0
Position: 0
Position: 0
Position: 0
Position: 0
Position: 0
Drive1                                 // RESET_NONE is set in OnFwd but why is position always 0 or 1 
Position: 0
Position: 0
Position: 1
Position: 0
Position: 0
Position: 1
Position: 1
Position: 0
Position: 0
Position: 1
Position: 0
Drive1 End                        
Position: 4                          //No idea what is going on here the motor is not spinning
Position: -1
Position: 0
Position: 0
Position: 0
Position: 0
Position: 0
Position: 0
Position: 0
Position: 0
Drive2                                 //After OffEx(OUT_A, RESET_NONE) function Drive2 is not working anymore. No motor spinning.
Position: 0
Position: 0
Position: 0
Position: 0
Position: 0
Position: 0
Position: 0
Position: 0
Position: 0
Position: 0
Drive2 End

Maybe there is another way to get the Motors spinning and not to reset the motor tacho count?

[HaWe]

hi,
this thread is about a project to set up a complete C API which is still missing some features, lik e.g., a sensor API and a daisy chaining API and other things which still don't exist.
Would you mind to open a complete new thread for programming issues or bugs?
thank you!

:)

[HaWe]

BTW, @ Xander:

After looking over Xander's input code, ...
John Hansen

...what about your input code...?
Would you please be so kind and publish it as John apperently abandoned his work on it ?