Isopod performance for 100 Mobile Robots

[jinx]

Hi,

Maybe this belongs more in the software section but it's about hardware performance so I post it here.

We've been evaluating the Isopod v0.6 for the past 6 months as a possible IO controller candidate for our new low-cost mobile robot platform for University research. We will be mass-producing more than a hundred of these by next year, when we finalise design and test the software control package.

Our experience with the Isopod so far has not been great. Though it boasts of an impressive list of features, we haven't really been able to squeeze what we want from it, with real-time robot control.

The first problem comes with the speed of the ADC sampling. We aren't able to get more than 30 samples per second, fromt the port, when our current requirements are at least 5Khz. We need this for inertial guidance using accelerometers.

We also need to send 10Hz sonar packets back to the main robot over serial. But the moment we do that, the serial line is chocked and the isopod responds to servo commands coming from the robot really late.

All this doesn't seem to be the performance of an 40-80Mhz processor.
I suspect it is also a problem with the way our code is organised. Maybe we aren't taking enough advantage of the Isomax parallel processing? We are using macros wherever possible to minimise state machine usage.

Since we need to finalise our candidate in the next 1 1/2 weeks, I was hoping that the NMI team would be able to help us out. It is critical that we get the I/O right, because we cannot recall 100 copies of the robot,once we give it for prodcution.

I am not pasting the code here since it's quite long. Is there some way I could mail it/post it separately so that you folks can take a look at it? Then you would be able to tell us whether the code is really causing the problem or whether the Isopod is not capable of giving what we're asking from it.

We really like the Isopod features and programming style and would be really sorry to have to let it go. Hence this urgent post for help.

thanks for your time,

regards.
jinx.

[nmitech]

Please email me, techsupport@newmicros.com your program, i will make a link to it for other to download and help

[RMDumse]

Originally posted by jinx

I suspect it is also a problem with the way our code is organised. Maybe we aren't taking enough advantage of the Isomax parallel processing? We are using macros wherever possible to minimise state machine usage.

Of course we'd be happy to help you if we can. Yes, it does sound like there may be a code organization problem, because, the A/D is capable of more than 500,000 conversions a second.

Using PCC's (Program Counter Capture) loops will break the IsoMax(TM) Isostructure paradigm, and cause poor performance. If the macros use BEGIN UNTIL or DO LOOPs to wait, the performance of the system will be wasted waiting instead of applied where needed.

I will look forward to seeing your program when you email it to nmitech, and offer what comments I may, then.

[RMDumse]

I've been playing some with your mentioned problem, that is, of having a high speed data requirement (5000 times a second) and a low speed reporting requirement (10 times a second) and using a loop index to count down from the high speed requirement to launch the low speed requirement.

I often get TCFOVFLO flags when the slower reporting reguirement runs. (Formating numbers in the current base is a slow process with many divisions.)

This is an interesting problem and deserves some more study.

[jinx]

Thanks for all your prompt responses. I will mail you the code by tomorrow. I am going thru it once more to make sure there are no loose-ends on my part. I will also be sending you complete documentation so it will help debug it faster.

thanks again,

regards,
jinx.

[RMDumse]

Just a note on programming style. I've been reading your code. I notice you usually work in DECIMAL and sometimes ahead of a decimal value inside a definition you will put DECIMAL in the definition. That's probably not what you want.

You see, inside a colon definition, the inclusion of DECIMAL will put the machine in the decimal number base -at run time- not while the word is being compiled. To choose decimal number base so a value inside a definition will be -translated- as a decimal at compile time, you need to either say DECIMAL before you begin the definition, or, to turn off compilation, then run DECIMAL, then turn compilation back on.

See if this helps. When you write : X + ; you don't expect + to add numbers until X is run. Same with this : Y DECIMAL 10 ; DECIMAL doesn't happen until Y is run, so the 10 is compiled in the base which was active before the : Y compilation started. So if this was the set up HEX : Y DECIMAL 10 . ; you'd get the hex value 10 compiled, but when Y ran, it would switch into DECIMAL, then get the compiled value (a binary is compiled, neither hex nor decimal persa) and then print it in base 10, so your output would be 16.

Now what do I mean by turning off compilation, then run DECIMAL, then turn compilation back on? The square bracket words do this. Use [ to turn off a calculation and ] to turn it back on. So if you did HEX : Y [ DECIMAL ] 10 . ; when Y ran if you were still in DECIMAL you'd print 10, not 16. However, if you switched to HEX and ran Y you'd print A, not 10.

So there's two issues, one is what base your compiling in, and another which one your printing in. IF you want to really be sure to print 10 in this example, you could do both. HEX : Y [ DECIMAL ] 10 DECIMAL . ; and then when Y ran, you'd print 10 for sure.

Okay, I'll have other suggestions, but this is something I notice in your INITISOPOD word right off, and repeated several other places.