New C library - testers required

[Admin]

First, I'm announcing my official support for Webbots library. Meaning, I'll actively be encouraging people to use it, and I'll be using it for my new [fully open sourced] projects too.

I read through the manual yesterday and I liked what I saw . . . despite the long emails I sent to Webbot that might suggest otherwise
(call me a perfectionist! hehe)

Any 'noob-friendly' EEPROM support yet for your library? All Axons purchased since summer of '09 have proper EEPROM fuses enabled.
http://www.societyofrobots.com/member_tutorials/node/309

[Admin]

I've decided to use your library today to reprogram my robot fish from scratch. It uses a very old Axon version, using the ATmega2560, and the button activation is inverted in hardware.

Since the 640 and 2560 are exactly the same except memory size, anything I need to change in the ATmega640.h file before making it an ATmega2560? (other than the top two lines, of course)

And what are these .a files?

I was about to ask about the button inversion, but then I noticed in axon.h you reused most of my code, including button code that only works on the really old Axon prototype
(you should probably leave credit for my code at the top, saying modified by webbot or whatever )



Also, I see this:

// ADMIN - not sure why, but this interrupt is being called.  I'm not sure what the PD0 pin is hooked up to on the Axon.
// this is basically the cause of the reset.
EMPTY_INTERRUPT(INT0_vect);

Where in my Axon code is that?

[Webbot]

The .a files are the libraries.
Take all of my code and compile it for the 640. You now have a load of compiled .o files. If I just gave you all of these .o files then you would have to add them to your link process.

So think of the .a library files as being like a zip file that contains all of these .o files. Whats the benefit well it means that my lib comes pre-compiled. So you just compile 'your' code and then combine it with my already compiled code. Of course my libraries (the .a files) contain lots of stuff you may not actually use - well thats fine - the link process will only include my code that you have referred to - other stuff gets left out.

This means that every time you compile your code then it doesn't have to recompile mine (as it
hasn't changed anyway).

My download includes .a files for ATMega8, ATMega168, ATMega32 and ATMega640. For an ATMega2560 version it will take a few minutes but then a while to make an official release - or I'll just email it to you.

The Axon system file: credit where credit is due. Not hiding anything but was trying to put together a version for you yo play with.

The EMPTY_INTERRUPT stuff was DEFINITELY there in early versions of the Axon lib and looked like a 'workaround' to unexpected interrupts that would otherwise reboot the device. It may have been in earlier versions of the TImer code that has since been re-written. I'll remove it from my lib.

Have been away, and am still away for a few days. My internet is down - am using a friends machine. So bear with me!

New version imminent (next week or so) with some doc fixes and more examples and Blackfin, SPI, EEPROM and microSD card support

[Admin]

My download includes .a files for ATMega8, ATMega168, ATMega32 and ATMega640. For an ATMega2560 version it will take a few minutes but then a while to make an official release - or I'll just email it to you.

Hmmm I plan to use it tomorrow at work . . . whats the fastest way? Does it actually need to be added, or I can just compile without it and it'll just take a little longer?

The EMPTY_INTERRUPT stuff was DEFINITELY there in early versions of the Axon lib and looked like a 'workaround' to unexpected interrupts that would otherwise reboot the device. It may have been in earlier versions of the TImer code that has since been re-written. I'll remove it from my lib.

The early Axon code was all a hacked up version of the outdated AVRlib that didn't actually support the ATmega640. And I'm still a weak coder . . . may the old code be used as an example of how not to code

New version imminent (next week or so) with some doc fixes and more examples and Blackfin, SPI, EEPROM and microSD card support

Any plans for I2C?

Sorry for sounding demanding, I'm starting to really like your library, and want to push the limits (without my coding skill being the limit)

[Webbot]

ATMega2560 - I'll be emailing you an unofficial release - backward compatible with the last release of the lib.

I have written a program to auto generate the device files for each new processor based on the XML part files from ATMEL.  So, in theory, its very easy to add any new ATMEL device. The downside is that I keep finding/reporting bugs in ATMELs own XML files - doh! Whilst they are fixable by me then I have to chase them to make sure that future releases don't 'overwrite' my fixes.

I2C - yep its on my list. I definitely need to provide routines for an I2C slave and an I2C master. The OSCAR project implies a device that is both master and slave - but that extra complexity will need to wait for now until the basics are done. Having no I2C devices then I will be flying blind anyway. Guess I need some voting/polling software for future features.

