This only works if a sensor has a single returned value. This is not the case for many sensors including:
* Two axis gyros that return two 16-bit values
* Cameras that have many, many returned values.
* Two axis accelerometers with two 16-bit values
* Etc.

There doesn't seem to be a nice clean way to provide a common end user interface to these!

One way this is handled is by the hardware manufacturers. For example, the HiTechnic color sensor can be configured in "basic" mode where it behaves similar to a ultrasonic sensor. It returns a single value (range 0 to 16). But it has a more powerful mode where it returns 3-different 16-bit values for the three different color components.

The I2C protocoll is much too complicate to handle. This really needs to be simplified a lot.
Why can't you implement a sensor protocol that allows some easy access to all sensors, equal if I/O, analog, or I2C (see above)?

As you said yourself, RobotC has been designed for beginners and novices.
An I2C protocoll is far too a low hardware- and bit-shifting level and appears to be more suitable for kind of professional embedded C programmers.

Novices and beginners need something like that 1 sensor block in NXT-G, but transfered to a convenient script language:

You're absolutely right! Individual programmers should not have to write drivers for each 3rd party sensor that they own.

The ROBOTC sample program includes drivers for a few of the 3rd party sensors. I had hoped that the sensor manufacturers would use these samples to write drivers in ROBOTC code the same way they have written NXT-G blocks; unfortunately they haven't!

The NXT-G blocks for 3rd party sensors are in fact complicated subroutines that "compile" into many instructions of the NXT-G virtual machine. These are masked from the end user.

THe sample drivers for ROBOTC behave similarly. They are code written in ROBOTC contained in a separate #include file. They usually have a simple interface which is all the end user needs to know about.

In fact, the simple sensors with a single value can be accessed with the "SensorValue[xx]" variable used throughout ROBOTC since the driver code is allowed to write to this value.

As time permits, additinoal driver files will be added to ROBOTC.

Wed Mar 19, 2008 5:32 am

Ford Prefect

Guru

Joined: Sat Mar 01, 2008 12:52 pmPosts: 1030

Dick Swan wrote:

You're absolutely right! Individual programmers should not have to write drivers for each 3rd party sensor that they own.(...) I had hoped that the sensor manufacturers would use these samples to write drivers in ROBOTC code the same way they have written NXT-G blocks; unfortunately they haven't!

That's really poor!From the view of the customers, it seems that completely developed RobotC drivers are available just like NXT-G sensor blocks, because the manufacturers (Mindsensors, Hitechnic) picture your "RobotC label" on their websites.That every single programmer has to write his own routines is unreasonably and impudently (babelfish English, sorry ).Why don't you forbid them to show your trademark label, if they they don't hold, what they promise!?

Dick Swan wrote:

As time permits, additional driver files will be added to ROBOTC.

I'll gladly wait for it... Maybe we can start meanwhile publishing such private written drivers, if the code will be checked by you (just as I started with the HT Compass driver, see my posting in "NXT Programming: Tips for Beginning with ROBOTC")

You're absolutely right! Maybe we can start meanwhile publishing such private written drivers, if the code had been checked by you (just as I started with the HT Compass driver, see my posting in "NXT Programming: Tips for Beginning with ROBOTC")

I'm all for user contributions.

Did you notice that the compass sensor driver is one of the samples included with ROBOTC? There's two files -- a driver file and a sample of its use.

Wed Mar 19, 2008 6:09 am

Ford Prefect

Guru

Joined: Sat Mar 01, 2008 12:52 pmPosts: 1030

no, I didn't!
I probably e-mailed 20 times to Hitechnic, cause with the drivers I found I didn't get it to work.
Could you plz check "my" code and compare it with yours (especially the calibrating part of the routine)?
If the code is the same, I will delete my post.

I meanwhile found some compass code of you (I think), but
- it's much too complicated to handle
- it lets you not calibrate the sensor.
- some endless tasks are started, which consistantly search, if a compass has been connected (this is absolutely unnecessary, cause I know where I have attached a sensor, the driver must not search for this!) .

I think the Hitechnic Code (and my small header file adjustement) are the best and most convenient for the moment.

Maybe you can improve the code further on to initiate and access the sensor like

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum