Need help determining just how much mCU power I need for 4 Quad Encoders
rwgast_logicdesign
Posts: 1,464
Ok so for those of you who dont know what im up to here is a quick run down. Im building a robot, as a huge learning project, but im trying to separate the tasks out between different micro controllers for two reasons #1 it forces me to get familiar with programming various micros and #2 it will leave the brain prop totally empty so I have the most bang for the buck where I need it.
Now one piece of this bot is a custom motor controller board, which is also used to monitor the current/voltage/temp of the battery pack. Originally it was planned that this board would do all the PWM generation for the motors along with reading the encoders and doing wheel odometry I chose to base this board around an atmega168 with the Arduino boot loader installed. The reason I went with arduino is because its quick to code and learn, it has a built in ADC for the battery measurements, and also a propeller seemed like overkill for these few tasks.... Well getting more familiar with the arduino and how things are done im thinking it doesn't have enough power to do what I want to do. I didn't realize just to count encoder pulses I would have to increment a variable on an interrupt every time the encoder sent a pulse out, because id be using almost all the avr's timers to generate PWM signals. Now I want to make this board capable of handling 4 motors. Doing the math at 240rpm I would need to run 4512 interrupts per second to read 4 quad encoders. This just seems like a disaster waiting to happen. So now im rethinking my whole system, maybe ill just leave the atmega there for battery control stuff only, and switch to a second propeller for motor control and odometry, then again maybe I could let the Arduino handle the PWM and battery since its already there doing all that stuff and the code is written, then stick with one prop as planned, connect the encoders to it, and do the odometry on it. To make my decision even harder I just got a free stmf3 arm board in the male a few days ago, and it has a built in 3 axis compass, 3 axis accelerometer, and 3 axis gyro (which is one thing im missing) so it wold be perfect as a motor controller/odometry board with its 12 counters and interupts on every pin at 72mhz, but its going to be a big involved pain to get working i bet.
So I guess what im asking you guys is how much power will I need to run eight 141 pulse per revaluation encoder channels at 240rpm+, and at maximum resolution. The encoder pulses once per motor revalution, and there's 141 motor revalutions, in one revaluation of the gearboxes output, So I guess if you count rising and falling edges thats 282 ticks per revalution so on 8 channels that would be 2256 encoder tick per revalution. How many cogs/counters will this use up on a prop, can spin handle it alone, does this even sound feasible on the poor avr/arduino 9024 interupts per second? Ive attached a screen shot of the prop scope measuring one quadrature encoder, just to give you guys a sense of how fast the encoders are. Im sorry I accidentally had VLC on top, but the shot shows the frequency and everything else important, I had put everything away before I realized I never closed VLC
This is also under no load with no wheel attached a full battery so its the extreme maximum the encoders will ever put out, more than 240 rpms Im sure. Basically at the moment I have no idea what im doing as far as the code for the prop, all I know is I want to write most of it myself no matter what chip I use for this, and I want to take the best route possible as far as the hardware for this. I just want to figure out what to use so I can get it built and finally start coding!! But I dont want to do something stupid like hook the encoders up to the main prop and find out all the wheel odometery and encoders are gonna hog over half the chip or something, not leaving enough cogs for all the other goodies. Ive already pro typed the whole board using an the atmega, and im glad I didnt hastily solder the whole thing together expecting it to handle the wheel encoders, im trying to avoid things like this. Ive already payed wasted to much time making these kinds of mistakes on the mechanical side of the bot,
Also right above the frequency the prop scope shows 1.46ms, what is that number, the length of a full on/off cycle?
Now one piece of this bot is a custom motor controller board, which is also used to monitor the current/voltage/temp of the battery pack. Originally it was planned that this board would do all the PWM generation for the motors along with reading the encoders and doing wheel odometry I chose to base this board around an atmega168 with the Arduino boot loader installed. The reason I went with arduino is because its quick to code and learn, it has a built in ADC for the battery measurements, and also a propeller seemed like overkill for these few tasks.... Well getting more familiar with the arduino and how things are done im thinking it doesn't have enough power to do what I want to do. I didn't realize just to count encoder pulses I would have to increment a variable on an interrupt every time the encoder sent a pulse out, because id be using almost all the avr's timers to generate PWM signals. Now I want to make this board capable of handling 4 motors. Doing the math at 240rpm I would need to run 4512 interrupts per second to read 4 quad encoders. This just seems like a disaster waiting to happen. So now im rethinking my whole system, maybe ill just leave the atmega there for battery control stuff only, and switch to a second propeller for motor control and odometry, then again maybe I could let the Arduino handle the PWM and battery since its already there doing all that stuff and the code is written, then stick with one prop as planned, connect the encoders to it, and do the odometry on it. To make my decision even harder I just got a free stmf3 arm board in the male a few days ago, and it has a built in 3 axis compass, 3 axis accelerometer, and 3 axis gyro (which is one thing im missing) so it wold be perfect as a motor controller/odometry board with its 12 counters and interupts on every pin at 72mhz, but its going to be a big involved pain to get working i bet.
So I guess what im asking you guys is how much power will I need to run eight 141 pulse per revaluation encoder channels at 240rpm+, and at maximum resolution. The encoder pulses once per motor revalution, and there's 141 motor revalutions, in one revaluation of the gearboxes output, So I guess if you count rising and falling edges thats 282 ticks per revalution so on 8 channels that would be 2256 encoder tick per revalution. How many cogs/counters will this use up on a prop, can spin handle it alone, does this even sound feasible on the poor avr/arduino 9024 interupts per second? Ive attached a screen shot of the prop scope measuring one quadrature encoder, just to give you guys a sense of how fast the encoders are. Im sorry I accidentally had VLC on top, but the shot shows the frequency and everything else important, I had put everything away before I realized I never closed VLC
This is also under no load with no wheel attached a full battery so its the extreme maximum the encoders will ever put out, more than 240 rpms Im sure. Basically at the moment I have no idea what im doing as far as the code for the prop, all I know is I want to write most of it myself no matter what chip I use for this, and I want to take the best route possible as far as the hardware for this. I just want to figure out what to use so I can get it built and finally start coding!! But I dont want to do something stupid like hook the encoders up to the main prop and find out all the wheel odometery and encoders are gonna hog over half the chip or something, not leaving enough cogs for all the other goodies. Ive already pro typed the whole board using an the atmega, and im glad I didnt hastily solder the whole thing together expecting it to handle the wheel encoders, im trying to avoid things like this. Ive already payed wasted to much time making these kinds of mistakes on the mechanical side of the bot,
Also right above the frequency the prop scope shows 1.46ms, what is that number, the length of a full on/off cycle?
1024 x 819 - 132K
Comments
If you read the encoders from a seperate MCU from the one you use for motor control you will need relatively high speed communication between the two MCU's in order to keep the motor controller updated with the latest encoder values which just adds more overhead.
Some things to research and think about:
- Quadrature Decoding (this will get you count info that properly increments/decrements the counter based on motor direction)
- PID Control (I often get by using just the P term) You can use scaled integer values in your calcs, you don't need floating point.
You should be able to easily put all the Quadrature Decoding in a single COG, keep the count values in the HUB for easy access by the motor control COGS. Use a single COG for each motor using the counters to produce your PWM, use another COG for communications to whatever you are using to control the robot.
C.W.
First thing is you think that one cog will be enough to handel all 8 encoder channels without missing a beat, theoretically 9024 counts a second? I'm going to go through JMacs Nuts and Volts Encoder PDF today and use a hand encoder to get a feel for how to do quadrature decoding on a prop, rather than a more conventional style processor with interrupts. Thats really good to hear that only one cog is needed though.
Second thing is if I use the same propeller to generate the PWM signals with counter, why would each motor need its own cog?? Driving all four motors seems like an easy enough task for less than a cog, the hardware counters are doing the real lifting here correct? Im just setting up a frequency, a duty cycle, then flipping pins hi and low to get the motor going the right direction.
Now what I was thinking if I seperate the encoders on a different mCU than the actual motor control I should be fine as far as syncing them together The plan would be to send serial data to the avr like "wheel1 255,255" at 115200bps. Basically the prop would handle all the odometry then just tell the AVR what to do with the motors, does this not seem reasonable? I know ive seen serial motor controllers out there im just not sure how they integrate in to a closed loop feedback system. In my mind it seems less important the motor control is on the same mCU as the encoders, and what seems very important is that things like the compass and accelerometer are on the same mCU as the encoder so there feedback can be used to help generate theta in the odometry equations.
Please let me know if any of what I just said seems way off the mark, like I said I dont want to do things wrong, these are all just detail im curious about. In the end im starting to thiink using the AVR for battery stuff only then using a dedicated prop to take care of motor control and all odometry is going to be the very best solution here. This will give me tons of processing power for hi accuracy odometry, then the planned propeller/rPI combo can control the rest of the robots functions and sensors.
An assembly routine could easily handle well in excess of 10K counts per second. Remember that a cog running assembly can handle serial I/O at over 1MB.
Each Quadrature Decoder (QD) can be build as a simple state machine in PASM, if you run a loop that processes all four state machines at 5K loops/sec you should be in good shape.
What you want to do is sample the state of the QD pins at a rate faster than the state changes.
From the data you provided: 240 wheel rev/min * (141 * 4) states/rev / 60 sec/min = 2256 states/sec.
So sampling at 5K should be good. Remember you can sample all 8 pins in one read on the pin status and then process each QD pair through it's own state machine to update the 4 counters.
The nice thing about sampling at a fixed rate vs. interrupts on pin changes is that you aren't triggering interrupts based on noise if the encoder is stopped on an edge and toggling.
C.W.
My Mecanum wheeled robot reads all four quadrature encoders with one cog. I haven't posted my latest code yet but I'm pretty sure what I have posted includes the four quadrature encoder code.
I used JonnyMac's technique and added code to average the speed over several encoder reading cycles. I used the two motors per cog technique to control the motors (Kye's PWM code). I'm working on some code to run all four motors with one cog.
I think I got the four PWM channels in one cog code working on its own but I haven't be able to incorporate into my larger program. I'll find the four channel code and post it here soon.
In the PASM you'd have a loop that does this (after setup, of course)
1) Read/set motor 1
2) Read/set motor 2
3) Update encoders, report to hub
4) Wait for end of pwm period
5) Back to 1
By using the counters to handle the pulse to the motor you have the almost the entire pwm period to do other work.
Easy-peasy!
Nope. The counters are mapped into the cog RAM space hence are only accessible from inside that cog. You'll need a second cog for the other two motors. You may as well create an object that handles two motors and four encoders and then use it twice. By creating an empty pin mask your second object would never have any encoder values to report.
As others have said, you can't do it that way but if you have a cog running a loop that has some spare time in each loop, you could add a call to a PWM update method. So you can kind of squeeze in the PWM without having much of an impact on the host cog but the host cog does need to take care of updating the PWM parameters.