LED_and_Switch_test.spin_.txt (1322Bytes)
Robot_Remote_Controller_2010.04.10.010.pdf (34244Bytes)
RoBo_Remote_v9_-Archive__Date_2010.04.20__Time_21.02.zip (32710Bytes)
RoBo_Remote_v20.spin.txt (11238Bytes)
RoBo_Remote_v23_-_UPEW_Archive__Date_2010.07.03__Time_19.46.zip (29439Bytes)
UPDATED: 2010.07.03
I haven't posted anything on my robot TOBI - The Tool Bot for a while because I have been working building a new Remote Controller for TOBI. The RoBo Remote is the result of my work. I originally purchased everything for my remote but all the parts ran on 5V and my Propeller runs on 3.3V. I went through several redesigns and newer hardware kept coming out that was 3.3V. Size has always been my issue as well as complexity of design. The Propeller chip called the PropStick has an on-board 3.3V regulator that I could use to power other 3.3V devices. I wanted to use that and not have to have a separate 5V regulator and the extra interfacing resistors to run parts that are 5V.
New Developments:
Parallax released a book on the Propeller "Programming & Customizing the Multicore Propeller Microcontroller: Official Guide" and in there, there is a chapter on using XBee tranceivers for setting up a 3-node robotic network. After reading just a few pages, I was hooked on the XBee's. Since they were only $20 a device, I bought two.
The old accelerometer I had is a 5V 2-Axis one and I wanted 3.3V version. Parallax recently released one and I picked that up as well.
Planning:
After reading only the first part of the chapter on the XBee's I found that they can be set to an ID number and you can form packets to be targeted to specific ID's and all other XBee's will ignore the transmission not sent to them. This is when my TOBI remote became a general RoBo Remote. Since I have another robot I wanted it to be able to control that one as well.
Assembly:
First off I had to assemble the XBee carrier boards. I bought two and a carrier board with a USB interface to program the XBee's from the computer.
One XBee on a carrier board for my breadboard and one to connect to my computer via USB adapter.
Next I wanted to breadboard the circuit and all of my breadboards are tied up so I went to Radio Shack to pick up some parts for the project and a breadboard.
I got a nice circuit board for the project
and two boxes of various sizes but this is the one that I used
There is one thing that I HATE about Radio Shack and all who have shopped there have seen this, they sell circuit boards of many sizes AND they sell project boxes of many sizes BUT they NEVER sell a circuit board that fits inside a project box!
I had to modify the screw holes and cut grooves into the board to make it fit inside the box
I played around with some layouts
I tested all of my parts on a breadboard and found that the PropStick did power my XBee and new I2C Accelerometer just fine.
I put the XBee in loopback mode by connecting the TX pin to the RX pin so that it would send out everything that it received back to my computer diagnostic software.
After that I wired up my accelerometer and sent the readings to the computer via the XBee link
I worked on the interface of the RoBo Remote next.
So at the top left is an LED illuminated power switch with 3 slider switches to the right that I will use to set the XBee to transmit to different ID’s. Using a binary read of the pins I can address 8 robots or ID’s with this device.
Next is a row of LED’s: Red, Yellow, Green and VERY bright Blue
Below that are three more slider switches and 4 pushbutton momentary switches. I have not decided what any of these will do yet.
Here are the switches installed and my board layout settled
So drew up a schematic; See Attachment
Then I wired up the board and tested at every step to make sure of the connections
I put all the parts on the board and hooked up the power to run the same test as on the breadboard
AND IT FAILED!
I thought that I may have fried my PropStick. So I opened a thread in the Parallax Forums [even though it was a weekend] and I was helped by other users to find the solution and get back up and running. The Forum community helped me find the issue even before Parallax had time to respond [since they were closed at the time]. Notice the headers that I soldered onto the board. I wanted to be able to remove the cover completely.
Next came the soldering of the spaghetti.
And then putting ends on each wire
The finished switch and LED wiring
The total finished project guts all connected and tested
The Grue was satisfied with the results
The Video has just test code loaded to test the LED’s and switches. I will post the real code as I develop it.
UPDATE: 2010.04.19
I just completed the writing of two Objects of code and had a successful test with TOBI (video to come when daylight is available). The code structure looks like this:
RoBo_Remote_v8.spin
│
├──XBee_Object.spin
│ │
│ └──FullDuplexSerial.spin
│
├──Acc_2_Servo_v4.spin
│ │
│ └──MMA7455L_SPI_v2.spin
│
└──Conduit.spin
Each of these is an Object that has its own variables and subroutines (called methods and they start either with a “PUB” or “PRI” heading). Each Object can call other Objects to access more methods for further processing.
First I worked on the Accelerometer code in steps until it gave me 4 digit numbers that can be plugged into my servo Object on TOBI. This Object eventually came to be called “Acc_2_Servo_v4.spin”. I made it initially as a stand-alone top Object that just displayed numbers on the Terminal screen. When I got the numbers that I needed I turn it into an Object that other Objects could call and pass 2 variable addresses for it to store the results in.
Next I worked on another Top Object to call the Acc_2_Servo_v4 Object that I eventually called “RoBo_Remote_v8.spin”. RoBo_Remote_v8 first tests the LED’s with a display pattern. Then initializes the accelerometer Object and programs the XBee radio. The bulk of the work is done in “PUB SendControl”. First it checks my top three slider switches to see if I changed them. If so, it calls a method that will read them and reprogram the “SendTo” address on the XBee radio. Next it checks to see if my right slider switch is off or on. If it is off, it calls the XBee Object to send a simple “h” (that stands for Halt on the robot end). If the switch is on, it calls my Acc_2_Servo_v4 to read the accelerometer and gets back two variables: “LeftPulse” and “RightPulse”. Then it calls the XBee Object again and first it sends a simple “d” (for Drive) followed by the RightPulse and the LeftPulse variables.
It was surprisingly simple for someone who only started learning Spin this January. The fact is that you do not have to know how someone elses code works as long as you know how to call it and if the writer is good on his in-code documentation then he/she will tell you how to call code and get back the results.
Lastly, is that I have attached a zip file (RoBo_Remote_v8_-_Archive__Date_2010.04.19__Time_22.20.zip) which is the Archive feature of the Propeller Tool that includes all Objects that make up this project. I created only 2 of them but all of the others came from the OBEX or the product page on Parallax.
I will have more postings on TOBI’s page as I work with both devices.
UPDATE: 2010.04.20
I altered and enhanced the code by adding a maximum speed limit by adding two variables PulseMax and PulseMin plus I brought the TurnAdjust variable out of Acc_2_Servo_v6 Object so that I can adjust my turn ratio from the top object. So all of my limits and ratio’s are now passable to the Acc_2_Servo_v6 Object for more versitility in adjusting the movements and speeds of TOBI. I also added a second speed of TOBI. I programmed the RoBo Remote to send pulses of half speed unless the middle slider switch is on. So in a sense, I have an indoor speed set as default and a higher outdoor speed.
I ran into an issue with the slow speed. The max speed limit was set to 1750 and I noticed that if I tilted the remote full forward and then to right or left to turn, TOBI would not turn. I had to go back to the drawing board so to speak. I re-ran the old accelerometer Object that is standalone and assigned my lower limits. Again the problem of turning at full throttle appeared. I solved the issue by adding a line to the code:
Forward := PulseMin #> Forward <# PulseMax
This applied my limits to the Forward variable first. Otherwise it could store up to 2000. If it stored 2000 then the max Turn value of 250 would still be above the limit and thus TOBI would not turn as you can see by the following 2 lines of code to set the Pulse variables:
long[LeftPulse] := PulseMin #> Forward + Turn <# PulseMax ’ Write result of Forward and Turn back to the Variable LeftPulse
long[RightPulse] := PulseMin #> Forward - Turn <# PulseMax ’ Write result of Forward and Turn back to the Variable RightPulse
So I also needed to compensate for my variable TurnAdjust by rewriting how I computed the Forward variable from the two X and Z variables like this:
LLimit := TurnAdjust + PulseMin
HLimit := TurnAdjust + PulseMax
’ Find common forward speed from X and Z-axis
if Z =< -1
Forward := (LLimit #> ((X * 50) + 1500)) ’
else
Forward := (((||X * 50) + 1500) <# HLimit)
This is how I figured out the problem. TOBI is nice and manuverable indoors and fast plus agile out of doors. Time for a Road Test!!! I want to shoot some video but my camera is broken. Somehow I will get some video.
UPDATE: 2010.04.23
I have been working on both the RoBo Remote and TOBI - The Tool Bot projects since they interface with each other. The hardware is done on the RoBo Remote and only the programming needs to be completed. But as I see it, it will never be completed because that is the way I designed it. To be versatile and programmable. So I consider this project as completed. Any further programming for my current and future robots will be posted on their pages. I leave you with parting video of RoBo Remote controlling TOBI - The Tool Bot.
UPDATE: 2010.05.09
I completely rewrote my RoBo Remote code so that it would be compatible with my other robots like the Beast! I decided to just send X and Y values and let the robots themselves to convert them into the correct pulse width’s. I also launched a separate Cog just to monitor my buttons in real time. I ditched my Accelerometer Object in favor of a larger top Object that is easier to share global variables even in different Cogs. Also I added a Reverse mode where the robot will move backward when I tilt the RoBo remote forward. This may seem silly at first but it makes it very easy to run the robot caster first or drive wheels first, depending on terrain. More to come later…
UPDATE: 2010.07.03
I finally deciced on the functions of the buttons for the RoBo Remote [at least for TOBI].
So starting from the top left:
PWR = Power
TX ID = The XBee transmitter ID that I am sending commands to.
INFO = Display diagnostic info on the LCD or an informational display
FOLLOW = “Follow Me” mode for the robot to follow a human controller
HALT = Basically just that, it stops the robot
REV = Reverse mode to drive TOBI wheels first when turned on instead of caster first.
SPD = Speed. Off=Indoor speed. On=Outdoor [high] speed.
DRV = Drive. Sends accelerometer readings to the robot with some other variables to basically RC the robot
OVERRIDE = Momentarily overide all sensors except bumper sensors
So that is the current list of functions in the RoBo Remote. To further explain, the TX ID is used to address my packets of date to a particular XBee with that number set as the MY_Addr. This came in handy at the Propeller Expo since TOBI was set to ID 1 and there were other robots set to that address. I had to get into TOBI’s code to change it to 4 and you see in the picture that the three switches are set to 4 in binary. Also the RoBo Remote itself was set to ID 0 and the connection to TOBI kept dropping out. So I changed the RoBo Remote code to set the MY_Addr to ID 7. After these changes, the RoBo Remote and TOBI traversed the Expo with no further interference.
DRV was the first for me to program. It sends the accelerometer data to the robot to be converted into drive pulses. SPD followed closely since the robot was very easy to drive into walls and other obsticles indoors at full speed. I needed an indoor speed and a full speed setting. REV followed, because I found that TOBI could get stuck on the smallest of door frames running caster first but could get over them running wheels first and still be able to drag the caster over.
The HALT and INFO buttons were just to fill space although I think the halt button could come in handy with the FOLLOW me mode. Yet it could just as quickly be achieved by turning off either mode with their respective buttons. The INFO button will be changed to altering a “Diagnostic” variable that can be transmitted in order to put the robot into a diagnostic mode or to display diagnostic information on its’ LCD screen or transmit it to a propeller driven monitor for displaying.
I uploaded my latest code that I worked on at UPEW. Several people wanted to see the code and now it is finally here!
Project : "RoBo_Remote_v23"
Archived : Saturday, July 3, 2010 at 7:46:08 PM
Tool : Propeller Tool version 1.2.7 (R2)
RoBo_Remote_v23.spin
│
├──XBee_Object.spin
│ │
│ └──FullDuplexSerial.spin
│
├──MMA7455L_SPI_v2.spin
│
└──Conduit.spin
NOTE: Above mentions that one of the objects used is called “Conduit.spin”. For those who have never used the Propeller, Conduit.spin is part of the “ViewPort” diagnostic debugger suite from HannoWare. With this enabled, I can view and edit on the fly all the variables in the Propeller at run time.
i saw the video of you driving with the accelorimeter , cool ? yes . functional ? , no…