New C library - testers required

[Webbot]

I have finally got around to uploading my new software library to SourceForge as a Beta release so I'm looking for 'guinea pigs' to check it out !

There are 2 downloads - a 'zip' file contains the source, header files, and compiled libraries. There is also a PDF file which you should download as it has a getting started section as well as the full API documentation. The source code is really only there for reference purposes if the documentation is unclear. The getting started guide shows how to use the library without copying any files out of the library. If you want to change the source code, or add to it, then I encourage you to sign up as a contributor on the Source Forge website.

The library makes it very simple to use a myriad of 3rd party hardware such as motor controllers, sonars and various sensors. For example: if you've written a program that uses the built in modified servo support and you decide to replace the servos with a SabreTooth DC motor controller then you only need to change about 6 lines of code. The PDF gives an example of doing this with the Photovore program.

Currently the library supports ATMega8, ATMega168, ATMega32 and ATMega640 processors but I can add extra AVRs very easily (no PIC support I'm afraid). Specific support has been added for the Axon, Roboduino, and BabyOrangutan boards.

Note that this is quite a large, and comprehensive, library and, with your assistance, I want it to become the 'defacto' standard for robotics (whereas AVRlib is just a generic library).

My library doesn't require AVRlib - only the WinAVR files that come with AVRStudio.

There is no I2C support (yet) but I'm working on it.

Here's the source forge project page - http://webbotavrclib.sourceforge.net/

I welcome any feedback

[hazzer123]

Wow, a quick look at the documentation and im already impressed!

Ill definitely take a look at it in the near future.

[Admin]

I haven't had time to look through it yet, but this would make a great replacement for AVRlib (which is seriously out of date).

If you have a $50 Robot and want much better features than the default software in my tutorial, this is what you should start using.

[dellagd]

I would test it but my $50 board will not work for no apparnent reason (soldering is good. voltage from the regulator. just don't know why)

[Webbot]

Also works with Axon and Roboduino boards - or any other custom made ATMega8/168/32/640 board

[Resilient]

Looks great so far.

But I am trying to resolve an issue I am having with Roborealm and want to try tweaking the rprintf function (see http://www.societyofrobots.com/robotforum/index.php?topic=7880.0) but am a little unclear as to how to do this because of the precompiled libraries.

If I change the rprintfs.c in your library folder nothing changes (because of the precomiled bit), but if I include a modified version of rprintfs.c in my folder and include that in the AVR Studio source files, it complains about the .elf file not being found (This I don't understand).

Thanks
Justin

[Webbot]

Looks great so far.

But I am trying to resolve an issue I am having with Roborealm and want to try tweaking the rprintf function (see http://www.societyofrobots.com/robotforum/index.php?topic=7880.0) but am a little unclear as to how to do this because of the precompiled libraries.

If I change the rprintfs.c in your library folder nothing changes (because of the precomiled bit), but if I include a modified version of rprintfs.c in my folder and include that in the AVR Studio source files, it complains about the .elf file not being found (This I don't understand).

Thanks
Justin

Hi Jason,
I discovered a potential issue in the uart buffer code which would leave interrupts disabled. So I guess that could be your original problem - ie the transmission stops.

I've uploaded a new release 1.1 to sourceforge - (also contains code to create software uarts and to handle GPS message data).

Could you try that release first and let me know - thanks.
Webbot

[Resilient]

No dice. Still buffers in Roborealm. I think it really must be an issue on their side.

[dunk]

dude,
good job so far.

dunk.

[Webbot]

Ok - some folk seem to be giving it a try - thanks.

Here is a list of other stuff I want to add:-
1. I2C (master only, slave only, master + slave) - split into 3 to keep size to a minimum
2. 7 segment LED support - as per Axon II LED
3. Generic 'pulseIn' function (pulled out of the existing sonar libs) for any IOPin
4. Generic 'pulseOut' function to emit a 'one-off' pulse, or a train of pulses (ie frequency/duty cycle generator)
5. Generic 'frequencyIn' function to return the frequency and duty cycle present at an input pin
6. RF transceiver for inter-robot/pc comms.
7. Single wire UART - for some humanoid type servos
8. SPI interface

Add to documentation:
1. Table of 3rd party hardware sensors/controllers - and what functions to use with each of them. If you've discovered any new combos ie 'this software' also works for 'this device' then let me know and I'll add it to the list.
2. More example programs

This is partly 'a note to self' but more importantly - a chance for you guys to say whats missing. So post any 'votes'.

[Admin]

Just an update . . . I'll try implementing this on the Axon 2 within the next ~3 weeks, right after RoboGames. My crazy schedule chills out on like the 17th of this month.

Bandwidth and server usage is not a prob, I'm currently using like only ~7% of my alloted resources

[Resilient]

Edit: Solved my own problem, doing basic subtraction correctly is helpful to programming.

[Resilient]

Ok, now I really am having a problem that cant be solved by simply doing subtraction right

I got the following code:

Code: [Select]

// Place any #define statements here before you include ANY other files
// You must ALWAYS specify the board you are using
// These are all in the 'sys' folder e.g.
#include "sys/axon.h" // I am using an Axon
// Now include any other files that are needed here
#include "uart.h"
#include "rprintf.h"
#include "libdefs.h"
#include <stdarg.h>
#include "Sensors/Encoder/quadrature.h"
#include "Motors/Dimension/Sabertooth.h"
// Now create any global variables such as motors, servos, sensors etc

#define TIME_REDUCTION 250000 //converts us to 1/4 seconds

ENCODER l_encoder = MAKE_ENCODER(K0,E3,FALSE,64);
ENCODER r_encoder = MAKE_ENCODER(J6,C1,TRUE,64);

SABERTOOTH_MOTOR motor1 = MAKE_SABERTOOTH_MOTOR(FALSE, 128,0);
SABERTOOTH_MOTOR motor2 = MAKE_SABERTOOTH_MOTOR(FALSE, 128,1);

SABERTOOTH_MOTOR_LIST motors[] = {&motor1,&motor2};
SABERTOOTH_DRIVER driver = MAKE_SABERTOOTH_DRIVER(motors, UART2, 19200);


//Wheel circrumfurance 229mm
//Add your code here
//Global variabls
int16_t r_clicks = 0; // Total clicks travled
int16_t l_clicks = 0;
int do_once = 1;

//encoder stuff

TICK_COUNT r_prev_time = 0;//Time of the last encoder reading
TICK_COUNT l_prev_time = 0;
TICK_COUNT speed_calc_timer;

//pid stuff

int16_t r_target_speed = 0; // most recent speed in clicks per 1/4 second
int16_t l_target_speed = 0;
int16_t r_speed = 0; // most recent speed in clicks per 1/4 second
int16_t l_speed = 0;
int16_t r_integral = 0; // integrals
int16_t l_integral = 0;
int16_t r_previous_p = 0;
int16_t l_previous_p = 0;
TICK_COUNT r_prev_integral = 0;//Time of the last encoder reading
TICK_COUNT l_prev_integral = 0;



int16_t calculate_speed(char side);
int16_t pid(char side);
void go_speed(int16_t l, int16_t r);



// This routine is called once only and allows you to do any initialisation
// Dont use any 'clock' functions here - use 'delay' functions instead
void appInit(void){
// Set UART1 to 115200 baud
uartSetBaudRate(UART1, 115200);
// Tell rprintf to output to UART0
rprintfInit(&uart1SendByte);
uartSetBaudRate(UART2, 19200);
sabertoothInit(&driver);
}



// This routine is called repeatedly - its your main loop
void appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart){
DRIVE_SPEED speed = 127;
if(do_once == 1)
{
speed_calc_timer = clockGetus();
do_once = 0;
}
if(clockHasElapsed(speed_calc_timer, TIME_REDUCTION) == TRUE)
{
act_setSpeed(&motor1,100);
if(speed > -127)
{
speed = speed-5;
}
}

}

But no motor is turning. I would expect it to start at near full speed then go down and eventually reverse. It is also throwing a warning saying:

../webtst.c:23: warning: initialization from incompatible pointer type

for the SABERTOOTH_DRIVER driver = MAKE_SABERTOOTH_DRIVER(motors, UART2, 19200); line.

Any ideas here?

[Webbot]

Hi Resilient - am away on business at the moment. So you may have to hangon until Tuesday. But will see if I can get time to have a look between meetings. Sorry..

[Resilient]

No problem. I wrote my own function to use the simplified mode on the Sabertooth and that works, so getting it fixed is not critical.

I also tried directly copying and pasting your code from Sabertooth.h and tried running that and had the same result. Wheels just sit there.

So something isn't working right with the Sabertooth functions on the Axon. I am using UART2 (which I did remember to change in your test code in Sabertooth.h)

[Webbot]

Ok think I found the problem. It came about when a created a virtual UART - ie all the code that can use a uart can now use either a hardware uart or a software uart. And this is what is causing your compile warning and therefore for the program to not work (I Think!).

I'd be really grateful, if you have time, to ediy 'dev/ATMega640.h' where it says:
#define UART2 &Uarts[2]
to say
#define UART2 &Uarts[2]._uart_

And then try your original code (or mine) again. Assuming that works then you may as well change the other UART defs in dev/ATMega640.h so that they also have the '._uart_' on the end as well.

Let me know if it works, and I'll do another release to fix the issue for others.

Thanks for all your efforts.

Webbot

[Webbot]

To those that have tried out my library.....

Currently your application file has to have 2 functions 'appInit' and 'appControl'.

appInit lets you set up all the hardware and therefore timers/PWM/InputCapture etc etc.

On return the the library then tries to find a left over timer to use for its system clock. So on the Axon it can use one of the timers that dont have pin headers and its less likely you will have used it. For this reason the call to 'clockGetus' cannot be used as the clock isn't set up until appInit returns.

appControl is then called repeatedly. It has a 'loop counter' but you cannot rely on testing this for '0' as it will eventually wrap around.

So I've noticed some peoples code (and Resilients attachment below is a good example) still use a flag ('do_once') to do any one-off set up.

I'm thinking of changing this to have a 3rd function inbetween the 2 so that there will be:-
appInitHardware - the new name for the old appInit. Set up your motors/drivers here. Still no clock
appInitSoftware - a new function - called only once. At this stage the clock will exist
appControl - same as before and called repeatedly forever.

So this means you can get rid of those 'one-off' variables and initialise your app in once place. I would make the signature of appInitSoftware be the same as appControl - but the 'loop_count' parameter to appInitSoftware would ALWAYS be 0.

I am also thinking of allowing both appInitSoftware and appControl returns a value in ms. So if appInitSoftware returned a value of 20 then there would be a 20ms delay before the first call to appControl to let the hardware settle down. appControl could return a value of 20 so that it was next called in 20ms minus the time taken for the current pass. Admins code often has a similar delay at the end of each loop to 'prevent crazy oscillations'.

Of course returning a value of 0 would mean dont pause at all - go at full speed.

What do you think?

[Resilient]

I like both of those ideas quite a bit.

I tried your solution to the sabertooth problem. It fixes the compile problem with the sabertooth function, but breaks every other UART related function.

It also doesn't make the sabertooth work.

The code I used as a temporary solution is the following:

Code: [Select]

//Takes values between 0 and 127 for motor speeds
void sabertooth(uint8_t m2, uint8_t m1)
{
uartSendByte(UART2, m1);//send a command for motor 1
uartSendByte(UART2,m2+128);//send a command for motor 2
}

This works when the dip switches are set to Simplified Serial mode  (rather than packetized like it was set before) . So serial communication works with the sabertooth with no changes needed to anything, so it seems like there must be something else going on here in the sabertooth functions (rather than the UART functions).

[Webbot]

Ok - tanks for that. Shows the problem of trying to fix code via mobile/cell phone!

Will take a look when I get home.

[Resilient]

I ran into a new problem.

I am trying to use a sharp GP2D120 sensor.

When I include:

Code: [Select]

#include "Sensors/Distance/SharpIR_GP2D120.h"
#include "sensor.h"

everything compiles fine, but as soon as i add

Code: [Select]

GP2D120 ir_r_f = MAKE_GP2D120(K5);
GP2D120 ir_r_r = MAKE_GP2D120(K6);

I get:

gcc plug-in: Error: Object file not found on expected location C:\Robotics\webtst\default\webtst.elf

and

avr-gcc.exe -I"C:\Robotics\webtst\..\..\WebbotLib"  -mmcu=atmega640 -Wall -gdwarf-2 -std=gnu99         -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT webtst.o -MF dep/webtst.o.d  -c  ../webtst.c
avr-gcc.exe -mmcu=atmega640 -Wl,-Map=webtst.map webtst.o   -L"C:\WebbotLib"  -lm -lWebbot-ATmega640  -o webtst.elf
c:/winavr-20081205/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr5\libc.a(floatsisf.o): In function `__floatunsisf':
(.text.fplib+0x0): multiple definition of `__floatunsisf'
c:/winavr-20081205/bin/../lib/gcc/avr/4.3.2/avr5\libgcc.a(_usi_to_sf.o).text+0x0): first defined here
make: *** [webtst.elf] Error 1
Build succeeded with 0 Warnings...

any idea whats going on here?

[Webbot]

This is what I think is going on....

My libraries were compiled using my version of win-avr - 13 March 2009. The Sharp IR libs use Admins floating point functions to convert the readings to a linear scale.

You seem to be using win-avr 5 December 2008 - ie a different version to my mine.

So I think its a winavr issue which is a bit of a downer. I'd foolishly assumed that their compiler would be backwards compatible ie not sure why 5 * 1.3 (or similar) should be compiler dependent - seems nuts to me

Any chance you can upgrade winavr by downloading from http://sourceforge.net/project/showfiles.php?group_id=68108

[Resilient]

This seems to be fixed by including the libc.a library.

Not sure if this should fix it... but if it should be there, some mention should probably be made in the documentation

Edit:
I will also update to the newer version of win-avr

[Resilient]

And one more question regarding pins.

The Axon is labeled oddly. Either F pins go from 0 to 15 or K starts at K8 and goes to K15. Or some combination thereof as seen here along the top row.

So how do I address these pins? I have assumed it goes F0 to F7 then from K0 on to K7 (the pin labeled F8 = K0 etc.), but I was getting some odd results using the IR sensors on pins K5 and K6. (the value of the sensor in K5 heavily effects the reading from pin K6, which makes me think these are not actually getting read right)

But if I use pins F0 and F1 it works fine.

Edit: err, this might just be something wonky going on with these damned IR sensors. I think I need some bigger capacitors for them.

[Webbot]

The numbers along the top from 0......15  are the 16 ADC channels on the Axon.

These are also accessible as I/O pins F0-7 and K0-7 respectively. ie ADC0-7 are also F0-7, and ADC8-15 are also K0-7.

I know that ADC8 onwards require special handling, which I have done in the lib, but perhaps need to revisit in case this is your issue. In which case you may currently have the same problem on ADC channels 8-15 (ie K0-7) for ADC input.

Thanks for the heads-up. Hope to spend time this week to fix this and your earlier UART problem but will keep this thread informed.

Am looking into libc.a issue and will update documentation as needed. Thanks for your help

[Resilient]

I would hold off on the IR stuff. It looks like its more of a hardware issue. It always seems to default to the reading of the highest numbered pin if any earlier pin is reading infinity.

so, if F0 should be reading infinity and F1 is reading 25, F0 will be pulled towards a reading of 25, even though it should be reading infinity.

I posted this problem over in the electronics forum, but just thought I would update you so you didn't try to fix something that may not be broken.

EDIT: testing suggests I might have been calling the sensor functions too close together, I added a delay and that seems to have fixed the issue.

[Webbot]

Have released version 1.2 at http://webbotavrclib.sourceforge.net/

Read Version.h to see whats changed.

NB Previous code will not compile. This is because I have replaced appInit with appInitHardware and appInitSoftware - and appControl can now return a value in microseconds (as discussed in this thread) The new documentation explains it in the intro sections and the example code has been changed to reflect these changes.

@Resilient - this should fix your Sabertooth issue (plz - let me know). But I'm very confused by your Sharp IR problem. Cant see why a delay would help (its just an A2D conversion) - unless the second sensor is detecting remnants of the first sensors light beam ie its a 'real world problem' rather than hardware/software.

[Webbot]

Have released version 1.3 at http://webbotavrclib.sourceforge.net/

Read Version.h to see whats changed.

The main differences have come about from trying to debug a Sabertooth motor driver in 'Packetized Mode'. Its a real swine. It auto-detects the baud rate from the first, and only the first, character you send it which is meant to be hex AA. Once set you cannot change it. So contact bounce on the Axon power switch, amongst other things, can mean that you accidentley send it a 'glitch byte' - and it then uses this to mis-guess the baud rate. Has taken an age to get right - and one side effect is that UARTs aren't now automatically initialised to a default baud rate. I've also discovered that if you have a level shifter, eg Max232 or others, in place at the same time for debugging via Hyperterminal then this can cause additional issues.

The whole Sabertooth library interface has changed a bit - in that MAKE_SABERTOOTH_DRIVER now has an additional parameter to allow you to select a protocol. This can either be SIMPLE (ie one byte per motor but limited to one card, or two motors, per UART) or PACKETIZED (the original design - ie many cards with one UART and now hopefully does the correct auto baud set up). If you are getting started then I'd suggest the SIMPLE mode to start with as it is not prone to these errors as the baud rate is set on the DIP switches.

Anyways - the docs now show up to date examples for both methods of control

Webbot

[Ro-Bot-X]

Webbot, how is the I2C slave going? did you have a chance to work on it?

I need to start testing the motor controller and without the library I can't do it. I have tested part of the controller code on Arduino, using their Wire library, but that doesn't fit in the tiny2313. So I have 2 options: use avrlib or bascom. Altho Bascom has a demo version that can program the tiny2313, I don't want to pay $15 for the hardware I2C Slave library. There is a third party hardware library for Bascom in (written in ASM) but it's in german and I can't understand how to use it. I could use the software library, but it takes too much space I can use for control code. I have no experience with avrlib yet so I don't know if I2C takes a lot of space in the flash and how to set it up to work as a slave.

Please let me know of your thoughts on this matter.

Thanks a lot.

[Webbot]

Webbot, how is the I2C slave going? did you have a chance to work on it?

I need to start testing the motor controller and without the library I can't do it. I have tested part of the controller code on Arduino, using their Wire library, but that doesn't fit in the tiny2313. So I have 2 options: use avrlib or bascom. Altho Bascom has a demo version that can program the tiny2313, I don't want to pay $15 for the hardware I2C Slave library. There is a third party hardware library for Bascom in (written in ASM) but it's in german and I can't understand how to use it. I could use the software library, but it takes too much space I can use for control code. I have no experience with avrlib yet so I don't know if I2C takes a lot of space in the flash and how to set it up to work as a slave.

Please let me know of your thoughts on this matter.

Thanks a lot.

I'm currently working on adding SPI support and, more specifically, MicroSD memory cards that build upon it. Which doesn't help you. My main issue with I2C being that I have no I2C slave hardware to test against. So I2C is still back burner as its hard to write support for something you cant test. I would also suggest that to make your board more commercial then you should look at something like the Sabertooth boards. They are excellent as they can be fed via a UART, a servo pulse, PWM etc etc let alone I2C or SPI or even an analogue signal. But flexibility like this requires a mcu with a lot of capabilities.

My current lib supports ATMega8,168,32,640 but, since it uses files from Atmel to auto-generate the files, then I have just tried it for ATtiny2313 and it works ok (some atmel files are rubbish and contain wrong data which I keep telling them about). ie my lib so far should support tiny2313 but is still missing I2C support. The main difference is my currently supported chips support I2C/TWI, SPI etc whereas ATtiny2313 uses Universal Serial Interface a kind of superset of stuff including I2C so would need some special handling anyway.

Afraid i know zilch about basic. Could you use AVRlib? - well maybe. I say 'maybe' because their code is targeted at a finite set of mcus which may, or may not, include tiny2313. eg some of their examples dont work on the Axon/ATMega640. The Atmel website is a good ref for specific code for specific chips. Whether its I2c/TWI or the tiny2313 Universal Serial Interface is probably important.

Just being a pain but 'why did you settle on the tiny2313, build the board, and then worry how to write the s/w and see if it would fit?'

Seems like SoR may be able to settle on a chip that is 'overpowered' for most modules but then go for bulk purchase to keep the cost down. By settling on a std chip, ATMega168 for example, then you could share libraries. ie portability vs saving a few cents.

So where now - if Bascom and AVRlib are not solutions for you then I could help you to write the software support (either in my lib or as a one off) but would need a sample card to do it and test it.

Hope that helps - but may just make you go 'aaaaaargh'.

Webbot

[Ro-Bot-X]

The main difference is my currently supported chips support I2C/TWI, SPI etc whereas ATtiny2313 uses Universal Serial Interface a kind of superset of stuff including I2C so would need some special handling anyway.

Actually, tiny2313 has TWI/I2C. Tiny861 that I wanted to use in the first place has USI.

Just being a pain but 'why did you settle on the tiny2313, build the board, and then worry how to write the s/w and see if it would fit?'

Well, stupid me. I wanted to use tiny861 because it has 8k flash and I could use arduino, but it has only USI and no UART. And I wanted to make the controller like the Sabertooth controllers. But in 2k it's going to be impossible, unless I'll do it in assembly (that I don't know).

Seems like SoR may be able to settle on a chip that is 'overpowered' for most modules but then go for bulk purchase to keep the cost down. By settling on a std chip, ATMega168 for example, then you could share libraries. ie portability vs saving a few cents.

Yes, I'll never use the tinys anymore, all boards will have a mega168 from now on.

Hope that helps - but may just make you go 'aaaaaargh'.

It surelly does.

But here is the thing. I got 2 boards. I'll send you one, perhaps you can help out with the code. Sure, I can buy that stupid bascom comercial lib and do it just for myself (can't make it open source...) so I don't throw in the garbage a good enough board. Just send me a PM with your address and I'll send it to you free of charge. All populated with parts.

Thanks for your time.