Micromouse book
Categories
Recent Comments
Meta
Popular Posts
- Simple ADC use on the STM32 (4,106)
- STM32 Arm-Cortex bootloader (2,803)
- STM32 USART basics (2,703)
- All Japan Micromouse 2011 – finals (2,011)
- STM32F4 – the first taste of speed (1,690)
- Micromouse Book (1,587)
- Nokia 3410 LCD on the STM32 (1,337)
- CodeSourcery GNU Toolchain for the ARM on a Mac (1,145)
- Bit Banding in the STM32 (1,045)
- ARM STM32 JTAG (973)
Blogroll
-
Upcoming Events
Tag Archives: PWM
Line Follower First run
All the bits are together and the processor code tested. Bob should know when he is on track and how far out he is when he is off track. Time to get him running on the test track…
For this first run, the control was kept very simple. If the position error is positive, Bob needs to turn right. If it is negative, he needs to turn left. Turning is accomplished by removing power from the appropriate motor.
Well, that isn’t too impressive is it. Not that I expected much better at this stage. A couple of things worry me a bit though. The amount of wobble on the straights indicate that there is a lot of inertia and plenty of overshooting. The control loop is running at about 200 Hz and the frequency of overshoot is a couple of hertz. When I put Bob together, I though that having the wheels at the rear and the sensors way out in front would be a good thing. However, the batteries are well ahead of the wheels as well and have quite a bot of mass. The other thing is that, in the turns, the robot is only just turning fast enough to keep up with the turn even though one motor is off most of the time. Apart from the expected oscillations, this may also be due to the fact that the motor is driven from single transistor so there is little braking available. Once the PWM is turned off, the motor can freewheel so turning is not as sharp as it would be if the motor were braked. It may be necessary to replace the motor driver with a bridge to get better control. Finally, it is much noisier than I anticipated. Not serious in terms of performance but it wakes up the dog and, trust me, it is better to let this particular sleeping dog lie.
Revised schematics and pin functions
After a bit more thought, there is now a new set of pin assignments for the Primus micromouse, along with a corresponding schematic.The problem with Primus was that it is not possible to generate two independant pulse trains from the PWM generators. All the PWM channels have to share a common time base.The Output Compare peripherals on the dsPIC30F4011 can generate up to two independant pulse trains in hardware but one of the time bases must come from Timer 2 which is needed for counting steps sent to the motors. One of the fundamental design decisions on Primus is to drive the two steppers at high speeds without any interrupt service routine soaking up processor cycles.It seems that one motor will have to be driven from an OC channel and the other from a PWM channel.The PWM channel is fairly straightforward, we just set the duty cycle to something appropriate, like 50%, and change the frame rate to get a square wave at some arbitrary frequency. steps are always made on the leading edge of the pulse so the actual duty cycle is not too important as long as the pulse satisfies the minimum leng specified for the driver chip. This is 2us so we have plenty of scope.For the other motor, one of the OC channels (OC1) will take its time base from the currnetly unused Timer 3. OC1 will be configured to generate short pulses at the start of each cycle. Again, only the leading edge is significant so we just need to make sure that the pulses are at least 2us long.This is not as elegant as I had hoped. the limitations of a 40 pin device start to bite here. Other devices in the family with more pins (but surface mount) give access to a couple more counter inputs and would make the problem a lot more simple. Just to add an extra layer of complication, I amtrying to arrange the pin functions so that conversion to a DC motor driven mouse will be easier. It might have turned out simpler if I had not bothered!The previously published schematics and pin functions have been updated and are available here:Mainboard SchematicsPin function list Continue reading
A bit of a change to Primus
It seems I made a bit of a mistake in how I thought the dsPIC could drive its PWM module. Consequently, there will have to be some changes.First, what can’t change is the need to use T1CK and T2CK as external inputs to count motor pulses. There are no other choices on the dsPIC30F4011 without using interrupts. Since I anticipate pulse rates of up to 100,000 Hz per wheel, life will be a lot easier not having to service that interrupt rate, even with a fast processor and a very efficient ISR.
Somehow, I had it in my head that the PWM module could use different time bases for each channel. Wrong – and stupid. So, how to produce two independant pulse trains at frequencies from about 500Hz to 125kHz?Well, the dsPIC has a set of Output compare modules. These are quite capable of the job and have a variety of useful modes. Each can use one of two 16 bit timers for its timebase. At first sight, it would be best to use the OC modules for both motors and have each derived from a separate timer. Unfortunately, the two timers we can pick form are Timer2 and Timer3. But we have already committed Timer2 to the pulse counting job. That means that only one OC module can be used and it must be driven from a timebase using Timer 3.This all makes things a bit tacky. The pin assignments are now a little more confusing and earlier posts will need to be edited along with theschematics and such. Hopefully this will be done by the time anyone gets to read this post. Apologies if anyone has done any work based on the errors. Continue reading
Add to Google