Shop Learn
Open Propeller Project #8: Eddie Firmware Ported to Propeller Activity Board — Parallax Forums

Open Propeller Project #8: Eddie Firmware Ported to Propeller Activity Board

Ken GraceyKen Gracey Posts: 7,326
edited 2015-05-14 10:57 in Propeller 1
OPP-EddieFirmware.png

Background to this Open Propeller Project


Today we launch a new Open Propeller Project (#8) to improve the Eddie firmware so that Parallax Arlo users have an effective Spin solution with the new Motor Mount and Wheel Kit with Encoder. At present, we have only released C code in the SimpleIDE framework which is adapted from the ActivityBot. However, many customers prefer Spin and we would like to support their requests. We also have many Eddie Control Board customers using ROS, who would benefit from a Propeller Activity Board compatible version of the Eddie Firmware.

WIth this code, we will be one step closer to releasing the Arlo Robotic Platform as a complete kit, to Parallax standards. Customers will be able to use the Motor Mount and Wheel Kit effectively on platforms of their own making, too.

Challenge Details

The author of the original Eddie Control Board firmware (David Carrier) has written up some notes on what it will take to complete a few challenges:
Programmatically, the only variations from the Eddie Control Board board are a different ADC and H-bridges with built in controllers. Replace the MCP3008 with ADC124S021 code and swap out the H-bridge controller code in "Eddie Motor Driver.spin" with a servo-pulse output, and you’ll be done. Make sure everything is compatible with the original code, including the motor power levels in "Eddie Motor Driver.spin"
  • Challenge 2: (Not so trivial) Add in the "ARC" command that was never finished.
The code in the "POSITION" section of the case statement in the PDIteration method drives the robot in a straight line while ramping motor speed up and down smooth. An "ARC_POSITION" case would drive the outer wheel using essentially the exact same code, but the inner wheel would need to move proportionally slower.
This is where copy and paste are your friend. Use a copy of the existing code to drive the set point for the outer wheel, but base the set point for the inner wheel on percentage of the distance the set point of the outer wheel has traveled; don’t let the inner wheel ramp on its own. The "TRVL" and "TURN" commands in the "Parse" method are similarly reusable. An "ARC" command would be mostly an amalgam of the two.
Make sure the units match. The "TRVL" command uses encoder positions as a unit of distance, so the turn radius should do the same. This will take some math. The POSITIONS_PER_ROTATION constant will help you here. Pay attention to how the "TURN" and "HEAD" commands use it.
  • Challenge 3: (Far from trivial - a technical stretch goal) Add an integral into the proportional/derivative control code.
Currently, the Eddie code will happily sit one position awn4cb805day from its destination, since it doesn’t accumulate error over time. This isn’t accumulative and doesn’t effect dead reckoning, so it isn’t a high priority, but if anyone feels the need to correct it, I don’t think anyone would mind.

This project has been one of those important efforts that we have always felt we can complete internally, but competing priorities have caused it to continually take second place [and never be completed]. We are also actively recruiting more internal and consulting engineering resources for our team. This project, along with the other Open Propeller Projects, has helped us develop additional productive relationships.

Parallax GitHub

The source code repository for this project will be in the Parallax GitHub. Parallax is in the process (as of November 1, 2014) of moving all of our community open source code development efforts to this GitHub. All code will be open source under MIT license (copy and paste the license from other code into this one). The original Eddie code didn’t have the MIT license because it was created for Microsoft.

We will create the GitHub repository for these files on Tuesday this week.

We’ll Support this Effort with Hardware

Our hardware platform is basically defined above as an Arlo Robotic Platform. We would happily provide up to three (3) additional sets of Motor Mount and Wheel Kits and HB-25s to productive contributors. If you’re a contributor to this project we would be happy to provide the hardware for your efforts.

Additional Resources

Eddie Spin code http://www.parallax.com/downloads/eddie-board-command-set

Ken Gracey
Parallax Inc.

600 x 250 - 194K
«13

Comments

  • Duane DegnDuane Degn Posts: 10,494
    edited 2014-11-03 18:14
    Count me in as an interested party.

    I'm very interested in motor control algorithms. If you were to send me the hardware, I'll put a lot of effort into these challenges.

    I've previously had some success with motor control using encoder feedback with my Mecanum wheeled robot project.
  • Ken GraceyKen Gracey Posts: 7,326
    edited 2014-11-03 18:18
    Duane Degn wrote: »
    Count me in as an interested party.

    I'm very interested in motor control algorithms. If you were to send me the hardware, I'll put a lot of effort into these challenges.

    I've previously had some success with motor control using encoder feedback with my Mecanum wheeled robot project.

    Fish on! I mean, ahem, "yeah, we got Duane!". I know you can do this project from your prior work with the ESC programming.

    Hardware shall be dispatched on Tuesday.

    Maybe we need one more interested and capable party to assist you as a tester/collaborator on this project.

    Ken Gracey
  • Duane DegnDuane Degn Posts: 10,494
    edited 2014-11-03 18:21
    Ken Gracey wrote: »
    Maybe we need one more interested and capable party to assist you as a tester/collaborator on this project.

    Absolutely. It would be great to work with some other Parallaxians.
  • WhitWhit Posts: 4,183
    edited 2014-11-03 18:23
    Great news Ken. I'll be keeping up with this and if I am able try to contribute...
  • Brian_BBrian_B Posts: 818
    edited 2014-11-03 18:55
    Ken,
    I have the hardware so I'll keep a eye on this.


    Brian
  • Ken GraceyKen Gracey Posts: 7,326
    edited 2014-11-03 19:12
    Brian_B wrote: »
    Ken,
    I have the hardware so I'll keep a eye on this.


    Brian

    Welcome back, Brian! Now that summer is over we'll be happy to see ya back on the forums. Thank you for the time this morning answering some non-electronic questions, too.

    We should be posting the WiFi/iOS stuff pretty soon, too.

    Ken Gracey
  • Brian_BBrian_B Posts: 818
    edited 2014-11-04 04:34
    Thanks' Ken,
    it's always a pleasure to chat with you.

    Summer is always a super busy ,so my robots ( and the forums) take a back seat.

    I pulled out my Arlo and noticed I have a propeller BOE board running it ,so I could use another Propeller activity board to make it code compatible.

    Brian
  • Duane DegnDuane Degn Posts: 10,494
    edited 2014-11-04 10:48
    I've come across the first of many changes where I could use some input from Parallax (Ken).

    The previous ADC code ran continuously in its own cog, JonnyMac's adc124s021 only reads from the chip when requested. It wouldn't be hard to convert Jon's code to continuously update the ADC variables but from my initial inspection of the Eddie code, I don't see a reason to tie up a cog to read the ADC chip.

    Will the PC software mind if only four values are returned from the "ADC" command? Should there be eight values returned? If more than four values are returned, what should the extra four fields consist of?

    IMO, if it's best to return 8 values, then the four readings from the ADC should be repeated. This way the last channel can still be used to monitor the battery voltage without needing to change the code on the PC end.

    Unless instructed otherwise (UIO), I'll have the ADC command return the four channels listed twice. Also, UIO, I don't have the ADC code running continuously. The chip will only be polled when requested.
  • David CarrierDavid Carrier Posts: 293
    edited 2014-11-04 11:05
    Duane,
    I agree with you in both of your "UIO" assumptions. I think the MCP3008 object was designed for oscilloscope-like functionality. Since the Eddie firmware only reads from the ADC occasionally, I think it makes sense to do the readings inline instead of tying up a cog.

    With the VERSION constant, we usually increase the first digit any time we break compatibility and the second for each release since then. I recommend setting the version [14] if you double transmit the ADC results and version 20 if you only return four values.

    — David Carrier
    Parallax Inc.
  • RobotWorkshopRobotWorkshop Posts: 2,307
    edited 2014-11-04 11:20
    I would like to help with this. I've looked at it in the past since I have a robot that originally used a pair of HB-25's and the early position controllers on the base. I swapped out the position controllers with the new quadrature encoders and was looking at changing the Eddie Firmware to leverage those instead. I was distracted with other projects but will see if I can find my notes on it. This is a project that I definitely think needs to be done.

    Robert
  • Beau SchwabeBeau Schwabe Posts: 6,479
    edited 2014-11-04 12:08
    With +10 years in prosthetic robotics, specifically motor control techniques, you should explore Dynamic PWM in addition to simple user defined PWM. Dynamic PWM allows the micro controller to take over so that a constant voltage is maintained to the motors during unexpected LOAD conditions. Typical user defined PWM can be sluggish when obstacles are encountered. Dynamic PWM is analogous to an adjustable switch mode power supply designed to drive an inductive load.

    Also, if your going to "double stamp" the data, make it so that the data packet sent is the Previous data along with the Current data or the delta (first derivative) between the previous data and current data. This can be useful in predicting acceleration deceleration trends.

    Another also .... can someone remove the (Parallax) from my name without destroying my forum account? Thanks
  • Duane DegnDuane Degn Posts: 10,494
    edited 2014-11-04 12:16
    Thanks for the reply David.
    With the VERSION constant, we usually increase the first digit any time we break compatibility and the second for each release since then. I recommend setting the version 13 if you double transmit the ADC results and version 20 if you only return four values.

    The latest version uses the "13" as the version number.

    It looks like version 1.3 includes code to read the new quadrature encoders. Do you know if version 1.3 is working properly with the Eddie board's h-bridge?

    If the quadrature encoder portion of the code works properly, then besides the change in the ADC (which should be trivial) then the other main change is to convert the h-bridge code to use servo pulses, correct? If this is the case, then the motor control change will also be trivial.
  • Duane DegnDuane Degn Posts: 10,494
    edited 2014-11-04 12:22
    you should explore Dynamic PWM in addition to simple user defined PWM. Dynamic PWM allows the micro controller to take over so that a constant voltage is maintained to the motors during unexpected LOAD conditions.

    I take it Dynamic PWM is above what is done with a PID loop? I'd think the encoders would indicate when additional power is needed to overcome an unexpected load.

    Would Dynamic PWM be practical with the hardware Ken listed? If so, it would require two of the four ADC channels, correct?
  • RobotWorkshopRobotWorkshop Posts: 2,307
    edited 2014-11-04 12:59
    I think that to start it would be good just to swap out the code for the H-bridge control with one of the servo objects to control the HB-25's. With the encoders in place that should help compensate for any unexpected loads. Actually we should expect unexpected loads and if one (or both) motors fall behind then make adjustments to the HB-25 output. Before going to all the trouble of using the ADC to monitor the motors some testing can be done to see if that would be needed. After the drive is working then the ADC can be fixed and work on the ARC command.

    Robert
  • Beau SchwabeBeau Schwabe Posts: 6,479
    edited 2014-11-04 13:08
    In a sense it could be done with Encoders. A dynamic switchmode power supply is a PID in and of itself that monitors voltage rather than an encoder wheel. An Encoder wheel will work, but it doesn't have the infinite range monitoring the voltage does, and if there is a power glitch it won't be able to recover easily.
  • Duane DegnDuane Degn Posts: 10,494
    edited 2014-11-04 14:38
    I think that to start it would be good just to swap out the code for the H-bridge control with one of the servo objects to control the HB-25's.

    I'm using a stripped down version of Beau's servo object with the variables moved to a DAT section so the object can be shared among several other objects.

    This would allow the use a command to set servo positions without much additional overhead.

    I was thinking about jury rig something together to test the changes but I think I'll wait until the hardware arrives.
  • NikosGNikosG Posts: 702
    edited 2014-11-16 21:52
    I'm interesting to contribute in this Project (If I can). I would like to test the code on my Robot "The Artist".
    As I saw Duane has made a "Stingray Like" robot that is very similar (design geometry and hardware) as the artist
    I visited Parallax GitHub but I couldn't find the code Eddie=>Arlo. Is the code there?
  • Duane DegnDuane Degn Posts: 10,494
    edited 2014-11-16 22:32
    NikosG wrote: »
    As I saw Duane has made a "Stingray Like" robot that is very similar (design geometry and hardware) as the artist

    Wow, you're right. Our robots do have a similar geometry (and hardware). Here's my robot.

    attachment.php?attachmentid=111999&d=1416204358

    And below is a photo I borrowed from your robot page showing your The Artist next to your Stingray.

    attachment.php?attachmentid=107235&d=1393528430

    I drew the design on the PC using Arlo's size as a guide. The distance between the wheels on my robot should be the same as on an Arlo. I used the distance between the wheels as the size of an octagon but then stretched the octagon out for the tail. The tail wheel (while turning) should fit within the diameter of a circle described by the two main wheels. I had the Stingray in mind while designing my robot but I didn't look up the design of the Stingray before drawing my bot. I can now see the angles of my robot and the Stingray aren't exactly the same. Five of the sides of my robot make up most of an quadrilateral octagon. One of my main desires was to get the design finished quickly while still matching the wheel spacing of the Arlo.

    Here's the drawing of my bot with a circle the size of an Arlo to give one an idea of the size difference.

    attachment.php?attachmentid=112002&d=1416207007

    So while the distance between the wheels is the same on my robot as on an Arlo, my robot has a lot less deck realestate.

    I cut my platform from some expanded PVC.
    attachment.php?attachmentid=112000&d=1416205063

    Once I make some significant progress with the software, I'll work on making the hardware more presentable.

    attachment.php?attachmentid=112001&d=1416205066

    I'm pretty sure I'll want to add a second deck.

    I have the ADC part of the Eddie code modified to use the Activity Bot's ADC chip and I can use the "POWER" mode commands to drive the motors but the encoder feedback portion of the code still needs some work (it may need lots of work).

    I'm still not sure how the GitHub stuff is going to work with this project. I'll do what Parallax wants but until we (or just I?) get this figured out, I'll post my most recent code here.

    Once I have a version of code I can be relatively sure won't cause damage to the attached hardware, I'll post it.
    647 x 603 - 228K
    611 x 387 - 105K
    681 x 537 - 216K
    606 x 604 - 35K
  • NikosGNikosG Posts: 702
    edited 2014-11-17 08:56
    Duane,
    It looks very nice!
    Have you found where the gravity center is?
    When you put the AX-12 Smartarm on the chassis in which point the Robot balances?
    Pay attention at this point if you want to have a good stability.
  • Duane DegnDuane Degn Posts: 10,494
    edited 2014-11-17 20:47
    NikosG wrote: »
    Duane,
    It looks very nice!
    Have you found where the gravity center is?
    When you put the AX-12 Smartarm on the chassis in which point the Robot balances?
    Pay attention at this point if you want to have a good stability.

    The "Smartarm" outline was added to see if the robot would be large enough to carry it. I understand I'd need to make some changes to the robot if I add the Smartarm.

    As the robot is now, the center of gravity is behind the main wheels. I've only powered it one while up on blocks so far. Once I get the ARC command to work, I'll have the robot perform a figure 8.
  • Duane DegnDuane Degn Posts: 10,494
    edited 2014-11-17 21:26
    I've attached the latest version of the Eddie software.

    Once I figure out what I'm supposed to do with Github, I'll submit a "push" (is that right?).

    I don't consider this project finished at all but I thought I'd post what I have so far in case any of you are interested in seeing it.

    One of the parts which is currently broken is the timeout code which would turn off the motor if communication from the PC stops.

    This is the section I broke (starting on line 325):
    repeat                                                ' Main loop (repeats forever)    NextCNT := PROCESSRATE + cnt
        repeat while (rxcheck := Term.rxcheck) < 0          ' Read a byte from the command UART
          LoopCount++
          '''if KeepAlive and LoopCount > constant(_clkfreq / PROCESSRATE)' Stop motors if no com in one second
          if KeepAlive == 0
            ifnot PDRunning
              Motors.Stop
              if debugFlag
                Term.Str(string(13, "Motors Stopped"))
            waitcnt(constant(_clkfreq / DIVISOR) + cnt)
            SetPower[LEFT_MOTOR]~
            SetPower[RIGHT_MOTOR]~
            StillCnt~
            Mode := POWER
          else
            'waitcnt(NextCNT += PROCESSRATE)
    

    In order to speed the debugging process, I'm interacting with the program through the Parallax Serial Terminal(.exe).

    Besides disabling a portion of the program to make it easier to interact through the terminal, I also added some "features" to make it easier for me to debug the code.

    The following three variables when set to one will make the output to the terminal easier to read and input easier as well (the input and output can be decimal ASCII instead of hex ASCII).
    debugFlag     byte      0
    decInFlag     byte      0
    decOutFlag    byte      0
    

    Here's an example of the output with these flags set to one.
    Mode = 3 = POSITION
    activeParameter = SetPower[LEFT] = 40
    MotorPosition[0] = 1694, MotorPower[0] = 40, SetPower = 40, SetVelocity = 60, MotorSpeed = 0
    MotorPosition[1] = 93808, MotorPower[1] = 80, SetPower = 80, SetVelocity = 60, MotorSpeed = 0
    

    The code required some significant (but easy) modifications to work with the HB-25 motor controllers. I added the "activeParameter" variable to make it easy to adjust some of the motor control parameters while the program was running.

    I added so many of my own commands the limit of 15 (or is it 16?) elseif conditions was starting to make the long list of string comparisons awkward. I was initially going to separate the list of "elseif" checks into methods with 16 conditions each but I decide if I were breaking the list apart anyway, I might as well cut down on the number of conditional statements each command entry required. I ended up grouping the commands by sections of the alphabet.
      case InputBuffer[0]
        "A".."F":
          ParseAF
        "G".."K":
          ParseGK
        "L".."R":
          ParseLR
        "S".."Z":
          ParseSZ
        other:
          abort @InvalidCommand
    
    
    

    The above code branches the program based on the first letter of the command. The commands starting with "A", "B", "C", "D", "E" and "F" are all listed in the method "ParseAF".

    I wrote some comments about the commands I added near the top of the program in the "CON" section. I figure most of these added commands will be removed once the code is working properly.

    I've started work on the ARC command but the code isn't included in the attached archive. I haven't started work on the integral aspect of the control algorithm but I'm written this sort of code before so I'm hopeful I'll be able to make it work.

    This is pretty amazing code. One can enter the distance and speed to travel and the code "magically" powers the motors at the appropriate level. It's been fun to work on this project.

    Edit (December 27, 2014): See post #36 for the latest version of the code.
    Edit(12/29/14) To reduce confusion about which code to use, I'm leaving only the latest versions attached to post #36.
  • Brian_BBrian_B Posts: 818
    edited 2014-11-18 04:07
    Duane,
    I ordered a activity bot board yesterday to replace my BOE board on my "Arlo". I'll test your code as soon as I can.

    Brian
  • Duane DegnDuane Degn Posts: 10,494
    edited 2020-04-19 19:45
    I keep adding commands to the firmware to add in the debugging process.

    I borrowed the S2's sound code so the robot could produce sounds with a command "SONG".

    I haven't cleaned the code up in a while but I think the attached code should work with the original commands.

    Here's a video of the robot performing a figure 8 using the new "ARC" command.

    Edit(12/29/14) This is an early test video. To see the most recent version of the firmware in action watch the video embedded in post #41.



    The difference between the code attached and the code used in the video is I had the "demoFlag" set to 1 so the demo (driving in a figure 8 and spinning in place) would start without any input on my part.

    Once I have the code working a bit better, I'll start removing some of the extra code I added.

    Edit: I think I've figured out how to add photo inline again. Here are the attached images.

    Cleaver141121a.jpg

    Cleaver141121b.jpg


    Cleaver141121d.jpg

    Edit (December 6, 2014): As mentioned in the comment section of the Eddie141121a code, the "SERVO" command had not been tested. I have since tested it and it does NOT work. I have since fixed it and I'll be posting an update with the fixed code soon.

    Edit (December 27, 2014): See post #36 for the latest version of the code.
    Edit(12/29/14) To reduce confusion about which code to use, I'm leaving only the latest versions attached to post #36.

    Edit(4/19/20): Fixed image links and YouTube link.
    793 x 605 - 269K
    798 x 574 - 203K
    666 x 523 - 206K
  • PublisonPublison Posts: 12,136
    edited 2014-11-22 02:22
    Very Nice DD !
  • Duane DegnDuane Degn Posts: 10,494
    edited 2020-04-19 19:41
    As I mentioned earlier, I wanted my robot to be functionally similar to an Arlo while at the same time being a bit different.

    Besides the overall shape being different, I decided to use straight lines to make the cutout for the motor instead of Arlo's oval shaped cutout.

    In case anyone is interested, here are the coordinates of the cutout (0,0 is top left)(units are millimeters).

    ArloCutout141122a.PNG

    The zipped OpenOffice drawing is attached to this post.

    I didn't add a lower level (used as a battery holder on the Arlo) since I didn't want to reduce the ground clearance of the robot.

    It appears there is 10cm of clearance between the platform and the ground.

    Cleaver141121c.jpg

    Now that I look at the above photo, I can see why the battery holder platform is a good idea. The wheels on my bot look like they angle outward a bit. I may need to figure out a way to better support the motors/wheels when I add additional weight to the robot.

    After recently reading through NikosG's Artist thread, I think I'll try to copy some of the features (I already inadvertently copied the shape) of the Artist and add a hole in the center of the robot to use with writing instruments.

    Hopefully I can make as easy to draw shapes using this Spin code as NikosG's has made it with the available C code.

    Edit(4/19/20): Fixed embedded images.
  • NikosGNikosG Posts: 702
    edited 2014-11-23 16:55
    Duane Degn wrote: »

    ..... I may need to figure out a way to better support the motors/wheels when I add additional weight to the robot..

    Duane,
    Indeed a lower level like the battery holder on the Arlo is necessary......
    Without a second hold (surbase) the wheel kit tremble as the robot moves fast or turn around (I saw that in my Robot)

    Duane Degn wrote: »

    .........Hopefully I can make as easy to draw shapes using this Spin code as NikosG's has made it with the available C code.

    Unfortunately I haven't done nothing with the writing code..... I'm still waiting some accessories from e-bay in order to make the painting mechanishm....
  • Duane DegnDuane Degn Posts: 10,494
    edited 2014-12-06 15:53
    Even though I haven't posted about this project for a while, I have been actively working on it.

    I decided I wanted my robot to be a bit more interesting so I started adding sensors to it.

    I added a couple of Pings but I was having trouble making sense of the feedback from the Ping sensors.

    One issue I had was the description of the units in the documentation. Both Eddie Command Set documents version 1.1 and 1.2 use this description under the "PING" command:
    The PING command will only initiate a measurement on pins that have been configured as
    PING))) sensor pins (see SPNG command). The response includes a measurement for each
    active sensor, from lowest pin number to highest, with a range in hex of 12 to B54. There
    are 470.2 units per mm or 11942.75 units per inch. Non-functioning sensors, or sensors
    with no objects within its range, will respond with a null.

    So the values returned from the PING command are between 18 and 2900 inclusive.

    If the above is correct then the maximum reading of 2900 should equal 6.168mm. Obviously there's an error.

    I think if you divide these conversion factors by 512 (9-bits) then you get closer to the correct conversion factor.

    Instead of 470.2 units per mm, the conversion factor is 0.91836 units per mm. If the values in the "Ping.spin" object are correct:
    CON
    
      TO_IN = 73_746                                                                ' Inches
      TO_CM = 29_034                                                                ' Centimeters
    

    Then the conversion factor should be 0.90698 units per mm (if I did my math correctly).

    It's not surprising to find small discrepancies among time to distance conversion factors since these conversions are dependent on the value used for the speed of sound. The speed of sound is strongly effected by temperature.

    Since I wanted to change the way the Ping sensors were triggered and read anyway, I decided to modify the original Ping.spin code in the Propeller library to include a method allowing for temperature compensations. (I understand the way the Eddie firmware reads from the Ping sensors is very different than the way used by the Ping object in the Propeller library.)

    I've posted my version of the Ping code in the Propeller forum.

    Part of my desire to change the Ping section of the Eddie code is to reduce (or hopefully eliminate) the problems of echos from one Ping sensor interfering with another. The present Eddie code triggers the Ping sensors in a way which is prone to interference.

    I have not finished incorporating my changes into the Eddie code yet. I still need to make my Ping object backwards compatible with the earlier Ping object.

    As mentioned in an edit to post #24, the "SERVO" command does not consistently work. I have fixed this issue and the fixed code will be included in my next update. This next update will occur once I have the new Ping object successful incorporated into the Eddie code.

    One question I have for Parallax is about the units used with the "PING" command. Since the present documentation is not correct about the conversion of returned values to actual units of millimeters and inches, I'm wondering if it would be okay for the "PING" command to return the distance reading in millimeters rather the 1/512 of the clock cycles the pulse takes to reach the obstacle and back. The present units are already 90% the value the units will have if millimeters are used.

    If Parallax would like the units to remain the same, then perhaps a command could be issued to switch to alternate units?

    I should have a version of code incorporating the new Ping object to upload within a couple of days. The next version will also include the fixed "SERVO" command.

    I'm anxious to get these small things done so I can get to work on the real problem of incorporating an integral component to the motor control algorithm.
  • Duane DegnDuane Degn Posts: 10,494
    edited 2015-07-26 20:12
    Here's an update on the code.

    This update doesn't really do much more than the previous code. I did fix the "SERVO" command and the Ping sensors are no long triggered all at once (which caused interference). I still don't have an integral component to the control algorithm yet. Edit: See post #36 for code which includes an integral component.

    I think the big change with this version is it may be used with either the original Eddie Control Board or the Activity Board by changing a single line of code.
    OBJ                             
                                    
      Header : "HeaderEddieAbHb25Encoders141225a"
      'Header : "HeaderEddieHbridgeEncoders141225a"          ' uses one cog
    

    I wired up a h-bridge to the robot so I could test the code using the same pinouts as the Eddie Control Board. I used a QuickStart board as the control board with the h-bridge since the Activity Board didn't have the I/O pins available which were used by the Eddie Control Board.

    Being able to run the version 1.3 code was really helpful. I could see how well the code worked and use it as a comparison for the code I was working on.

    There are a lot of changes to the code but most of the changes are superficial and cosmetic. I've personally gotten used to using the formatting suggested by the Parallax Gold Standard so I changed the code to match the Standard's formatting. I also changed many of the variable names and constant names in an attempt to understand the code. I hope these changes are not too annoying to anyone.

    I don't have time to list all the changes now or why they were made. Many of the changes were made in preparation of implementing what I hope is a better PID algorithm.

    Here's a video of my robot running though some of the navigation commands. The "ARC" command (which now supports reversed directions), the "TURN" and "TRVL" commands are also demonstrated.

    Edit(12/29/14) This is an early test video. To see the most recent version of the firmware in action watch the video embedded in post #41.



    The firmware using the Eddie Control Board is named "EddieBxxxxxxx" ("xxxxxxx" is the version date and letter) and the firmware or the Activity Board with HB-25 motor controllers is named "EddieCxxxxxxx". If I get the position encoder version of the firmware figured out I'll add an "EddieA" firmware version.

    There are still lots of changes I intend to make but I wanted to get something up for people like JackJack.

    Again the "B" version uses the Eddie's h-bridge and the "C" version uses an Activity Board and HB-25 motor controllers. I haven't tested the B version's ADC command yet.

    If the "demoFlag" variable is set to 1, the robot will start driving the course shown in the video.

    Edit: See post #36 for the latest version of the code.
    Edit(12/29/14) To reduce confusion about which code to use, I'm leaving only the latest versions attached to post #36.
  • RS_JimRS_Jim Posts: 1,489
    edited 2014-12-26 05:00
    Duane,
    I tried to run the video and got the response "this video is private"
    Jim
  • Duane DegnDuane Degn Posts: 10,494
    edited 2014-12-26 09:30
    RS_Jim wrote: »
    Duane,
    I tried to run the video and got the response "this video is private"
    Jim

    Thanks for letting me know. I thought I saw it say "Public" when I posted it. Hopefully it's working now.
Sign In or Register to comment.