New C library - testers required

[Admin]

Just noting there was a bug in the Accelerometer and Compass code, but its been figured out and the next version will have the fix.

Webbot doesn't have many of the sensors, so its hard to verify code.

All the other code seems to be working fine.

[Webbot]

Version 1.8 available

Whats fixed: ACCM3D2 and HMC6343 - tested by Admin

Whats new: MPX5100a pressure sensor, ADXL335 accelerometer, IDG500 gyro:- all untested (alpha release)

I've also added a dump routine for each sensor type ie accelerometerDump(device) or compassDump(device) etc - this will dump the last read value of the device to the current rprintf destination meaning you dont have to worry whether to use %d, %u, %ld, %lu etc with your rprintf command - it just does it!

Remaining code remains unchanged and stable. Admin has tested the servo code (with like 10? servos), timers, delays, etc and no bugs currently outstanding.

The library is now getting quite 'feature rich':-

Sensors: 2 x accelerometers, 2 x compasses, 4 x current sensors, 3 x  sonars + many Sharp IR, quadrature encoders, 1 x gyro, 1 x humidty sensor, 1 x pressure sensor, 1 x temperature sensor, 1 x voltage sensor, 1 x camera. Just plug them in and go - no sensor coding required - swap one sensor for another with only two code line changes !!!

4 x commercial Motor drivers/controllers boards

Servos via hardware PWM or software PWM.

Bus options: I2C, SPI, UART, software UART, SPI over UART, SPI in software

Support for ATMega8, 168, 32, 640, 2560 and the Axon, Roboduino, and Baby Orangutan boards

And lots more

Plug, plug !!

Enjoy...

[Ro-Bot-X]

Nice! Thank you for your efforts! This lib has grown a lot! However, I was waiting patiencefully for some other things to be added like:

Can you add the tiny family (2313... and others) to the microcontrolers? I mean set up the USI to work as TWI (I2C), interrupts, UART... ? Also I know you've written code for AVRcam on Axon, can you add that camera to the library?

Thank you.

[Webbot]

I do have some tiny 2313 chips now but with only 2k of program space then I'm not sure how usable they are gonna be!

The 'plug'n'play' or 'just does it' approach of my lib always comes at a price and makes life easier for a 'master' board - but I'm not convinced its the solution for a slave sensor/controller device which needs to be a lot tighter.

I'll try to remember to send you a version with support so you can at least have a play (PM me with your email addr).

The tiny 2313 as a 20 pin dip package is not much smaller than say a Mega168 which has 8x more program space and isn't much different in price. So its the usual trade off ie 'easy but requires more space' vs 'compact but harder to code'.

I don't have any I2C devices so its always been hard to experiment with I2C master/slave but now Admin has tested that my I2C master code works then I can now play with I2C slave coding knowing that the master is working ok.

But 'Master and Slave' coding, as required by OSCAR on this forum, is even more complex and I'm not convinced that it will work (too much bus contention) and is very low down on my priority list for now.

AVRcam I haven't done - I've done the Blackfin. ALL of the 'devices' in the lib are supported by ALL of the target devices of my lib. However: the code may 'work' for the tiny but it may not 'fit' into the available space !

[Ro-Bot-X]

Oh well, don't get me wrong, there are 2 separate things, the tiny2313 and AVRcam. They are both slave devices tied to a "mega" master on a serial line (be it UART or I2C). Different projects. The thing that I'm interested for tiny2313 is setting up the USI to work as a regular I2C. The registers are different in contents and number, so I'm really curious if USI can work as a slave device (I know it can be done, they have a commercial lib for BASCOM-AVR).

Sorry, I must have confused you with someone else on this forum (mbateman) for the AVRcam. He has developed code for Axon to work with the AVRcam, see this thread: http://www.societyofrobots.com/robotforum/index.php?topic=6352.0 Perhaps you can talk with him to integrate it in your lib?

Thanks!

[Admin]

Ro-Bot-X, i support getting AVRcam added. Do you own one and are willing to debug/test the code? The requirement to getting your sensor added is that you gotta own it and willing to test/debug alpha code.
Or you can buy Webbot/admin one and we'll do it for you

As for the tiny2313 or any other memory limited mcu . . .
WebbotLib is designed to be feature-rich, powerful, and easy to use. This is a direct contradiction to what needs to be done to fit a program on a tiny . . . unless you plan to manufacture 20k+ units of something, the cost savings of a dollar or two isn't worth days of effort.

