Monday, September 12, 2011

Sept.11-12 Lego Arm application working

Following application does a simple test of the Lego arm
  • turning left / right
  • up/down  (drifts down - because of weight of motor(?))s
  • open/ close


Saturday, September 10, 2011

Sept.9 Application Time - Robot Arm

Chose 3 robots, which use few parts, to build and use with test applications,
First Lego arm to test motor FB in applications and for something new and 
because the other 2, (a CarBot, NXTway) use motors.


New motor FB since easiest to change directions in an application via a boolean:


Test 1: Test each motor going back and forth.  Same test was used for all 3 motors.
First simple alternating test with Flip-Flop
Test 2:  Used 2 Touch sensors - 1 turned motor on and 1 reversed the motor direction (both had to be pressed at same time)

Test 3:  Should allow testing of all 3 motors in 1 test.


Lego Arm test reflections / results:
1. Discovered easiest to change motor direction with BOOL input variable, 
so new Motor FB. 
Open: How to switch between on/0/off = tri-state
This is a general problem. Ref: http://www.societyofrobots.com/member_tutorials/node/161

2. Then a good test for changing directions  is using a flip-flop.
Created a F_FLIP FB that is a flip-flop built with 2 delays and 1 SR. 

This design was chosen because it uses 2 rather than 3 types, since each 
downloaded FB type takes more or the limited space.


Using F_FLIP FB there are timing issues. Usually goes back and forth, but sometimes misses one and goes twice in the same direction. Solution is probably to use E_CYCLE even if it an extra FB Type has to be downloaded.


3. Physical results:
  • Open/Close
    • hit on bottom of the other claw
    • needs short times and little power
  • Up/Down 
    • Down is noticably faster than Up due heavy motor on the end of the arm
    • Flop-flop with 2 equal delay times allows it to wander down fast.
    • Can hit on motor if goes to far over
  • Left / Right - works as expected


Friday, September 9, 2011

Sept.8+ Optimizing for size

Using -Os to compile LMS drops the size from 24k to 17k.
But even boot blinky doesn't work...... more to come.

Tuesday, September 6, 2011

Sept.6 Testing Composite FBs

Composites are working: LC_AD, LC_TOUCH, LC_LED, LC_LT, LC_SOUND
eCos and Forte keep getting smaller.
More interesting was using 1 application, but various combinations of FBs. 
For example testing FBs in the composite network before testing the composite FB.
Another example shown below is the application that was used to test both LC_LT and LC_SOUND. Since both sensors are on port 1, both sensors cannot be mapped to the device during the same test.


Monday, September 5, 2011

Sept. 5 Smaller Forte and ecos

New smaller Forte and eCos packages, so back to 1 version to test.  0904cyg 
Can finish testing all new LMS FBs now...  (current size: edef4)


Test Cases
  • Compiles, Links, Boot Blinky: -works
  • 4 LED app -works
  • FlipFlop app 1 -works
  • FlipFlop app Cycle -works
  • Touch LED on app  - LC_TOUCH not working
  • Reads app - also not working.... backing off to test the FBs that make up the composites
  • Motor on app  -works
  • 3 Motors on app - uses TOUCH sensor to turn on

Sunday, September 4, 2011

Sept. 4 LMS FB clean-up tests


Forte has grown as it has stabilized, not leaving much room in 256K for lms FBs 
LMS FBs C++ /  4diac 0.4 are cleaned up; Now using Composite FBs (see previous post)

Testing one after the other 3 base versions : 
  • 0904cyg; With current forte with LMS NXT modification compiled into ecos package 
    • BASE is TOO LARGE now. Only L_LED fits
  • 0904:   With current forte (1.0)    
    • The base forte has grown!
    • 727z:      With 0727 forte
      • all LMS HW functioned prior to using composite FBs
    Tests: black works, grey not yet tested, orange fixing
     note: have to change apps to use most current FBs wtith sensor type.
    • all compiles and link
      • 727z, 0904, 0904cyg
      • Boot Blinky:
        • 727z, 09040904cyg
      • 4 LED app: (deploy works)
        • 727z, 09040904cyg
        arm-elf-size forte.elf  size Info
        1. with LMS NXT modification compiled into ecos package 
        Linked fine,but its too large now, think it should be same size since it should have just changed locations, but
        with all LMS FBs  size is 42d9c > 4000  = 256K (max) 
        Only small enough with just LED FB : 3fd34
        Both Boot Blinky and deploy of an application work.
        [Could this be the large eCos version that caused similar space problems in Feb.?]

        2. With current forte (1.0) = 0904 forte
        when I changed to the most recent forte and it has grown!!!
        3f8e8 !!!!  Max is 40000x =256K
        3a214 is smallest with only the old Boot Blinky code and no AVR initialization
        changing the queue parameters makes no difference to the size 

        What caused it to grow so much? Anything else that can be left out?

        3. With 0727 forte
        0727 forte 3f69c with all LMS FBs in previous post.

        Minor side notes:
        1. Did some optimization and found the local variables sometimes make it smaller, but in the case of L_LED it was smaller using local variables.

        2. Finishing up the lms code I tried to move all the port related code in the FB L_S_PORT, but had problems moving the static constant arrays that were initialized and private methods into the exported code. Not a priority, but if you understand this cryptic description and have hint I will try again... otherwise I will leave the code in a separate class.  

        Thursday, September 1, 2011

        Aug. 30 New LMS Composite FBs design

        Below is the new LMS composite FBs design