Robot Remote
Duane Degn
Posts: 10,588
This a a project I'm working on. It's a remote I plan to use to control my robots.
The remote uses a PlayStation 2 controller for input. The remote also has a touchscreen to use as both an input device and to display telemetry from the various robots. The remote also has a SayIt module inside to allow it to accept voice commands.
I plan to use this top post to give an overview of the project. I plan to used this top post as a sort of table of contents for the rest of the thread.
Here are posts so far. Some are just placeholders for future posts.
#1 Project overview and table of contents
#2 Best videos of the remote in action.
#3 Best photos from the thread.
#4 Robots controlled by remote
#5 Software used in the remote.
#6 Bill of materials.
#7 Remote to robot communication protocol.
#8 Build details. Circuit boards used inside the enclosure.
#9 SayIt and EasyVR Comparison
The remote uses a PlayStation 2 controller for input. The remote also has a touchscreen to use as both an input device and to display telemetry from the various robots. The remote also has a SayIt module inside to allow it to accept voice commands.
I plan to use this top post to give an overview of the project. I plan to used this top post as a sort of table of contents for the rest of the thread.
Here are posts so far. Some are just placeholders for future posts.
#1 Project overview and table of contents
#2 Best videos of the remote in action.
#3 Best photos from the thread.
#4 Robots controlled by remote
#5 Software used in the remote.
#6 Bill of materials.
#7 Remote to robot communication protocol.
#8 Build details. Circuit boards used inside the enclosure.
#9 SayIt and EasyVR Comparison
494 x 662 - 104K
Comments
Including touchscreen graphic's slave software.
Enclosure (IIRC, it was from Mouser or Digi-Key. I'll find a link.)
PlayStation 2 Controller
TetraProp Board (Half) Or other Propeller boards which would fit in the space available.
4.3" Touchscreen with Breakout Board
SayIt Module (discontinued) (An EasyVR module would be even easier to use.) $60
Push On, Push Off Switch
Nordic nRF24L01+ Transceiver (I'm using an expensive module from SparkFun. Inexpensive modules should also work.)
Antenna for Nordic Module (Not needed for all modules.)
MCP3002 Analog to Digital Converter Chip (10-bit) (Used to monitor batteries.) $2.30
Wire and Headers
Blank Proto Board $5
1086 Voltage Regulator 3.3V
I had previously used some of Rayman's touchscreens and I thought it would be cool to have a touch screen on a robot remote. I also liked the PlayStation 2 controller since most of the buttons output an analog value.
I previously modified one of the PlayStation 2 drivers to read these analog values.
I was at a loss at how to incorporate a touchscreen with a PlayStation 2 remote. I finally settled on attaching an enclosure to the front of a PlayStation 2 controller.
In order to have a flat surface to attach the touchscreen, I'm using the enclosure upside down from its normal orientation.
I'm using one of Rayman's 4.3" touchscreens. One of Rayman's breakout boards is attached to the inside of the lid.
I added a 3.3V regulator to the breakout board. I also used the extra prototyping holes to hold the piezo circuit.
There's a lot going on inside the enclosure with lots of wires connecting the various parts together.
Here's the inside of the enclosure with most of the components removed.
The enclosure in the above picture still holds a Nordic nRF24L01+ module (red PCB top right), a push button on and off switch (under Nordic module), a piezo speaker (bottom right), a microphone for a SayIt module (bottom left), a 2x4 female header for PropPlug connections (right side above piezo speaker), a power jack intended to be used to charge onboard batteries (above Nordic module).
There are also some power connectors and wires and wires and connectors to get the PS2 signals up to the main control board.
The white stuff holding some of the components in place is Polymorph. Polymorph is great stuff. If you don't have any, get some.
The control board has two Propeller chips. The board was made by cutting one of jazzed's TetraProp boards in half.
The blue circuit board in the picture below plugs into the board with the two Propeller chips.
The relay at the bottom of the picture was used in an attempt to let the remote control the charging of its batteries.
One thing about the touchscreen, it requires a lot of connections. As you can see, there are a lot of wires between the touchscreen breakout board and the board that plugs into the Propeller board.
Getting the lid closed on the enclosure can be a bit of a trick. There are a lot of wires that need to routed to the correct locations.
The photo above is a look inside the enclosure from the side showing the various wires and PCBs. On the far left of the photo is the edge of the touchscreen. Next to the touchscreen is the enclosure's lid. The inside of the lid is shiny enough to reflect the touchscreen's breakout board. The touchscreen breakout board has an orange wire (which is reflected off the lid) on one side and a bunch of yellow wires on the other. These yellow wires connect with the PCB which in turns plugs into the board with two Propeller chips.
Out of view in the above photo is a board I removed from a SayIt module. The SayIt module board can be seen (covered in red electrical tape) in this next photo.
I think it's a bit ironic I went through the trouble of removing the smaller PCB from the SayIt module and Parallax now sells the EasyVR which is pretty much a SayIt module without the added carrier board.
I have previously used four NiMH AA cells to power the remote. The four AA fit into a battery holder at the bottom of the enclosure. It was pretty awkward to get the batteries in and out of the remote. I'm not sure what I'll end up using as a power source for this remote.
In order to take the photo in post #1 with the remote powered up, I used a bench top power supply and powered the remote from wires exiting the bottom of the enclosure.
With the touchscreen on, the remote draws about 280mA of current at 5V.
As I mentioned, I'm still not sure how I'm going to power the remote.
I'm still editing this post, check back for more.
The SayIt used a relatively common voice recognition module which was added to an additional circuit board. This additional PCB make it easier to use the module with a Basic Stamp since it would be plugged into an AppMod connector.
The additional PCB had a LED and a microphone. I removed the circuit board and made a wiring harness for the power, tx, rx and microphone.
Here's a picture of my modified SayIt next to an unaltered version.
I thought it ironic that Parallax now sells the EasyVR which is basically the circuit board from the SayIt. If I could have purchased an EasyVR instead of a SayIt a couple of years ago, I would have been able to save myself the trouble of making these changes.
Here's my modified SayIt (covered with red electrical tape) next to the new EasyVR.
The EasyVR's mic is out of the photo but it's at the end of a wire extension very much like the one I added to my SayIt.
The SayIt's form factor had some advantages for certain applications, but I think I prefer the form factor of the EasyVR over the form factor of the SayIt. The EasyVR also comes with a USB to serial converter which eliminates the need of using a bridge program to let the module communicate with the PC. This makes it easier to test the module and program in speaker dependent words.
I have recently been working on some code to use the EasyVR with a Propeller. Working with the EasyVR was one of the things that got me thinking about this project. Along with using the touchscreen and the PS2 controller, I'm planning on using voice commands to control my robots.
One of the reasons I run out of RAM is I tend to keep adding menus to my touchscreen projects. For example even though this will mainly be a robot remote, I also want it to be able to control our sprinkler system, and our oven and our heat pump and . . . well you get the idea. It's relatively easy to add a menu to the program. Most of the changes are entered into the DAT section. For example here's the text for the menu displayed in post #1.
menuRobot word @mecanumButton0, @mecanumButton1, @roboniButton0, @roboniButton1, { } @hexButton0, @hexButton1, @roombaButton0, @roombaButton1, @otherRobots0, { } @otherRobots1, @otherMenus0, @otherMenus1, 0Most menus are displayed by the same method. This method accept the memory location of the menu as a parameter and then looks up each of the addresses listed and displays the text using the data at the memory location to know how and where to display the button's text. For example, here are the buttons listed in "menuRobot".
The first two byte listed are x and y coordinates of where on the screen the button is to be display. The program also uses these coordinates with the size of the text displayed to keep track of what action to perform when the that particular area of the screen is touched.
The second two bytes are the text color and background color.
The next pair of bytes either lists the action to be taken when the button is pressed or the pair of bytes hold the memory location for the next menu to be displayed. All the buttons in is this particular menu invoke other menus. (Apparently I don't have an "Other Robots" menu yet and I'm using the timers and alarms menu as a place holder.
I'm very pleased with how easy it is to add menus with this system but it sure seems like there ought to be a way to store all this data in a different location than the Propeller's RAM. In other projects I've used a SD card to hold alternative programs. I'm thinking I should add a SD card to this project and store the menu and button data on the SD card.
I haven't figured out how to keep track of what information is where yet. Maybe I could have one program with all this data listed in it and it sorts through it and creates a lookup table with where the location of each menu and button is stored.
I suppose I could have each menu saved in its own file on the SD card.
I'm not really sure how to go about making this change. I thought it might help if I described what I'm trying to do to all of you. I suppose the next step is to add a SD card to to the project. Once I have the hardware in place I can start to work on the software.
Here's the inside of the lid again with some other the other components added.
I used an X-acto knife to cut a slot in the enclosure for the SD card. My X-acto knife skills have appeared to have improved since I cut the hole for the 4x2 header.
Unfortunately the Propeller Memory Card's SD slot isn't the push, push kind. The card has to be pulled from the slot from it's inserted position. This means in order to remove the uSD card from the remote I either need to add a tab of some sort to the card (which I'll probably do) or to carefully remove the lid in order to access the SD card. I don't think the card will need to be removed often so this isn't really a big concern for me.
I'm still coming up with some sort of system of storing the menu and button information on the SD card. Here's my description from the header file I'm using in the project.
CON '' SD Card File System{{ The touchscreen menu information for the robot remote will be contained on a SD card. There will be two master files. One file will have a list of pointers to the names of the various files contained in a second file. This second file will contain the names of the files. The pointers in the first file will make finding the names in the second file faster. If there is room in hub RAM this list of pointer can be copied into the RAM. The first long of the first master file will contain the number of menu files which have been created. The name of this first file will be "ptrList.mst". The name of the file containing names of the menu files will be "nameList.mst". The menu files will have the extension "mnu". }} ' menu enumeration #0, MENU_START, MENU_SET_DATE, MENU_SET_YEAR, MENU_SET_MONTH, MENU_SET_DAY, { } MENU_SET_TIME, MENU_SET_HOUR, MENU_SET_MINUTE, MENU_SET_SECOND, MENU_ROBOT, { } MENU_ROOMBA, MENU_S2, MENU_MINI_HEX, MENU_ROVER, MENU_CHARGE, MENU_ACTIVE_CHARGE, { } MENU_SLEEP_CHARGE, MENU_MECANUM, MENU_MECANUM_HELP, MENU_ROBONI, { } MENU_TIMERS_ALARMS, MENU_OTHER, MENU_OTHER_PRD, MENU_TOUCH_XY, MENU_NUNCHUCK, { } MENU_KNOB_CONTROL, MENU_TV, MENU_SPRINKLER, MENU_SPRINKLER_ADJUST, { } MENU_SPRINKLER_HELPThe pointers to the menu file names will be in the same order as the constants listed above. If I change the names of the files or change the order to the menus, I'll need to regenerate the two master files.
I'm still working on the program to generate the master files. It's been a while since I've used a SD card in a project. I need to relearn how to create and edit files (hopefully it's like learning to ride a bike and the knowledge will come right back to me).
If access to the memory chips on the PSC is faster than SD card access, then I may copy the data from the master files to the memory chips on the card.
So far this is still just a collection of parts. It currently doesn't do anything useful. Hopefully this will change soon.
I've finished the program which writes the menu data to a SD card. It uses two master files. One master contains the file names of the various menus and the other master file lists the location of each of these names within the menu.
Each menu has its own file on the SD card.
This is the same data shown in post #10 but as a file on the SD card.
Since I didn't convert the numbers to ASCII characters, much of the menu doesn't display correctly when I open the file in notepad or when I paste the data to the forum code block above.
I debated making the files ASCII characters but it would have added a layer of complication to convert to and from ASCII and it would also make the files larger which in turn would take more time for the Propeller to read.
It would have been nice to be able to enter the menu data in a spreadsheet but for now I'll stay with writing the raw data.
I'm now working on modifying the original program to use the data from the SD card. I'm very close to the point of testing it.
I have used this to control a robot but unfortunately I did it before the time I made videos of my projects. I'll make sure and make a video this time around.
It's pretty cool to see the menus change on the touchscreen. I also want to use the touchscreen to display telemetry from the robot.
Hopefully I'll have at least the touchscreen menus working this weekend and I'll post a video of the screen once it's working.
re: Unfortunately the Propeller Memory Card's SD slot isn't the push, push kind. The card has to be pulled from the slot from it's inserted position. This means in order to remove the uSD card from the remote I either need to add a tab of some sort to the card (which I'll probably do) or to carefully remove the lid in order to access the SD card. I don't think the card will need to be removed often so this isn't really a big concern for me.
I often make a tab out of tape. Even plain old scotch tape, folded over and stuck to itself (and both sides of the SD card) is plenty strong when pulled in a straight line.
Shirley, I don't need to tell you to keep the tape away from the SD contacts...
Thanks. I've been working on this one for a long time or I should say I started working on this a long time ago. It's been one of many projects that have sat around partially completed.
I'll probably make a tab out of a Brother label. That way I can label the card at the same time.
Here's a shaky video of a couple different menus.
The remote still doesn't do anything useful yet but it's fun to be able to jump from one menu to the next.
The information for each menu is read from the SD card. There's a lot of debug information being sent to the terminal right now. I think the debug information is slowing the menu transitions more than the SD card reading.
I was able to free up some more memory so I now have 655 free longs.
I still have a lot of work before I can use this to control a robot but it seems to be coming along. I'm very pleased to be able to keep so much information on the SD card rather than in the Propeller's RAM.
I had previously modified one of the PlayStation objects to take advantage of the PlayStation 2 controller's analog buttons. Did you all know most of the PlayStation 2's buttons are pressure sensitive? Well they are and I think it's pretty cool.
After updating my old object to conform to the Parallax Gold Standard (except I don't include all the comments the GS calls for), I got the controller to work with the remote again.
Here's a video of text changing from green to red based on which button is pressed.
Here's the thread with my version of the PlayStation 2 object. I'll clean up my latest version and post it sometime this weekend. If any of you have a PlayStation 2 controller, I hope you test my object. I personally think the analog buttons are really cool. I think they may come in handy for controlling my hexapod.
Besides the addition of reading the analog buttons I also made the object continuously update the various joystick and button variables in the parent object. The button information is stored as individual bytes for each button to make it easy to check if a particular button has been pressed and the button information is also stored as bits in another variable so the program can quickly check for buttons pressed in combinations.
One of these days I'll add a way to control the vibration motors. (If anyone is wants this for a project, let me know. It will probably motivate me to work on it sooner.)
I think it's time for me to start adding a Nordic nRF24L01+ module to my Mecanum wheeled robot. The robot currently uses a radio receiver intended for airplanes and helicopters. I want to convert the control interface to use the Nordic transceivers.