[Admin]

Oh, Webbot forgot to mention he also added the Toshiba TB6612FNG motor driver (alpha version).

I've been testing out the various sensors, and it turns out many of them don't match their datasheet. They have fairly bad manufacturing tolerances. So if you use a sensor with the library, keep in mind to calibrate your sensors!

I'll be testing some of the alpha versions today, and only report back if a bug has been both found and fixed.

As a side note . . . the manual gets thicker by ~15 pages per version. Mostly just added external hardware support. The manual is an easy read, but the size can still be intimidating to beginners. As such, I'm finishing up a  ~3 page crash course WebbotLib tutorial. It'll be released when we feel the library is 'beginner-proof'.

[Ro-Bot-X]

Ro-Bot-X, i support getting AVRcam added. Do you own one and are willing to debug/test the code? The requirement to getting your sensor added is that you gotta own it and willing to test/debug alpha code.
Or you can buy Webbot/admin one and we'll do it for you

Yes, I have an AVRcam, I can do tests with it.

As for the tiny2313 or any other memory limited mcu . . .
WebbotLib is designed to be feature-rich, powerful, and easy to use. This is a direct contradiction to what needs to be done to fit a program on a tiny . . . unless you plan to manufacture 20k+ units of something, the cost savings of a dollar or two isn't worth days of effort.

OK, I get it. No problem, I'll survive without it. Webbot sent me something that might do the trick. Thanks!

[Webbot]

Version 1.9 released -

Added the following sensors:-
InvenSense IDG300
ST LPR530AL  - which measure pitch and roll and is good companion with
ST LY530ALH - which measures yaw
These two gyros have just been released by SparkFun along with an ADXL335 3 axis accelerometer (already supported) to give a '6 degrees of freedom' sensor.

Added support for ATMega328P processor.

Fixed an issue in the 'clock' where the occasional strange result was generated.

Changed GPS code so that baud rate is not 'auto initialised' to 4800baud. It is now up to you to set the required speed that the device communicates at.

servos.h - added 'setServosConnected' and 'servosSetSpeed' to allow you to send the same command to entire bank of servos.

[Admin]

ST LPR530AL  - which measure pitch and roll and is good companion with
ST LY530ALH - which measures yaw
These two gyros have just been released by SparkFun along with an ADXL335 3 axis accelerometer (already supported) to give a '6 degrees of freedom' sensor.

FYI for those who don't know, WebbotLib now supports the smallest 6 DOF IMU on the market:
http://www.sparkfun.com/commerce/product_info.php?products_id=9431

Fixed an issue in the 'clock' where the occasional strange result was generated.

It was an overflow bug I found. Webbot, you mentioned you'd change the manual:
"It will, after every 7 minutes, wrap around to zero . . ."
Is it 7, or 3.5 now? (just checking)

Changed GPS code so that baud rate is not 'auto initialised' to 4800baud. It is now up to you to set the required speed that the device communicates at.

FYI for everyone, most GPS units are default (NMEA standard) at 4800. The Venus is 9600, and I'm sure others in the future will come even faster.

servos.h - added 'setServosConnected' and 'servosSetSpeed' to allow you to send the same command to entire bank of servos.

Webbot, in your manual its called ''servosSetConnected"

So, I just call this to turn off a bank?
servosConnect(&bank1);

[Webbot]

Is it 7, or 3.5 now? (just checking)

Have yet to do the exact maths - and it will now depend slightly on the  speed of the processor. - but its now about every 70 minutes

So, I just call this to turn off a bank?
servosConnect(&bank1);

No - that would 're-connect' the servos. Look at servos.h...
To disconnect you can use:

Code: [Select]

servosDisconnect(&bank1)or

Code: [Select]

servosSetConnected(&bank1, FALSE)

[Admin]

but its now about every 70 minutes

whoa . . .

So, I just call this to turn off a bank?
servosConnect(&bank1);

No - that would 're-connect' the servos. Look at servos.h...
To disconnect you can use:

Code: [Select]

servosDisconnect(&bank1)or

Code: [Select]

servosSetConnected(&bank1, FALSE)

lol here I am correcting your typos and I make a dumb one myself . . .

Anyway, I was playing around with your code yesterday and haven't found any new problems with it so far.

