Shop OBEX P1 Docs P2 Docs Learn Events
Mecanum Wheeled Robot with Machine Vision - Page 4 — Parallax Forums

Mecanum Wheeled Robot with Machine Vision

12467

Comments

  • ercoerco Posts: 20,244
    edited 2013-02-27 17:39
    amano001: Initially you said you were using CR servos, but your latest posts talk about a 4-channel DC motor controller. Which are you using?

    You can read Duane's love/hate relationship with the Rover 5 chassis in several of his threads. Looks neat, but pretty flexible, which may cause problems once the weight of the vehicle creeps up. Especially since mecanum wheels push & pull your wheels in all directions. Looks like your bot is getting heavy, so you might consider a different chassis. Even a hunk of plywood! http://www.youtube.com/watch?v=rAgiYtwuWB4

    BTW, I'm a staunch advocate of slow, torquey DC motors with lots of gear reduction, because they will be pretty closely matched, RPM-wise. I've had good results with my simple mecanum bot, which doesn't even have encoders yet: http://www.youtube.com/watch?v=RPIfIOat6Os
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-02-27 18:51
    I want to point out I was wrong about the 5V regulator. The Propeller Proto Board does indeed have a 5V regulator.

    I know I was thinking to myself as I clicked the link "I'd use a QuickStart of a Propeller Project Board if I were amano001." When the board wasn't a QuickStart my brain hallucinated a Project Board (it's the same size as a Proto Board). (Don't tell anyone about my hallucination, it's kind of embarrassing. Especially not erco!)

    The reason I'd suggest the Project Board over the Proto Board is the Proto Board requires a Prop Plug to program it. There are lots of Propeller board that require a Prop Plug for programming but if you're only purchasing one board then a board with built in USB makes more sense. Both the QuickStart and the Propeller Project Board have on board USB and can be powered by the USB connection.

    Here's a regulator I use when I need 5V on a robot.

    I agree with erco about your robot starting to look a bit on the heavy side. One thing that might help is the use of a higher voltage battery pack. I originally used a 2 cell LiPo to power my robot but I had so many more 3 cell LiPos (used with my quadcopters) that I started using a 3 cell with this robot. The 12 Volts (probably dropped to 10V after the motor controller) is higher than the motors 7.2 volt rating but it's nice to have the extra power. I figure I'm shortening the life of the motors but I don't run the robot for very long when I use it so I thought risk wasn't too bad.
  • amano001amano001 Posts: 47
    edited 2013-02-27 19:36
    Hey guys, THanks for all the info. I think I definetely WIll go the way of slaving out the board. That way I can use the arduino to deal with ultrasonics making sure the robot stays parallel to the wall. I have a quickstart board I bought for myself originally to play with and then I ordered the board with the 5v regulator but im starting to rethink my purchase since we just going to use it as a slave board. Also I already have a FTDI connector from an arduino I built myself from a kit, so I dont have to worry about getting the prop clip.

    The previous robot we had built was using servos but now we switched over to the rover 5 chassis w/ motors because the shafts were starting to bend and cause slow down. The robot is a little heavy with the arm we wired up 2 in parallel 7.2v Nicad batteries for power and then we break down that power with 2 different 5v regulators for different parts. Running it off the board itself was just making it easier and less wires going everywhere but if we have to we will just add another temrinal block to run the servos and sensors off of.

    Thanks for the info on the 3.3 logic we just wanted to make sure before we blew something up lol.

    I am looking over your code now that you have uploaded, We are very short on time so it will be a lifesaver to not have to learn the propeller stuff right away and just use it as an integrated part of our robot.

    Thanks and I will keep you updated on how things are going, the computer vision is a pain in itself.

    Also wanted to ask you our logic behind making sure the robot is parallel with wall is using 2 ultraonics one on each corner and determining the distance they are off by parallel being u1-u2 = 0 if they are the same distance from the wall therefore they are parallel. If u1-u2 <0 means left side of robot is going faster then right side and opposite case for u1-u2 >0 . Do you think this is overthinking the process? We need to be very precise when the robot moves into positions on a board.

    U1| Let Side Robot <======
    |
    |
    |
    U2|
  • amano001amano001 Posts: 47
    edited 2013-02-27 22:38
    Maybe I could just use a compass....hmmmm might be easier then having to deal with ultrasonic mess ups when theres weird angles or things in the way.
  • amano001amano001 Posts: 47
    edited 2013-02-28 20:09
    I am having a horribly hard time getting this to work lol. I can't seem to figure out how to program which pins are going where from the motor controller. Enc 1 = A and B signals and ENC 2 = A and B Signals I put into pins3 and 4 on my parallax and I get a static changing value so if I spin the wheel forward it counts up and reverse counts down which seems to be working I think but I never set any pins unless 3 and 4 are defaults pins for the encoder[1]. I cant seem to find where to set the motors pwm pins either.

    Let me know if your available for a skype pow wow, my skype is mayong972
  • ercoerco Posts: 20,244
    edited 2013-02-28 20:44
    Everyone loves Duane. He's a very helpful fellow!
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-02-28 21:44
    amano001 wrote: »
    I am having a horribly hard time getting this to work lol. I can't seem to figure out how to program which pins are going where from the motor controller. Enc 1 = A and B signals and ENC 2 = A and B Signals I put into pins3 and 4 on my parallax and I get a static changing value so if I spin the wheel forward it counts up and reverse counts down which seems to be working I think but I never set any pins unless 3 and 4 are defaults pins for the encoder[1]. I cant seem to find where to set the motors pwm pins either.

    Let me know if your available for a skype pow wow, my skype is mayong972

    I have a bunch of instructions in the top object "Demo4WDBot13026e.spin".

    Here's the section about setting encoder and motor pins:
    ******* Setup Instructions *******
    
      This object is intended to be easy to use with multiple
      robots.
      The settings for a specific robot are held in a "Header"
      file. This file should be modified to reflect the
      setup of each robot.
    
    
      ******* Motor/Encoder Setup *******
      The pins used to control the motors, and those used
      to receive encoder pulses, should be set in the header
      file.
      
      The motors/encoders are numbered starting with
      zero in the front left, motor #1 is in the front
      right, motor #2 is in the rear left and motor #3
      is in the rear right of the robot.
      
      Any free I/O pin may be used to control the motors.
      The direction the motor turns may be adjusted
      by switching "WHEEL_RED_x" and "WHEEL_BLACK_x" constants.
      
      The quadrature encoder pins need to be grouped together
      in pairs. Each quadrature encoder output should be
      connected to two consecutive I/O pins. The order of the
      two pins within the pair is not important. The direction
      sensed by the encoders may be adjusted with the
      "FORWARDx" constants.
    

    The pin settings are in the file "HeaderMecanumQs_130226a.spin".

    Here's the section:
    WHEEL_RED_0 = 17         ' The "RED" constants don't have to be assigned to  WHEEL_BLACK_0 = 18       ' red wires. It may be useful to switch the pin
      WHEEL_RED_1 = 21         ' assignments if the wheel direction doesn't match
      WHEEL_BLACK_1 = 20       ' the encoder directions.
      WHEEL_RED_2 = 23         ' Set to "-1" if a motor isn't being used.
      WHEEL_BLACK_2 = 24       ' If any of the three motor control pins is
      WHEEL_RED_3 = 27 '26     ' is set to -1, the motor will not receive a PWM
      WHEEL_BLACK_3 = 26 '27   ' signal.
      
      FIRST_ENCODER_0 = 0     ' The next I/O pin higher will also be used.
      FIRST_ENCODER_1 = 2     ' Example: the encoder for motor #1 will use pins 2 and 3.
      FIRST_ENCODER_2 = 4     ' Set to "-1" if a motor isn't being used.
      FIRST_ENCODER_3 = 6
      WHEEL_ENABLE_0 = 16 
      WHEEL_ENABLE_1 = 19  
      WHEEL_ENABLE_2 = 22 
      WHEEL_ENABLE_3 = 25
    

    The constant "WHEEL_RED_0" should be set to one of the two pins that control the front left motor. On my motor control PCB it's marked "IN1". "WHEEL_BLACK_0" connects to the other motor controller pin ("IN2" on my board).

    Don't worry about which way the motors spin to start with. You'll want to get the encoder directions figured out first and then come back and set the motor pins so they agree with the encoders.

    I've made it so you don't have to switch encoder wires or motor wires if you don't want to. The directions of both the encoders and motors can be set with the constants in the header file. Depending on your setup, it might be easier just to switch wires rather than changing constant values.

    During this initial setup phase, you'll want to make sure the line"INPUT_TYPE = PC_ONLY_INPUT" is not commented out. Here's the section of code to look for.
    ' inputType enumeration  #0, PC_ONLY_INPUT, WII_NUNCHUCK_INPUT, RC_INPUT, WII_AND_RC_INPUT, AUTO_DETECT_INPUT
    
    
      INPUT_TYPE = PC_ONLY_INPUT       '' Use this when first setting up robot
      'INPUT_TYPE = WII_NUNCHUCK_INPUT   
      'INPUT_TYPE = RC_INPUT
      'INPUT_TYPE = WII_AND_RC_INPUT    '' Not yet supported. If used it will behave the same
                                        '' as AUTO_DETECT_INPUT.                                                                                                                                            
      'INPUT_TYPE = AUTO_DETECT_INPUT   '' Priority given to Nunchuck
    

    You shouldn't need to change this since the appropriate line is already active.

    I did notice a section of code in the header with an incorrect setting.
    ' wheelMode enumeration  #0, INDEPENDENT_WHEELS, TREADED_WHEELS, MECANUM_WHEELS 
    
    
      'WHEEL_MODE = INDEPENDENT_WHEELS '' Use this when first setting up robot
      WHEEL_MODE = TREADED_WHEELS     '' The target speeds of each side will be matched.
      'WHEEL_MODE = MECANUM_WHEELS    
    

    I'm not sure why I had the active mode set as "WHEEL_MODE = TREADED_WHEELS".

    While you're setting up your robot, you should change the above code to:
    ' wheelMode enumeration  #0, INDEPENDENT_WHEELS, TREADED_WHEELS, MECANUM_WHEELS 
    
    
      WHEEL_MODE = INDEPENDENT_WHEELS '' Use this when first setting up robot
      'WHEEL_MODE = TREADED_WHEELS     '' The target speeds of each side will be matched.
      'WHEEL_MODE = MECANUM_WHEELS    
    
    
    

    This will let you control the speed of each motor independently from the rest of the motors. You'll probably want to keep it set to "INDEPENDENT_WHEELS" when you're sending it instructions from your other microcontroller.

    While you're in the header file, you'll want to set "PROPORTIONAL_CONSTANT" to zero while you're setting up the motor and encoders. This will keep the motors from spinning at full speed if the encoders' directions don't match the motors' directions.

    You'll want to make sure and use resistors between the Rover 5's encoders and Propeller's I/O pins.
    ******* Note About Wiring *******  
       Each encoder pair needs to be connected to two consecutive
       Propeller pins.
       10K&#937; resistors should be used in series with the encoders.
    
    
       10K&#937; series resistors should also be used if a RC
       receiver is used.
    
    
       If a Wii Nunchuck is used, it is expected to be used
       on the Prop's I2C bus (P28 & P 29).  
    

    Once you have the above constants all set, you'll want to load the top object "Demo4WDBot130226e" into your Propeller board's EEPROM (by pressing "F11").

    Open the Parallax Serial Terminal (by pressing F12). With the baud set to 115,200 and with the appropriate comm port selected, you should see a bunch of data in the terminal window.

    Something like this:
    Target Speeds:   targetSpeed[0] = 0,  child[0] = 0
       targetSpeed[1] = 0,  child[1] = 0
       targetSpeed[2] = 0,  child[2] = 0
       targetSpeed[3] = 0,  child[3] = 0
       Current Speeds:
       currentSpeed[0] = 0,  output[0] = 0
       currentSpeed[1] = 0,  output[1] = 0
       currentSpeed[2] = 0,  output[2] = 0
       currentSpeed[3] = 0,  output[3] = 0
       Current Encoder Readings:
       encoder[0] = 0
       encoder[1] = 0
       encoder[2] = 0
       encoder[3] = 0
               3            2           1
              1098_7654_3210_9876_5432_1098_7654_3210
       Ina = %1111_0000_0000_0000_0010_0000_0000_0000
    

    You'll want to pay attention to the "currentSpeed" values. Turning the wheels in the direction that would cause the robot to move forward should produce positive speed. If the speed is negative, then you'll want to do one of two things.

    If you're encoder pins are easy to switch, just switch the two encoder pins for that particular wheel. The other way to deal with a negative speed with positive wheel motion is to change the constants "FORWARD0" through "FORWARD3". Change the constant that corresponds to wheel from "1" to "-1".

    Once all the "currentSpeed" values give positive speed with forward robot motion, you'll want to make sure the motors' directions match the encoder directions. There's no guarantee which way the motors will turn when power is applied to the red and black wires. Some of these wires are reversed when they are installed. You'll need to test the motors to see which way they turn.

    Here's the instructions for setting the motor directions:
    Before proceeding with the rest of the setup, save  the changes to the header file and recompile and
      load (to EEPROM) the modified code.
      * Set Motor Directions *
      With the modified code running in the robot, again turn
      off the feedback portion of the program by typing "o"
      in the terminal window.
      The direction of the motors should now be checked.
      The direction of the motors should match the direction
      of the encoder feedback.
      The characters ">" and "<" will be used to bracket
      data to be entered into the terminal window. The
      character "&#61626;" will be used to indicate the "Enter"
      key. To test the direction of motor #0 type the
      following into the terminal window. >0700&#61626;<. This
      should turn on motor #0 (the front left motor) to
      70% power. If the encoder direction did not need to
      be reversed , the motor should be spinning in a direction
      that would move the robot forward. The main thing to
      check in with these motor tests is to see if he motor's
      "targetSpeed" matches the direction of the motor's
      "currentSpeed" positive "targetSpeed" should produce
      positive "currentSpeed". If the two directions do not
      match, then the constants "WHEEL_RED_0" and "WHEEL_BLACK_0"
      will need to be switched.
      Turn motor #0 off by typing >0&#61626;<.
      Test the direction of motor #1 (front right) by typing
      >1700&#61626;<. Again, check to see if the directions of
      "targetSpeed" and "currentSpeed" match.
      Turn motor #1 off by typing >1&#61626;<.
      Repeat this process for motor #2 (left rear) and motor
      #3 (right rear).
      Once the appropriate "WHEEL_RED_x" and "WHEEL_BLACK_x"
      constants have been switched, recompile and load the
      program.
    

    That's all I have time for right now. Let me know if you need any of the above clarified or if you have any other questions. (I don't have Skype installed on this PC. If need be I could install it. I'd rather help on the forum so others wanting to also use this code can benefit from our exchange.)
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-02-28 22:47
    I'm not sure if I've mentioned that this is the program I used to drive figure eights. If the robot doesn't receive any input to tell it to do otherwise, it will start trying to drive in a figure eight.

    I think this should be easy to change. There's a line (#584) in the "Setup" method that sets the driveMode variable. The "SetUp" method is the first method in the top object "Demo4WDBot130226e.spin".

    Here's the section of code:
    kP := Header#PROPORTIONAL_CONSTANT  
    
    
      debugFlag := 0
      pDebubFlag := -1
      uSecond := clkfreq / 1_000_000
      refreshInterval := clkfreq / Header#REFRESH_RATE
      ignoreThrottleInterval := uSecond * IGNORE_THOTTLE_INTERVAL
      wheelMode := Header#WHEEL_MODE
      state := WAITING_FOR_MOTOR_ID
    [B]  driveMode := FIGURE_8_MODE[/B] 'MANUAL_MODE '
      '**18a*Adc.start(Header#DI_ADC, Header#CLK_ADC, Header#CS_ADC, 001)
    

    Change:
    driveMode := FIGURE_8_MODE
    

    To:
    driveMode := KEYBOARD_MODE
    

    This should keep the motors off when the robot starts.

    I haven't tested this yet (I don't want make any noise right now). I should be able to test this tomorrow to make sure the robot starts with its motors off.

    I wasn't thinking about using the code on a slave Propeller when I posted the code. I just posted the version I had been using (to drive figure eights).
  • amano001amano001 Posts: 47
    edited 2013-03-01 13:45
    Hey duane thanks for all the info I have been following the steps to get it working. I am having trouble with the red and black wheel wires since I am using a different motor controller board

    https://www.sparkfun.com/products/11593

    It has Cur(used to measure the current the wheel is pulling), direction, pwm, gnd pins for each motor. So I am not sure what pins would go where for the red and black.

    Ok I see IN1 and IN 2 as motor 1 and IN 3 and IN 4 for motor 2 but I can't figure out how that corresponds to my board with direction pin and pwm pin instead of IN 1 and IN 2?

    THe more research I do it seems that I cannot use the current motor controller with your code. Since my board does all the logic of the H bridge inside it you just pass it the dir and speed while yours you have to enA IN1 and IN2 to set high and low in order to give it a dir and speed. Let me know I might have to swap out the motor controllers to the L298.

    http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Robotics/4 Channel instruction manual.pdf

    here is the datasheet for my motor controller and it seems in one of the last paragraphs states the built in control logic allows the motors to be controlled by 2 pins dir and pwm.



    Thanks.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-03-01 14:23
    amano001 wrote: »
    Hey duane thanks for all the info I have been following the steps to get it working. I am having trouble with the red and black wheel wires since I am using a different motor controller board

    https://www.sparkfun.com/products/11593

    It has Cur(used to measure the current the wheel is pulling), direction, pwm, gnd pins for each motor. So I am not sure what pins would go where for the red and black.

    Thanks.

    You motor controller uses PWM and direction which is different than what my driver's two "IN" connections and an enable connection. I've been meaning to add inverters to my motor controller so it would behave the same as yours.

    For now, I think your controller could work by setting the "WHEEL_ENABLE_x" pin to the PWM pin and the "WHEEL_RED_x" to the direction pin. Set all the "WHEEL_BLACK_x" constants to some unused I/O pin (which will stay unconnected). I think all the "WHEEL_BLACK_x" constants could be set to the same pin number. If the motor direction doesn't match the encoder direction, you can switch the "WHEEL_RED_x" and "WHEEL_BLACK_x" constants.

    I don't have any support for current sensing yet. I've been intending to add support for an ADC chip to my projects for measuring current. One of my boards has an MCP3208 chip installed but I haven't added the software to read it yet.

    You could connect the "cur" pins to you other microcontroller's analog pins to monitor the current.

    I just thought of something. The Rover 5 control board you're using has connections for the quadrature encoders which are then converted to single channel encoders. Don't use you motor control board encoder connections. The Propeller is expecting quadrature encoders not a single channel encoder. (Make sure and read the notes about using resistors on the encoder lines.)

    Normally quadrature encoders would be able to tell you how far the robot had traveled. I think with Mecanum wheels, trying to make sense of the encoder information is much more difficult than with normal wheels,

    All these different PCBs need to have a common ground connection.
  • amano001amano001 Posts: 47
    edited 2013-03-01 15:29
    My motor controller board has outputs for ENC1 and ENC2 and then a Single INT output. So I should be able to just pass the ENC1 and ENC2 pins to the parallax board correct and just not use the single INT pin which combines the two ENC 1 and ENC 2 into a single encoder?
  • amano001amano001 Posts: 47
    edited 2013-03-01 15:30
    Also should the encoder readings on the terminal be counting up and down or should they reset when the wheel stops spinning? It seems to go like move wheel forward 1 2 3 ...600 or reverse 600 599 598 .... 3 2 1 0 -1 -2 -3 etc ?
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-03-01 16:26
    amano001 wrote: »
    My motor controller board has outputs for ENC1 and ENC2 and then a Single INT output. So I should be able to just pass the ENC1 and ENC2 pins to the parallax board correct and just not use the single INT pin which combines the two ENC 1 and ENC 2 into a single encoder?

    Correct. You don't want to connect the INT pins to the Propeller board. The yellow and white wires from the Rover 5 should connect through resistors to the Propeller. The red wire (grouped with the yellow and white wires) should be connected to 5V and the black wire (again, the black wire on the encoder bundle not the motor power wire) to ground.
    amano001 wrote: »
    Also should the encoder readings on the terminal be counting up and down or should they reset when the wheel stops spinning? It seems to go like move wheel forward 1 2 3 ...600 or reverse 600 599 598 .... 3 2 1 0 -1 -2 -3 etc ?

    The encoders so not reset to zero unless you turn the wheel backwards as much as you turned it forward (this is a feature of quadrature encoders). I've seen encoder objects that allow the encoder to be reset to zero but I didn't have this need myself. You could record the previous encoder value to compare with new encoder values if you wanted to keep track of how far you've moved from some arbitrary point in time.
  • amano001amano001 Posts: 47
    edited 2013-03-01 18:08
    Hey wanted to check something about wiring up the parallax board. on the board it starts at 1 to 40 but in the datasheet it shows 1 as pin 0? so when coding up do I use 0 or 1 when referring to the pin labeled pin 1 on the board?

    also forgot to ask why the 10k resistors on all the input pins to the board?
  • amano001amano001 Posts: 47
    edited 2013-03-01 18:17
    When I use the serial terminal it seems to output a lot of extra information, not as concise as what you had posted earlier.
    SerialParallax.jpg
    1024 x 584 - 57K
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-03-01 19:44
    amano001 wrote: »
    Hey wanted to check something about wiring up the parallax board. on the board it starts at 1 to 40 but in the datasheet it shows 1 as pin 0? so when coding up do I use 0 or 1 when referring to the pin labeled pin 1 on the board?

    The Propeller has 32 general purpose I/O pins (four of these are used during boot up and it's generally not a good idea to use P28 - P31 for other devices unless you know what you're doing). The QuickStart has a 40 pin header. Header pins and physical pins on chips start their numbering with #1. The I/O pins are numbered starting with zero.

    In the diagram below, P0 is located on the physical location #1 on the header. P1 is on location #2.

    attachment.php?attachmentid=99629&d=1362193799
    I use a label to help figure out which pin is which.

    attachment.php?attachmentid=82231&d=1308241428


    If you happen to have a Brother label maker, you can use the file in post #7 of this thread (about the QuickStart board), to print your own labels. If you don't have a label printer send me a PM with your address and I'll mail a few of these labels. (The label offer is good for anyone else reading this post.)
    amano001 wrote: »
    also forgot to ask why the 10k resistors on all the input pins to the board?

    The Propeller is a 3.3V device and 5V will damage the chip if the current is above certain amount (500uA IIRC). As long as the resistor value is 3K or more, it should be okay. I use 10K since I have a lot of 10K resistors.
    amano001 wrote: »
    When I use the serial terminal it seems to output a lot of extra information, not as concise as what you had posted earlier.

    I just posted the top section of the debug information earlier since it contains all the information you need to setup your robot. I have the program displaying a lot of data as I try to figure out what the program is doing.

    You'll probably want to reduce the amount of information transmitted from the Propeller when you have it hooked up to your other uC.

    The method "DebugCog" contains the main debug loop. If you comment out some of the method calls, less information will be displayed to the terminal window (or sent to the other uC). I think you'd be save to comment out the following methods:
    PUB DebugCog  
    
      Pst.Start(115200)
      
      repeat
        'CheckOtherInputs
        result := Pst.RxCount
        if result
          if state == WAITING_FOR_MOTOR_ID   
            DisplayMenuSpeed
          elseif state == FIRST_DIGIT_SPEED or state == WAITING_FOR_SPEED
            ReceiveSpeedInput
        CheckNewData
        DisplayTargetSpeed
        
        DisplayEncoder
        'DisplayPinStates
    
    
        'if TEST_DIRECTIONS_FLAG == Bot#TEST_DIRECTIONS_OPERATION
        DisplayPresentSpeed
        'DisplaysSpeedBuffer
        'DisplayControlData
    
    
    

    You'll probably want to reduce the amount of information the Propeller sends to make it easier for your other uC to read the pertinent information. You can go through the remaining methods called by "DebugCog" and remove or change the information it transmits. Let me know if you need help editing the debug information.

    When you connect the Propeller with your other uC you'll want the use the TX and RX lines. Since your other uC is a 5V device you'll want to use a resistor on the Prop's RX line.
    317 x 575 - 38K
  • amano001amano001 Posts: 47
    edited 2013-03-01 20:00
    Thanks,

    I got the encoders to respond great and get current speed. But now I am trying to control the motors my motor controller and not sure if I am either not doing it right or is it jjust not compatible. I have it hooked up like this


    Wheel enable 1 = pin 10 = pwm on my motor controller
    wheel red 1 = pin 11 = direction on my motor controller

    then I have the ground from my motor controller going to ground and the boards ground going to same ground. but no luck thus far.
  • amano001amano001 Posts: 47
    edited 2013-03-01 20:11
    Got it to spin a little bit but then it slowed down and stopped. Not sure if its the motor controller or the code since its not made for my board really.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-03-01 20:38
    Got it to spin a little bit but then it slowed down and stopped.

    Had you typed anything into the keyboard? The default action is for the motor is to spin a bit and then stop.

    I just tested the change I suggested in post #99 and it didn't work. I'll figure out to how to make sure the motors start out off and only turn on with keyboard input.

    As it is now if you type the letter "o" it should turn off all the motors. You should be able to then type in motor and speed after that.

    After starting the robot, type "o". Then type "0500" followed by enter (and without quotes). The front left wheel should spin at half speed. Type "0" enter to turn motor #0 off. (Assuming you have the pins for motor #0 set and wired correctly.)

    If you're unsure your motor controller responds to 3.3V logic, you could try one of the motor control objects that use a direction pin to test it.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-03-01 21:29
    Okay, I tested a way to keep the motors off at start up.

    In the "Setup" method of the top object change line #595 from:
    keyboardFlag := 0
    

    To: (You guessed it.)
    keyboardFlag := 1
    

    There's a bug in the posted version of the code that doesn't accept the first motor speed command entered. So the first command to change speed is ignored but subsequent commands should work.

    I'm pretty sure I have this bug fixed in the version I'm presently working on but I've also added new bugs as I've been incorporating a compass.
  • amano001amano001 Posts: 47
    edited 2013-03-02 01:17
    I was inputting into the terminal 0700 for motor 1 to go speed 700 I saw in the code it was -1000 to 1000. But now that you say it doesnt take in the first command that you write to it I cant remember if I typed it in twice....I will have to try tomorrow inputting 0700 twice and see if it responds. I hope so!!!!

    thanks for responding.
  • amano001amano001 Posts: 47
    edited 2013-03-02 15:50
    two little side questions

    A> sometimes terminal will stay blank even after loading a program into the board I have to close out of propeller and reopen for it to show the information I have tried a bunch of alittle things enable disable etc but nothing working not sure if ehre is acommand to refresh maybe.

    B> does the board run always whatever is in RAM ? if there is something in eeprom when it boots up and nothing in ram it will load into ram and run correct?
  • amano001amano001 Posts: 47
    edited 2013-03-02 16:00
    Tried to add another motor to the mix and the first motor started freaking out and grinding a lot had to cut it off . I am just going to grab some L298 H bridges and try to get it working instead of trying to force this board to fit, It has its own control logic so who knows what signals it is interpreting.

    Ill post on Tue hopefully the boards will come in by then.

    Thanks
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-03-02 18:51
    amano001 wrote: »
    two little side questions

    A> sometimes terminal will stay blank even after loading a program into the board I have to close out of propeller and reopen for it to show the information I have tried a bunch of alittle things enable disable etc but nothing working not sure if ehre is acommand to refresh maybe.

    I don't know how to get around this problem. This used to happen to me relatively often. I don't have this problem much anymore, I don't know what I did, if anything, that made it better. I think it's a problem on the PC side of things.

    Often if I close the terminal window and then reopen it, it behaves better.
    amano001 wrote: »
    B> does the board run always whatever is in RAM ? if there is something in eeprom when it boots up and nothing in ram it will load into ram and run correct?

    The Propeller always runs from RAM. It loads the program from EEPROM to RAM at start up. It's possible to load a program from the PC directly to RAM but the program will be lost when the Prop reboots if the program hasn't been loaded to EEPROM.
    amano001 wrote: »
    Tried to add another motor to the mix and the first motor started freaking out and grinding a lot had to cut it off . I am just going to grab some L298 H bridges and try to get it working instead of trying to force this board to fit, It has its own control logic so who knows what signals it is interpreting.

    Ill post on Tue hopefully the boards will come in by then.

    Thanks

    I looked through the comments I made in the program to see if I wrote down how to set the PWM frequency. I couldn't find any instructions so I'll give some here.

    The frequency is set by setting the constant "MAXSPEED" in the object "FourMotors130223a.spin". The frequency can be computed with this equation:

    PWM frequency = 80,000,000 / MAXSPEED

    Presently I'm using the value 1,600,000 for MAXSPEED which make the frequency 50Hz. I decided 50Hz wasn't very bothersome. I had previously used 20KHz as my PWM frequency but it greatly reduced the power to the motors. I don't know if your motor control would have a problem with the 50Hz frequency or not. I doubt it would be a problem but I'm not sure.

    Have you used the motors and motor control board with a different uC? Where you able to power all the motors at the same time? I looked back through the thread and see you're using two 7.2V NiCd packs. Do you know how much current these packs can supply? 7.2V might be a problem for the L298N motor controllers since they drop the voltage a bit (I think by 2V). Could your problems with the motors be related to the batteries?
  • Duane DegnDuane Degn Posts: 10,588
    edited 2020-03-05 21:01
    I got the compass to work.

    I used it to control a figure 8. (Same video as in the figure 8 thread.)



    The robot takes a heading reading before it starts the first loop. It then ignores the compass for two seconds to make sure it doesn't accidentally zigzag at the beginning of the loop. After the first two seconds of the loop it checks to see if it has passed the start heading.

    Here's the portion of code that checks to see if the starting heading has been passed.
    elseif driveMode == FIGURE_8_MODE     ' ** Seems awkward to check modes in this method                                     ' and AutoDrive method.
        previousHeading := pseudoHeading                                
        Control.RefreshInput
        if watchCompassFlag == CCW_WATCH_COMPASS
          if previousHeading > initialPseudoHeading and pseudoHeading =< initialPseudoHeading
            watchCompassFlag := NO_WATCH_COMPASS
            result := true
        elseif watchCompassFlag == CW_WATCH_COMPASS
          if previousHeading < initialPseudoHeading and pseudoHeading => initialPseudoHeading
            watchCompassFlag := NO_WATCH_COMPASS
            result := true
          
    

    Since the compass transitions from -179 to +180 as it passes south, the above algorithm could have a problem if the robot started with a southern heading. I intend to take care of such possibilities in the future, but for now, I just make sure the robot is headed north at the beginning (most of my previous figure eights started out heading south).

    I also want to make it so the robot can use the compass to figure out and adjust its turn rate.

    It's kind of fun to start giving this robot some intelligence.
  • amano001amano001 Posts: 47
    edited 2013-03-02 20:33
    Hey duane, I have a 9v battery I can always try out if the voltage drop across the bridge is to much. I think the motors say 5v to 7.2v operating range so I might be able to get away with 7.2v batteries. I think the batteries are 1000mAh iirc. I have also tested all the motors with just the motor controller and they work fine that was using the arduino to control. Is there any way to figure out a good pwm frequency to set it to?, why 50hz might I ask.

    Wanted to add that we were discussing using a compass instead of the 2 ultrasonics to make sure we drive straight and sideways . We are having issues with the ultrasonics and objects sometimes so we cannot rely on them always to make sure were driving straight. The tilt compensated ones are quite costly so we might just go without the tilt compensation . Still trying to figure out how we can adjust the speeds of wheels when its off.

    In one of the above posts our theory was
    when driving straight if it veers left then we need to slow down the right side and opposite if its veers right a simplistic approach so not sure if it will work in practice.
  • rwgast_logicdesignrwgast_logicdesign Posts: 1,464
    edited 2013-03-03 00:40
    @ammano

    You can use an accelerometer to help with compass tilt, im not sure if it is any cheaper but it adds more functionality to your bot than a new compass. Also if you are after straight lines, check in to adding quadrature encoders to your bot. If you DIY them this will be super cheap and also allow you to do accurate speed control a long with dead reckoning and all kinds of cool odometery. I personally think encoders are one of the most important things you can add to a bot!
  • amano001amano001 Posts: 47
    edited 2013-03-03 11:15
    Ya actually thats what were working on in this thread is I am trying to integrate duanes pid controller into my robot. The rover 5 chassis has 4 quadrature encoders. The problem with an accelorometer is great for tilt but if were standing still we want to know which way we are oriented.
  • amano001amano001 Posts: 47
    edited 2013-03-06 21:56
    Hey duane,

    So I got the new H bridges in, I will be testing tomorrow. I had a quick question about the settings that you have for indepedent wheels or meccannum wheels what is the difference when setting these? Particularly when I go to send directions to the parallax board will I still send the motors signals like 0700 1700 2700 3700 or does the meccannum setting accept something different?obot to go sideways well we know how to program it to go sideways with arduino but if I am sending commands say 0700 0-500 0-500 0700 What does it pick to make the master speed to match all the motors to? another example just going straight 0700 1500 2700 3300 what would it choose to be the master speed to try to match all the motors together? Thanks.
  • amano001amano001 Posts: 47
    edited 2013-03-07 18:40
    Also was wondering about the slave part when I am sending serial out of my arduino do I need to have it in string or does it need to be an int that I send to the parallax board? for isntance "0700" when I type it into the serial terminal and the board reads it is it reading it as a string or integer?

    Tried this on my arduino to just send a speed but not working It just sends 0700 with carriage return at the end through serial. I have my arduino TX hooked up to parallax RX , not sure if the usb being hooked on the parallax is interfering with the communication?


    char str[ ] = "0700\n";


    void setup() {
    Serial.begin(115200);
    Serial.write(str);
    }

    void loop() {



    }
Sign In or Register to comment.