Shop OBEX P1 Docs P2 Docs Learn Events
Wireless differential steering creates another problem — Parallax Forums

Wireless differential steering creates another problem

I finally succeeded in controlling my bot project with a joystick. I'm using two Propellers and two nrf24L01 tranceiver ic's. It took a couple of months to get it done.
My next test will be to turn an LED on/off with a button. I want to send a binary "32" (LED pointer) and a "1" or a "0" (on/off). This represents one line of code in Spin. Maybe the solution is simple but I'm stuck. (There are some brilliant roboticists in this forum so it doesn't hurt to ask for help)
The problem is that differential steering requires five (byte) data packets while everything else I want to do only needs one byte packet.
IOW, when I transmit "%0001_0000" it accomplishes several things: It says "motors", it aligns the incoming data with a variable array and it clears the "idx" variable. Dropped packets were a problem.

Differential%20Steering.jpg
872 x 486 - 54K

Comments

  • lardom wrote: »
    The problem is that differential steering requires five (byte) data packets

    I think you've jumped from Step 1 to Step 14, without filling in the rest (or maybe your post requires following another thread?). Why does differential steering require five (byte) data packets? You can do it in half a byte, depending on the features you want.

    I take it the purpose of the exercise to reduce the bytes required to indicate motor control is because you're losing data somehow, and you want to simplify the stream. So you want to control everything with one byte. If so, could you be more specific how you're mapping the bits in the byte you are sending, and what you are expecting to control in the motors other than direction.

  • lardomlardom Posts: 1,659
    edited 2016-02-14 20:58
    lardom wrote: »
    The problem is that differential steering requires five (byte) data packets

    I take it the purpose of the exercise to reduce the bytes required to indicate motor control is because you're losing data somehow, and you want to simplify the stream. So you want to control everything with one byte. If so, could you be more specific how you're mapping the bits in the byte you are sending, and what you are expecting to control in the motors other than direction.
    Five bytes to control the DC motors works perfectly for me. In fact, I tested it out last night and it worked better than I thought eventhough it still needs a few tweaks. (One day I'll post it if there's any interest.)
    I use two i/o pins per wheel with pwm to control speed, direction, turn and rotate.
    I eventually want to add pan/tilt and an arm with a gripper. I got the idea from "vanmunch". I've wanted to build something like it ever since.
    Having taken a fresh look at the code snippet below I'm going to test if CurrentSpeed == 32.
    repeat       'Wait for incoming data
        if ina[SpiIrq] == 0     
          Nordic.ReadPayload(@globalPayload0)
          CurrentSpeed := globalPayload0    
          if CurrentSpeed == 16
            test_var[idx]~     
          test_var[idx++] := CurrentSpeed   
          if idx==4          
            Lmtr.main(test_var[1], test_var[3])
            Rmtr.main(test_var[2], test_var[4])
    
  • ercoerco Posts: 20,254
    I'm also midstream in a project for short-range radio control using a single 433 or 315 MHz tx/rx pair (the dollar types on Ebay) to control a diff steer robot with two CR servos. I'm making my own communications protocol, basically sending different sequential pulsewidths to control 2 servos and one or two other pushbutton on/off functions. It's at least twice the work, tweaking both the transmitter and receiver programs at the same time. I make the fastest progress having two PCs up & running, one on each end.

    A fun and challenging project, highly recommended to teach patience. I did learn that the quality those cheap radio modules varies wildly, a third don't work at all, and from individually testing 3 different sets I could get one good pair with acceptable range, one mediocre range and one DOA.

    Another fun fact (pay attention Publison!) is that I'm using analog joysticks with pots & ADCs. I tried the ones I mentioned recently and found that they are non-linear, most sensitive midrange and not sensitive near the endpoints. I found others I like better. In this case, I got what I paid for.

    The video below shows my setup which does not use the radio or pot yet. I got sidetracked testing audio through the fixed-tone buzzer.

  • erco, I couldn't walk away from the nrf24L01 chips because they were insanely cheap. I bought two to test and then I bought ten more.
    Duane Degn wrote an object than allowed you to put both chips on one Propeller. That made it easy as cake. Now I plug my 2nd board into my wife's desktop.
    It is "...twice the work" but it's also "twice" the payoff too.
  • erco wrote: »

    Another fun fact (pay attention Publison!) is that I'm using analog joysticks with pots & ADCs. I tried the ones I mentioned recently and found that they are non-linear, most sensitive midrange and not sensitive near the endpoints. I found others I like better. In this case, I got what I paid for.

    Duly noted, I'm still getting the Diptrace footprint finalize for the original joysticks. Many irons in the fire.



Sign In or Register to comment.