Oh and just an FYI to everyone else, WebbotLib is now as default too big for the ATmega8. You'll have to remove a bunch of libraries/stuff to get it to fit (otherwise you'll get a compiler error). But honestly, Webbot and I both feel its better to just not support the ATmega8 - its obsolete and the ATmega168 is much better.

[dellagd]

I'm impressed.
too much code.
nice .

[Webbot]

Version 1.10 released

Accelerometers are so flakey! The existing code will try to return a reasonable value. But the manufacturing tolerances are so varied that these values may be inaccurate for your device. In which case you can calibrate the software to 'fit' your device.

Use the existing code to find min/max values for each axis then to make them more precise try adding
 accelerometerCalibrateX(device,min,max)
 accelerometerCalibrateY(device,min,max)
 accelerometerCalibrateZ(device,min,max)
in your appInitHardware to force the sensor to return sensible values.
 

Tested and fixed all sonars MaxBotix EZ1, Parallax Ping sonar, Devantech SRF-05
Tested and fixed BabyOrangutan B328 board. On board 1 Amp motor driver verified as working.
Sabertooth.h moved from Motors/Dimension to Motors/DimensionEngineering
Added supprt for LB1836M as used by older BabyOrangutan boards
Changed Toshiba TB6612FNG to allow either 3 or 2 pin control - see manual
Fixed conversions for Sharp IR distance sensors
Each sys file now has a sysInitHardware to init any devices built onto the board
All versions of rprintf now allow %u to print unsigned number
Removed 'servoPWM.h' - its only function is now merged into 'servos.h'
timer.h - added 'compareGetOutputMode' function

[Webbot]

Version 1.11 released (see my signature for URL)

version.h lists the changes but the main change is the ability to set up a custom hardware PWM output. This is useful if your motor driver isn't 'listed' or if you want to use PWM for other stuff - like dimming an LED etc.

No other code signatures have changed - ie your 'old' code from version 1.10 will still compile with this release.

Enjoy.

--- Edit ----

Known documentation issues:
1. The Maxbotix EZ1 sonar example in the manual should say:-

Code: [Select]

Maxbotix_EZ1 sensor = MAKE_Maxbotix_EZ1(F0);
Known library issues to be fixed in the next release:-
A. The ATMega328P has a problem with uarts that causes the machine to reboot

[Webbot]

Version 1.12 released (see my signature for URL). As most things have now been tested, by me or others, then this is the first general release.

version.h lists the changes - they are as follows:-

• Added support for Freescale MMA7260QT accelerometer
• Fixed ATmega328B UART functions
• Fixed documentation for Maxbotix EZ1 distance sensor
• Fixed some 'case sensitive' include filenames - only effects Unix/Mac users

NB If you have any WebbotLib questions then please post under a new thread - DO NOT reply to this posting

[Webbot]

Version 1.13 released

See http://webbot.org.uk/iPoint/35.page

This includes the change for http://www.societyofrobots.com/robotforum/index.php?topic=9911.0 although it should be treated as 'alpha' as I don't yet have my Axon II to test against.

[madsci1016]

I'm trying to make sense of how to use the gpsNEMA header and code, i wish i had an example of how to access the data. For example, does gpsNEMA.latitude work?

Also it doesn't look like you parse out the "degrees of track true" from the NMEA messages, is this correct? Would you add that? I have a compass on my SAGAR BOT but still need to compare it to GPS Track degrees to compute offset of true and actual north.

Thanks, Madsci

[Admin]

I'm trying to make sense of how to use the gpsNEMA header and code, i wish i had an example of how to access the data. For example, does gpsNEMA.latitude work?

see Axon II GPS example code until Webbot expands the documentation

Also it doesn't look like you parse out the "degrees of track true" from the NMEA messages, is this correct? Would you add that? I have a compass on my SAGAR BOT but still need to compare it to GPS Track degrees to compute offset of true and actual north.

Yea, a few other variables aren't being processed either that probably should be. 
As for degrees, it won't be very reliable unless your robot is moving at a decent speed - its not a compass, it uses angle between current and previous locations only.

[Webbot]

Here's an example for the Axon:

Code: [Select]

// Example of how to use an NMEA compatible GPS card
#define RPRINTF_FLOAT

// We will use UART3 to talk to the GPS
#include "gpsNMEA.h"