Keep me/us informed on your on-going progress.

[Admin]

Having no I2C devices then I will be flying blind anyway.

I'll be using it as soon as you release it

Guess I need some voting/polling software for future features.

I can arrange for that . . . but expect a lot of people requesting really odd things, like 'a library that detects faces for my photovore robot'.

Personally, I think it better for people to submit their own working code, then you add it to the library. At the moment, I think the basics are more important, like SPI and I2C, and bug fixing. Feature creep for later

edit: Now that I think about it, after you get I2C working, can you convert this code over to your library?
http://www.societyofrobots.com/robotforum/index.php?topic=8393.0
It works using AVRlib I2C, so should be easy to port. Or if you're busy, I'll do it using your I2C documentation
(but you'll probably nod your head in disapproval of my hacked up code, hehe)

[jaime]

Hi.  I'm a robot noob (1st post, yay).  But I'm a pretty good C programmer, so I'm not a complete loss!

Anyway, I can't get the rprintf functions to work.  I'm working with the AXON micro controller.

My code is below.  The program works in its current state.  The status led blinks every second or so.  However, if I uncomment the rprintf line, the AXON "crashes".  There is no blink, there is nothing.  I assume the program has "crashed" but I can't tell

Any ideas?  Thanks!


// Specify which board is being used.
#include "sys/axon.h"
#include "uart.h"
#include "rprintf.h"

typedef void (*puart_sbyte)(unsigned char);


/*
 * @brief Called once for hardware initialization.
 *
 * DO NOT USE ANY CLOCK FUNCTIONS HERE.  Use 'delay' functions instead.
 *
 */
void appInitHardware(void)
{
    uartSetBaudRate(UART1, 115200);
    rprintfInit((puart_sbyte)&uart1SendByte);
}


/*
 * @brief Called once to allow variable initialization.
 *
 * Clock can be used here.
 *
 * @param loop_start contains the current clock value in uS.
 * @return pause counter
 */
TICK_COUNT appInitSoftware(TICK_COUNT loop_start)
{
    return 0;
}

/*
 * @brief "main" function called repeatedly; the main loop.
 * @return the time to wait before callign in uS.  1,000,000 uS = 1s.
 */
TICK_COUNT appControl(LOOP_COUNT loop_count, TICK_COUNT loop_start)
{
    statusLED_set(loop_count % 2);
    // rprintf("Hello world...\n");
    return 1000000;
}

[Admin]

jaime, I got the same error about 10 days ago. This email, from Webbot, describes how to fix it.

The problem you are seeing is caused by a "funny" I introduced in the last release (its already fixed but I haven't re-released yet). The problem came about when I added different sorts of uarts ie both hardware and software. The docs also need changing as 'uartSetBaudRate' should be replaced by 'uartInit'.

So change your 'uartSetBaudRate' to 'uartInit' - else the program will hang on your first use of rprintf.

You will still get the compiler warning (until I manage to do a new release) but the code should still run ok.

There's also a bug in the documentation on page 57 where the
include "servos"
should obviously be
include "servos.h"

[jaime]

jaime, I got the same error about 10 days ago. This email, from Webbot, describes how to fix it.

The problem you are seeing is caused by a "funny" I introduced in the last release (its already fixed but I haven't re-released yet). The problem came about when I added different sorts of uarts ie both hardware and software. The docs also need changing as 'uartSetBaudRate' should be replaced by 'uartInit'.

So change your 'uartSetBaudRate' to 'uartInit' - else the program will hang on your first use of rprintf.

You will still get the compiler warning (until I manage to do a new release) but the code should still run ok.

There's also a bug in the documentation on page 57 where the
include "servos"
should obviously be
include "servos.h"

Perfect, that did the trick!

jaime

[Admin]

Webbot, I'm fairly sure its your code that has the H6/E6 bug . . .

I'm using this below code. Its a stripped down version of your photovore code in your manual.

Code: [Select]

#include "sys/fish_2560.h"
#include "servoPWM.h"
#include "a2d.h"
// Define two light sensors connected to ADC channels 0 and 1


// Define two servos
SERVO left = MAKE_SERVO(FALSE, E6,1500, 500);
SERVO right = MAKE_SERVO(TRUE , H6,1500, 500);

// Create the list - remember to place an & at the
// start of each servo name
SERVO_LIST servos[] = {&left,&right};
// Create a driver for the list of servos
SERVO_DRIVER bank1 = MAKE_SERVO_DRIVER(servos);


// In my initialising code - pass the list of servos to control
void appInitHardware(void){
// Initialise the servo controller
servoPWMInit(&bank1);
// Give each servo a start value of 'stop'
act_setSpeed(&left, 0);
act_setSpeed(&right,0);
}

TICK_COUNT appInitSoftware(TICK_COUNT loopStart){
return 0;
}

// This is the main loop
TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart)
{
int i;

for(i=0;i<100;i++)
{
act_setSpeed(&left,50);
act_setSpeed(&right,50);
delay_ms(20);
}
for(i=0;i<100;i++)
{
act_setSpeed(&left,-50);
act_setSpeed(&right,-50);
delay_ms(20);
}

return 20000; // wait for 20ms to stop crazy oscillations
}
The sys file fish_2560.h is exactly like the axon sys file, except this:

Code: [Select]

cbi(PORTG, PG5);  // disable pull-up resistor for v1e and earlier
//sbi(PORTG, PG5);  // enable pull-up resistor for v1f and laterAnd that 640 is swapped for your 2560 files.

The problem is, E6 and H6 don't work. Both pins work fine with my non-webbotlib code. If I change the code to this, using different pins, it works fine:

Code: [Select]

// Define two servos
SERVO left = MAKE_SERVO(FALSE, E5,1500, 500);
SERVO right = MAKE_SERVO(TRUE , H5,1500, 500);
Anyone else having trouble getting H6 or E6 working on their Axon using the WebbotLib?

[jaime]

This simple program below works for me, using E6.

Code: [Select]

// Specify which board is being used.
#include "sys/axon.h"
#include "uart.h"
#include "rprintf.h"
#include "core.h"
#include "servos.h"

typedef void (*puart_sbyte)(unsigned char);

SERVO servo = MAKE_SERVO(FALSE, E6, 1500, 500);
SERVO_LIST servos[] = {&servo};
SERVO_DRIVER bank1 = MAKE_SERVO_DRIVER(servos);

void appInitHardware(void)
{
    uartInit(UART1, 115200);
    rprintfInit((puart_sbyte)&uart1SendByte);
    servosInit(&bank1, TIMER1_COMPAREA);
}

TICK_COUNT appInitSoftware(TICK_COUNT loop_start)
{
    act_setSpeed(&servo, DRIVE_SPEED_CENTER);
    return 0;
}

TICK_COUNT appControl(LOOP_COUNT loop_count, TICK_COUNT loop_start)
{
    if (loop_count % 2 == 0) {
        act_setSpeed(&servo, DRIVE_SPEED_MAX);
    } else {
        act_setSpeed(&servo, DRIVE_SPEED_MIN);
    }
    statusLED_set(loop_count % 2);
    rprintf("Hello world...\n");
    return 1000000;
}


[Webbot]

So the differences are that 'jaime' is using software servo control (which works) and 'admin' is using hardware PWM for the servos (doesn't work).

Admin is using H6 which is also OC2B which is Timer2 channel B, and using E6 which is not a PWM output pin !
Also Timer2 is only an 8 bit timer whereas hardware PWM for servos, as per manual, really requires a 16 bit timer.

@Admin - are you seeing an error msg flashing on your status LED as I'm guessing the lib is not doing anything as you've asked it to do PWM for servos on a non 16 bit timer, and to E6 which is not a PWM output. So it ain't ouputting anything - and is flashing an error number on the status led.

--edit--
so you should either get 7 flashes on the LED (timer must be 16 bit) or 12 flashes (the pin, E6, is not a PWM output)

-- edit2 --
@jaime I can tell from your code comments that you are a top notch C programmer. First post - you say.  You're more than welcome

[Webbot]

Have released version 1.4 on SourceForge.

There is now only one download - which includes all of the libraries as well as the documentation PDF. Since some folk found it hard to locate the PDF docs. So now its just a one click download.
So whats new:-
ATMega2560 support
New SPI interface support using SPI hardware, or in software or via any UARTs that supports SPI mode (ie ATMega168, ATMega640 and ATMega2560)
Added EEPROM support and documentation.
Added new 'CLAMP' function to libdefs.h
Fixed some doc bugs.
Work in progress for next release is Blackfin camera, SSD card, and I2C.

Decision to upgrade is up to you - but bug fixes will only be made to current/future code streams.

Thanks to all who have downloaded and tried and especially to Admin and Surveyor corp for their on-going patience and commitment.

-- edit --
the SourceForge site should now have some area to post messages. Haven't tried it yet so dont know what its like or whether it will send me an email. Give it a go.
Plan is to continue to release versions on sourceforge but to hold a 'last tested by SoR Admin' copy/link on this site.

[Admin]

So the differences are that 'jaime' is using software servo control (which works) and 'admin' is using hardware PWM for the servos (doesn't work).

Admin is using H6 which is also OC2B which is Timer2 channel B, and using E6 which is not a PWM output pin !
Also Timer2 is only an 8 bit timer whereas hardware PWM for servos, as per manual, really requires a 16 bit timer.

oops . . . I thought I was using software PWM all this time . . . lol I feel dumb now . . .

Plan is to continue to release versions on sourceforge but to hold a 'last tested by SoR Admin' copy/link on this site.

I'll probably wait for another version release or two before establishing a permanent link, just to make sure all the major issues are ironed out.

Just so everyone else knows, I'm rewriting my robot fish code from scratch to use the Webbotlib, my biped (and Biped Engine v3) is now using this lib, the Axon II will fully support it, and I *may* rewrite my ERP code to use the lib too.

[Admin]

I noticed that I can only use one timer thingy per servo bank. For example, these don't work:

Code: [Select]

servosInit(&bank1, TIMER1_COMPAREA);
servosInit(&bank2, TIMER1_COMPAREA);

Code: [Select]

servosInit(&bank1, TIMER2_COMPAREA);
servosInit(&bank2, TIMER2_COMPAREA);
but these work fine:

Code: [Select]

servosInit(&bank1, TIMER1_COMPAREA);
servosInit(&bank2, TIMER2_COMPAREA);

Code: [Select]

servosInit(&bank1, TIMER1_COMPAREA);
servosInit(&bank2, TIMER1_COMPAREB);
Not sure if you are aware of this, or if it's that important to fix . . .

[Webbot]

Yep - thats the whole point of having a 'bank'. All the servos in a bank are connected to one timer compare channel.

So in your first example:-

Code: [Select]

servosInit(&bank1, TIMER1_COMPAREA);
servosInit(&bank2, TIMER1_COMPAREA);
Then you may as well put all the servos into bank1 and get rid of bank2 altogether. Obviously a given timer compare channel (ie a bank) can only cope with a finite number of servos (as per manual) otherwise the frequency of issuing the pulse to each servo becomes too long.

Have you got a status LED registered (ie are you on the AxonI or AxonII)? If so then it should start flashing an error message (5 flashes, 2s pause, 5 flashes, 2s pause etc) when you connect bank2 since TIMER1_COMPAREA is already in use - which is what the 5 flashes means as listed in errors.h

[Admin]

oh! I guess that makes sense then.

As for the status LED error, didn't notice it. I have the Axon and the robot fin tester in my giant water tank like 10 feet away from me. I was too lazy to get up and check it out
(yeap, it flashes as you said, with a ~1.5s pause )

This error detection + flashing LED idea is interesting. For the Axon II, what if it actually displayed an error number on the display while flashing? That'll limit to 10 errors, but you can flash two numbers in succession for many more.

[sonictj]

That'll limit to 10 errors, but you can flash two numbers in succession for many more.

10 numbers but you can also make different combination with the leds. 2^7 for 7 segments is 127 different combinations excluding all off.

[Webbot]

This error detection + flashing LED idea is interesting. For the Axon II, what if it actually displayed an error number on the display while flashing? That'll limit to 10 errors, but you can flash two numbers in succession for many more.

On the Axon I use the on board LED, and the Axon II uses the decimal point of the segment display. Once I get an AxonII then the plan is to also be able to send errors to any output ie via UART, on board LCD display, or the on board single LED segment as a marquee. Flashing LEDs is a good start point but I've now got a lot of error codes so counting the flashes can be difficult for the larger numbers. The only issues with using the whole 7 segment display is it then becomes reserved for the library which is why I've used the decimal point. I guess I could make it so that the user can access the display but once an error is logged then it ignores anything else from the users program.

Note: don't forget that your own code can also use this feature. My error codes are negative numbers which cause the LED to flash rapidly. Your own codes should always be positive numbers which cause it to flash more slowly - so that you can tell the difference between your own errors and those reported by the library. This is useful if there is a point in your code where something unexpected happens - so you could signal the error and 'stop the robot'.

[Webbot]

Version 1.5 now released - see my signature for website link.

A2D problems fixed, software servo PWM improved when lots of servos,  some new functions added to rprintf.

See version.h for details.

This release also contains an 'alpha' version of Blackfin support - so no docs for now - but anyone that has used Admins library should see that the functions in Cameras/Surveyor/Blackfin.h are familiar. Am adding support for other Blackfin commands before releasing/documenting.

Thanks to Admin for continuing to test this to destruction !!

Webbot

[Admin]

Thanks to Admin for continuing to test this to destruction !!

yea quite literally . . . all previous versions will cause your servos to overheat and fry - and I wouldn't have noticed it if it wasn't for all the debugging I went through to figure out the ADC bug.

I just installed the latest version, and I'll play around with it all today. You'll hear back if/when I find problems.

*         Added 'fraction.h' - not documented as you need to understand Fabonacci sequences. Too long to describe !! But is used
 *            by other lib functions to avoid floating point maths library.

Is this a response to me adding the math.h include in my code?
Do I still need it?

And I'm sure you have a good reason for rprintfCharN, but I can't figure out how its useful . . .

Also, since you have seen my code . . . Webbot, I think my hardware.h file method should be used in future versions. Its not a big deal for a robot with just a handful of external stuff, but becomes much more useful to declutter/organize code when you have 10+ servos and many sensors.

Oh, and I'm working on a 'getting started with WebbotLib for the Axon' tutorial. It's 90% done. I'll release it when I'm confident all the bugs are thoroughly squished.

[Webbot]

Is this a response to me adding the math.h include in my code?
Do I still need it?

Yep you still need math.h - until such time as I can get around to documenting the fraction stuff. The fraction stuff is also only useful for multiplying by a real number - the result is always an integer. But its good for mapping linear values - as with some sensors, or when mapping between YUV and RGB values from cameras like the Blackfin (ah hah - that's why its been added).

And I'm sure you have a good reason for rprintfCharN, but I can't figure out how its useful . . .

No worries - one day you may find a purpose   I have used it elsewhere in the lib as it reduces the amount of flash taken up by things like: 

Code: [Select]

rprintf("-------------------------\n");
rprintf("|  Menu Options: |\n");
rprintf("-------------------------\n");


Also, since you have seen my code . . . Webbot, I think my hardware.h file method should be used in future versions. Its not a big deal for a robot with just a handful of external stuff, but becomes much more useful to declutter/organize code when you have 10+ servos and many sensors.

The hardware.h file is a way you have used to make your own code look neater. Its isn't part of the library and changes for each project. My 'dev/*.h' files detail ALL of the processor hardware available - and your file maps the connected devices onto the processor hardware for a given project.

So the best place to comment on it is in your 'Getting started with Webbot lib guide' - as your recommendation of one way of working.

I have done a similar thing myself with my example/test code whereby I can recompile the same example for all of the supported boards/processors.

[Admin]

Just letting everyone know I've verified that the ADC and servo frying bugs have been squished. Still a minor issue with the servo code (minor servo jumping), but me and Webbot are working on it behind the scenes.

And I'm sure you have a good reason for rprintfCharN, but I can't figure out how its useful . . .

No worries - one day you may find a purpose   I have used it elsewhere in the lib as it reduces the amount of flash taken up by things like: 

Code: [Select]

rprintf("-------------------------\n");
rprintf("|  Menu Options: |\n");
rprintf("-------------------------\n");


Oh! For purposes of satisfying OCD! (just poking fun, I understand why now)

The hardware.h file is a way you have used to make your own code look neater. Its isn't part of the library and changes for each project. My 'dev/*.h' files detail ALL of the processor hardware available - and your file maps the connected devices onto the processor hardware for a given project.

So the best place to comment on it is in your 'Getting started with Webbot lib guide' - as your recommendation of one way of working.

Yea that was the current plan, and how I structured my tutorial. I'll keep the status quo, then.

[Webbot]

New version 1.6 released (read version.h from the download) but:-

1. fixed delay issues reported by Admin
2. fixed servo twitch issues reported by Admin when controlling servos (like loads of servos!) via software rather than by hardware PWM. ie Axon is also acting as a servo controller board. May be a small twitch still left but then the controller cant run your program, manage 20 servos, do USART comms etc etc. There are only so many microseconds it has in the day. Bit like me?
3. Added I2C master routines. Nice'n'small'n'tight. Your I2C based sensors will be built into the lib in the coming weeks/months - so unless you want to play with I2C then dont worry. It just works. Oh No - its alpha release of I2C so I will be bombarded with comments that it 'just doesn't' !!
4. Alpha version of Blackfin camera support plus documentation. Watch this space for up'n'coming apps to help support the excellent Blackfin from your PC.

Download from  the usual place - see my signature.

[Admin]

The alpha version for I2C in v1.6 has a bug. This is how to fix it:

First, in appInitHardware(void), add this:

Code: [Select]

i2cSetBitrate(100);You won't need to do this manually in future versions, Webbot will be adding it in.

Second, in the sys file, enable internal pullups. For example, for the Axon, enable the pull-ups BEFORE DDRD:

Code: [Select]

sbi(PORTD, PD0); // SCL pull-up
sbi(PORTD, PD1); // SDA pull-up
DDRD = 0b11110011;  //configure ports for output
*Note that internal pull-ups shouldn't be used if you have external pull-ups already. The Axon doesn't come with external pull-ups.

[Webbot]

These two mods were just a temporary fix for 1.6 to get things going.
Come 1.7 then you wont need to do either of these.

*Note that internal pull-ups shouldn't be used if you have external pull-ups already. The Axon doesn't come with external pull-ups.

The internal pullups are between 20k and 50k. So if you have external pullups like 4.7k then the effect of the internal pullups will be negligible. ie the the internal pullups can ALWAYS be turned on (which is what the next release will do).

[Admin]

The internal pullups are between 20k and 50k. So if you have external pullups like 4.7k then the effect of the internal pullups will be negligible. ie the the internal pullups can ALWAYS be turned on (which is what the next release will do).

Even better . . . less confusion for beginners, too.


So uhhhh what happens after v1.9? What version will it be called

Anyone else current using WebbotLib for anything interesting?

[Webbot]

So uhhhh what happens after v1.9? What version will it be called

Luckily computers have lots of fingers - so I'm guessing 10,11,12 etc 
But since most things have been getting a good hammering: motors, sensors, servos, timers etc etc then I feel we are close to the first production release - Version 1.0. Yeah I know that conflicts with the past but live with it for this first release.
Subsequent interim releases will then be 1.0.1, 1.0.2, 1.0.3 until a production 1.1 release is made.

Anyone else current using WebbotLib for anything interesting?

C'mon folk - I know from my PMs who some of you are!  Give us the news bad/good/indifferent! Even if you've just been playing.
 

[Admin]

so I'm guessing 10,11,12 etc

I'm thinking 1.9, 1.10, 1.11, 1.12, 1.13, etc.

Otherwise people who search for help on the forum might get confused . . .

[Webbot]

Version 1.7 is now available  (For Admin this is called 1.0.1.7.8.3.2  )

Whats fixed:
The I2C issues discussed in previous threads.

Whats new:
Toshiba TB6612FNG motor driver - cool little motor driver
Dynamic Engineering - ACCM2D2 3 axis accelerometer
Honeywell HMC6343 compass, with roll & pitch
iopin now has a pulseIn and pulseOut feature
Have restructured the way sensors work - see below *

NB Some flles have been deleted or have been moved. So you should delete your previous install directory before loading this version - to make sure that all the 'old' stuff gets removed.

* Sensors are now organised by type/make/model.h
Where:-
type: is stuff like: distance, voltage, compass, current, acceleration etc
make: is the manufacturer: Phidgets, Devantech, Sharp etc
model: is the part number of the device: TB6612FNG

The old sensorRead and sensorReadRaw functions have gone!! They only returned one value, and some sensors, like accelerometers return lots of values. Also, due to C limitations, they always had to return the same data type. And this became a pain.

Instead they can be accessed via <type>Read(sensor) eg distanceRead, compassRead etc.
But note that the read doesn't return a value - it just reads the sensor and stores away the values. These values can then be accessed (without re-reading the device). Each type can now potentially return a different value eg floats vs uint16_t etc - but all of the devices of the same type will return the same value (ie you can still swap one 'compass' for another without changing your code).
The manual explains all !!

The attached example shows how to use all of the sensors. NB This is not meant to be compiled/executed because, with so many sensors, some of the IOPins are re-used for multiple sensors. Its only for reference.