PIC - Code for non-linear servo responce?

[Gary Warner]

I have an AOA project from 1998-1999 and I've decided to pick it back up again. I'm addressing some problems I had.

One of the issues is the need to correct the servo response with a non-linear rate. In the project I made before, I used a linear response curve. I can think of several methods, but I'd be interested in hearing what your ideas are.

Details of the project can be found here (http://web2.airmail.net/warner1/aoa1.htm).

Gary
--

[Mr.RC-CAM]

If simplicity is needed, I would code the PIC with a look up table (LUT). You can create one 256 byte LUT that represents both sides or your symmetrical curve. This will provide 512 step resolution.

The nice thing is that fast processing times are not needed since the math is just some integer work to derive the table's offset value. Your table can provide complex shapes without having to create math models.

RC-CAM

[Gary Warner]

I agree. I had thought of this, but I've never used LUT's on a PIC before. And you also make a good point about the lack of math - that's a good thing. ;)

Also, the curves can be adjusted without sifting through all the code. If I move up to a 4k memory chip, I should have enough room for the lookup table. I considered an I2C EEPROM for storing the table, but was afraid it would eat up my processing speed. Do you think an I2C solution would be practical considering I need to loop on every frame cycle with headroom?

Thanks for the input. Now to 'learn' the use of LUT's...

Gary
--

[Mr.RC-CAM]

You would have sufficient time for an I²C solution. But, I think that keeping the table inside the PIC is the way to go. This will simplify the hardware and software.

RC-CAM

[Gary Warner]

The reson for the thoughts about the I2C was that an assortment of LUT's could be put into cheap chips, then field replaced. I have about 100 24C02's on hand. A final product could then have the data in the CPU. If you think there will be enought time in the loop cycle, maybe I should try this for R&D.

[Mr.RC-CAM]

For R&D the external LUT table sounds great to me.

RC-CAM

[Texy]

Yep definately the way - use excel, or some other spreadsheet, to calculate your values on the PC then cut & paste them into mplab, (or your programming s/w of choice) for programming into the serial eeprom.

Texy

[vintage1]

LUT definitely for speed.

Multiplication is a bit of a dog speed wise on any processor, BUT shifting (mutiplying times two) ain't too bad :D

I've hard coded two shifts and an add before now to get a times 5, and add another shift to get times ten....

For really crude stuff something like

IF MOD (value) > first_point
THEN value =((value-first_point) << 2)+value

Which will give you a sort of straight line with two slope values on it.

You can do a piece wise approximation to various curves and its a bit more amenable to quick changes without rewriting a whole LUT.

The secret of real time coding is to understand what the processor does well, and use that. Not try and make it conform to the maths that YOU find easy.

You can also e.g. code the whole 8 bit multiplication table into 128kbytes of ROM...
...or use a mixture of LUT and do linear interpolation between basic points.

[Quacker]

Gary,

I've been toying with various AOA project ideas for some time. Can you tell me what type of sensing you are using?

Thanks,
Q