#include "buffer.h"
#include "sys/Axon.h"
#include "led.h"
#include "gpsNMEA.h"
#include "rprintf.h"

// Create the gps
GPS_NMEA nmea = MAKE_GPS_NMEA(UART3);


// This routine is called once only and allows you to do any initialisation
// Dont use any 'clock' functions here - use 'delay' functions instead
void appInitHardware(void){
// Set up the hardware UART to xmit the results
uartInit(UART1, (BAUD_RATE)9600);

// Set rprintf to go to output
rprintfInit(&uart1SendByte);

// Turn on LED for no signal
statusLED_on();

rprintf("GPS warming up\n");
}

TICK_COUNT appInitSoftware(TICK_COUNT loopStart){
return 0;
}

// This routine is called repeatedly - its your main loop
TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart){
gpsNMEAprocess(&nmea);
if(nmea.info.valid){
statusLED_off();
rprintf("# sat:%d",nmea.info.numSatellites);
rprintf(" long:"); rprintfFloat(10,nmea.info.longitude);
rprintf(" lat:"); rprintfFloat(10,nmea.info.latitude);
rprintf(" alt:"); rprintfFloat(10,nmea.info.altitude);
rprintf("\n");
}
return 0;
}

I have added 'degrees of track true' into the next release

Yea, a few other variables aren't being processed either that probably should be.

Let me know if you have any specifics.

NB Don't forget that a given GPS device may only supply a subset of the possible GPS messages, and for each message may only supply a subset of the fields. eg not all GPS' provide altitude.

I tried to use the most useful fields to keep the code and data structure sizes as small as possible. Hence things like the details of each visible satellite are not returned as there isn't, as far as I can tell, anything useful that a robot could do with that info.

[Admin]

NB Don't forget that a given GPS device may only supply a subset of the possible GPS messages, and for each message may only supply a subset of the fields. eg not all GPS' provide altitude.

I tried to use the most useful fields to keep the code and data structure sizes as small as possible. Hence things like the details of each visible satellite are not returned as there isn't, as far as I can tell, anything useful that a robot could do with that info.

Well, altitude would be important to process for airborne bots . . .

Number of satellites hints at reliability of position data, useful to plug into a Kalman filter.

And angle is useful for faster robots, like car or aircraft types . . .

Now if a particular GPS isn't supplying some of that data, I'd argue it isn't following the full NMEA standard, and hence should probably be considered a special case.

[Webbot]

Look at gps.h to see what is returned.

amongst other things: it includes number of satellites, altitude and the next release will have track angle.

What I meant about the satellite info is I dont return: the satellite number and location of each individual satellite that is detected. This is only useful for graphic display.

[Admin]

I haven't used gps.h since we were originally debugging it. So probably was just the original version missing that stuff, then . . .

What I meant about the satellite info is I dont return: the satellite number and location of each individual satellite that is detected. This is only useful for graphic display.

oh! ok nm then.

[madsci1016]

As for degrees, it won't be very reliable unless your robot is moving at a decent speed - its not a compass, it uses angle between current and previous locations only.

I know, but comparing that value to your magnetic compass is the only easy way to correct for the magnetic north and gps north not being the same, as well as any hard iron offsets in your area.

Thanks for the addition and sample code Webbot.

[madsci1016]

Can I make a suggestion? In order to define a UART_RX_BUFFER, buffer.c needs to be included.
However this is not documented in the section on initializing uart buffers, and it took me a little while to figure that out.

Webbot, I am going to be using your library extensively on my Autonomous robot. Is there a way I can help you out more directly in perfecting the library, like adding to the documentation?

I also wrote an interface to control an Irobot Create/Roomba a while back that I could adapt (or try to) into a driver for your library. 

[Admin]

Is there a way I can help you out more directly in perfecting the library, like adding to the documentation?

He always needs people testing code, and if flaws are found, help in debugging. In the early days of WebbotLib I was definitely pulling out my hair! But I think I caused Webbot to lose some hair too with all my dumb mistakes . . .

I also wrote an interface to control an Irobot Create/Roomba a while back that I could adapt (or try to) into a driver for your library.

Thats actually a good idea. Since it uses the ATmega168, it shouldn't take much work to add iRobot Create support to WebbotLib.
http://www.societyofrobots.com/robot_iRobot_Create_mod.shtml

