Performing a loop every 10ms

[wasssup1990]

Wow, thankyou for all of your replies.

I forgot to mention that my crystal is 20MHz and both CCP1 and CCP2 are being used for HPWM.

I found PicMultiCalc and it is saying that I can use the 8-bit timer (Timer0) for an error of 0.371%. It says that if I use the 16-bit timer I will get an error of 0%. Now I have decided that I will use the 16-bit timer only if it won't interupt my HPWM. The HPWM is driving two motors. I am not at all familure with these timers and I don't know how to set them up or know when to start my 10ms loop so that the gyro can be read at the start of every loop at 100Hz (10ms intervals). Integration calculations and other processes are carried out after the gyro has been read. If all calculations and procesess have been done before the next loop should start, the processor should wait until the timer flag or whatever signals the loop to start over.

FYI I am making a balancing robot.

[skimask]

Wow, thankyou for all of your replies.

Said it before, I'll say it again...
Start simple...
Get the LED blinking at a known rate under an interrupt drive (or just get an LED blinking ), get the HPWM working on all channels in all situations, get the interfaces working, THEN tie them all together.
Otherwise you'll be shooting yourself in the foot wondering why...no more...just wondering WHY!!!!

[wasssup1990]

Well ok; so it's just a trial and error thing then? I'll just experiment with the PICMULTICALC values by plugging them into the right registers and i'll see how I go. BTW I have no idea of how to use an interupt. Anyhelp in using interupts in PBP relating to what I need will be very much appriciated.
I was hoping someone here has done what I want done before. Or perhaps someone could link me somewhere, but thanks for all of your help.

[skimask]

Well ok; so it's just a trial and error thing then? I'll just experiment with the PICMULTICALC values by plugging them into the right registers and i'll see how I go. BTW I have no idea of how to use an interupt. Anyhelp in using interupts in PBP relating to what I need will be very much appriciated.
I was hoping someone here has done what I want done before. Or perhaps someone could link me somewhere, but thanks for all of your help.

The old 'inverted pendulum' trick has been done a lot by various people using various processors...but in the end, it's all up to the guy behind the keyboard.
Read the book, work your way up to it...otherwise, again, your foot will end up with holes in it...

[Acetronics2]

FYI I am making a balancing robot.

You should browse the parallax site ...

They already did it ( and they share it !!! ) ... and moreover their basic is PbP compatible !!!

... at least TONS of understandable solutions to your headaches ...

Alain

[wasssup1990]

I saw that balancing robot on the paralax website. It doesn't use a gyro and an accelerometer. Useless on a sloped surface.

[skimask]

I saw that balancing robot on the paralax website. It doesn't use a gyro and an accelerometer. Useless on a sloped surface.

Differential GPS, one on each corner of a 4 cornered base... Solves everything!

[wasssup1990]

Ok I got the timer going, but brace yourself for a possible kalman filter question. I havn't found a single website that can explain kalman filters in laymens terms.

[skimask]

Ok I got the timer going, but brace yourself for a possible kalman filter question. I havn't found a single website that can explain kalman filters in laymens terms.

And you probably won't find one.
Best explanation I can offer is that a Kalman filter makes a best 'future guess' based on the accuracy of it's past 'future guesses'.
If the Kalman filter isn't sure of itself, it's 'future guess' goes out the window.
I remember this from working the INU's on -130's. Ring Laser Gyro based INU's. The aircrews wouldn't believe the INU's position, so they'd update the things fairly often from TACAN or RADAR or whatever, even handheld GPS's. Then they'd whine when they got back because the INU would start drifting really badly inflight. The crews would come back and whine, we'd explain to them that they had ruined the INU's confidence by telling the INU it wasn't where it thought it was even though the difference between where the INU thought it was and where the crew told it that it was was very small. But of course, the aircrews knew better, because they're officers, and have degrees right?
We'd have to go out and run a ground align on the INU about a half a dozen times and each time, just let the INU cook by itself for awhile to build up it's confidence. At first it would sit there and drift away from the spot the aircraft was on. After a couple of time, the drifting would get less and less and eventually, it wouldn't drift at all.
But all that explanation doesn't help a person write any code now does it?

[wasssup1990]

This post above and the post about the PicMultiCalc have been the most usefull to me in this thread. PicMultiCalc taught me a little bit of how timer0 works, and the post above taught me in laymens terms what the kalman filter does. The post two poitions up by Acetronics is not usefull and this person has probably no life. (:

[Acetronics2]

I saw that balancing robot on the paralax website. It doesn't use a gyro and an accelerometer. Useless on a sloped surface.

... ROFL !!

THEY show you how to interface with the sensors, YOU write the program for your own requirements and dreams, with YOUR sensors.

Not just a cut and paste party ...

Alain