[madsci1016]

When i find my irobot code, i will see if i can adapt it for the Webbot lib driver style.

What about a wiki for the Webbot documentation? That way a few of the trusted regulars around here could help webbot perfect the documentation. and at the very least, a arduino reference ( http://www.arduino.cc/en/Reference/HomePage ) style index.

I assume Webbot and Admin would rather keep it 'in the family', but i have server space and a domain i could donate (yeah for unlimited transfer volume) and I have been waiting for an excuse to learn to install / manage a wiki.

Would you mind if i went ahead and started a wiki? and started to transfer what is in the pdf document into it?

[Webbot]

When i find my irobot code, i will see if i can adapt it for the Webbot lib driver style.

The way to go is to convert your code to use WebbotLib and then try to generalise it - ie configurable IOPin, uarts etc etc. Once done then this could become a candidate for addition. But since I don't own every piece of hardware, and so cannot test, then I would look for a number of 3rd parties to 'approve' its addition. This is fairly simple to do as your iRobot code can be wrapped up in an h file (or even as an additional precompiled library somewhat like the Arduino contributed libraries) and so users can add it on top of WebbotLib. Once stable, and you've got backers, then its just a case of me moving it into WebbotLib. The only reason why I may sound hesitant is that in order to do a new release I have to co-ordinate and re-test the code and verify the docs. Obviously this gets harder with more contributors. So its a trade off, for me, of being nimble vs having 'helpers'. In the meantime: it would then be your responsibility to release versions of your contributor library and to say what versions of WebbotLib it supports.

What about a wiki for the Webbot documentation? That way a few of the trusted regulars around here could help webbot perfect the documentation. and at the very least, a arduino reference ( http://www.arduino.cc/en/Reference/HomePage ) style index.

I don't want a Wiki (for now). If there are holes in the docs for my code then I would rather receive edits/additions etc. This way I can make sure that the docs are, at least, correct. Wikis tend to only be good for the latest release. So lets say something new was added to the software, but not released, then you would need a way to manage documentation for the next release which only became public upon release and only applied to that release.

I assume Webbot and Admin would rather keep it 'in the family', but i have server space and a domain i could donate (yeah for unlimited transfer volume) and I have been waiting for an excuse to learn to install / manage a wiki.

Would you mind if i went ahead and started a wiki? and started to transfer what is in the pdf document into it?

Couple of points:
1. WebbotLib is a 100% Webbot product with Admin being my much appreciated power user, tester, and advocate. So there is no 'family'.
2. I already have space at http://webbot.org.uk
3. Of course you could start an un-official Wiki but you will then have to keep it up to date with new versions.
4. In the same way that I can create trusted code contributors in SourceForge then I can also move my documentation system onto webbot.org.uk for trusted contributors.

[madsci1016]

The lib is your baby, and if you don't want me to do it, I won't.

But if you don't care either way, then I would like to try to create an unofficial wiki (or some other documentation style) site.

I think your lib has the potential to be a very powerful alternative the the Arduino IDE; however I feel currently it presents too high a learning curve to most people that are new to micro-controllers. If you are still in the process of perfecting the lib, and then you have plans to better document it after you are comfortable with it's stability, then I will leave well enough alone.

I will give you an example of what happened to me:

I was trying to use Uart communications for the first time, so i went to the pdf, found uart.h in the menu on the left, expanded it, and clicked "uartGetByte" since i knew that was the function i wanted. What i didn't realize was that since i navigated directly to the function, i missed the whole section on Uart buffers are disabled by default. So i spent an hour or so trying to figure out why i was getting the same single byte out of "uartGetByte". Then when i defined buffer sizes, i got strange compiling errors, and spent another half an hour before i realized i had to include buffer.h to get it to work.  (thats not in the pdf, at least i have not found it)

So i guess what i have the biggest problem with is the format the documentation is in. I am spoiled by the Arduino style of reference index, and i felt i could contribute to this community by making the Webbot lib documentation more "noob friendly'.

Like i said, it's your baby, so I'm not going to do a thing before i get a "go/no go" from you, or even a "Don't care" 

What if i keep it simply a unofficial (noob friendly) translation of you pdf releases?

[Webbot]

Can we take this offline - so as not to dilute the original thread about the software?
We will chat, decide, and post any results.
PM/email/etc me - and I'll get back to you over the next few days.