Shop OBEX P1 Docs P2 Docs Learn Events
A Portable Programmable Robot Controller — Parallax Forums

A Portable Programmable Robot Controller

nchlornchlor Posts: 21
in Customer Projects

My objective was to design a portable controller which could be used to control wheeled robots in any environment, as well as receive sensor data. The attached figure shows the result.

The core of the programmer is Geoff's Explorer 100 board which uses a 100 pin pic32 running MMBasic Plus. This system has several advantages over other choices. A display (SD1963 LCD panel) can be plugged into the board. The display includes a SD card for data and program storage. MMBasic+ has a rich set of graphical commands, in addition to supporting keypads. The keypad can be programmed in different modes, effectively increasing the effective number of keys greater than 16. Most important, the keypad program runs in the background. An additional feature of the controller is a set of 8 push buttons which execute commands independent of the keypad. Communication is through an XBee.

When the programmer is powered on, the screen shows a list of robots recognized by the programmer. All robots must have the same command syntax. All my robots are controlled by propeller chips programmed in Tachyon Forth. RCL.pdf shows the structure of the control language. While only two-wheeled robots are shown, the programmer is designed to handle 1 to 4 wheeled systems. RCL_Keypad.pdf shows how commands are defined in different keypad modes.

This figure shows the display after a robot selection.  It has the following features.

-- Current selected keypad mode - in this case, Defined Motions-2.
-- Area for entering parameters, eg, inches and degrees.
-- Settings specific to the selected robot, in this case, the BOE.
-- Description of the last entered command.
-- List of commands in order executed.
-- Dynamically updated data
- Wheel Speeds as % Duty - Encoders - Servo Angle (if enabled) - Ping Distance
- Heading & Acceleration (If enabled) - Execution Time of last entered command

When a robot is selected, the operation mode is displayed and the program executes a continuous loop, displaying updated sensor data. Executing a keyboard command, momentarily halts the loop.
This can be observed by simultaneously running a XBee connected terminal emulation.

Nick

pdf
pdf
RCL.pdf
49K
pdf
pdf
RCL_Keypad.pdf
117K

Comments

  • Duane DegnDuane Degn Posts: 10,588

    Very very cool.
    It would be great to see your controller in action.
    How many robots do you presently have which can be controlled with this device?
    How come we haven't seen any of your robots performing a figure-8?
    Thanks for sharing your project with us.

  • MicksterMickster Posts: 2,698

    I have several CNC machine-tools that use the same Explorer E-100 board.
    MMBasic is very capable B):+1:

  • nchlornchlor Posts: 21

    Duane:
    Thanks for the comments.
    I will have to define a figure-8 maneuver.
    I am working with 8 different robot platforms, each of which have different features, eg, no. active motors, sensors, etc.
    I would appreciate your comments concerning my attempt at defining a universal robot control language?

    Mickster:
    The Pic 32 running MMBasic is my second microcontroller choice after the Propeller running Tachyon.

    Nick

  • MicksterMickster Posts: 2,698

    Same here; heck of a combo. Except I like to stick with BASIC and PropBasic is still my "GOTO" language for the P1.

    I do have another cool alternative to MMBasic, though for when I need more speed. It's called ByPic and no-longer being developed but it works on a 40MHz PIC32MX170 and runs ~8 X faster than the E-100 @120MHz :)

    Same on-chip programming and supports up to 20 tasks. Combination of BASIC, C and Forth. Awesome front-end for the Prop1 :+1:

  • Duane DegnDuane Degn Posts: 10,588

    @nchlor said:
    I would appreciate your comments concerning my attempt at defining a universal robot control language?

    That's a tough one.

    When I adapted the Eddie firmware to use on a Propeller Activity Board and HB-25 motor controllers, I used the same commands as had been used by the Eddie robot. In order for the robot to perform a predetermined set of actions, I added a mode to the robot which would allow it to parse commands which had been listed in RAM.

    Here's the section of RAM with the list of instruction addresses.

    DAT

twoByOneMRectanglePlusTwo8s     word @straightF2000mm, @leftTurn, @straightF1000mm, @leftTurn
                                word @straightF2000mm, @leftTurn, @straightF1000mm, @right180
                                word @straightF1000mm, @rightTurn, @straightF2000mm, @rightTurn
                                word @straightF1000mm, @rightTurn, @straightF2000mm, @left180
                                word @straightF1000mm, @leftTurn, @straightF500mm
                                word @rightCircleF299mm, @leftCircleF299mm
                                word @rightCircleF500mm, @leftCircleF500mm, 0

    The above list caused the robot to perform the actions shown in the video in this post. Here are the instructions located at the address listed above.

    DAT ' script buffers

leftCircleF500mm                byte "ARC -360 149 50", 0
rightCircleF500mm               byte "ARC 360 149 50", 0
leftCircleF299mm                byte "ARC -360 89 50", 0
rightCircleF299mm               byte "ARC 360 89 50", 0

straightF2000mm                 byte "TRVL 596 50", 0
straightF1000mm                 byte "TRVL 298 50", 0
straightF500mm                  byte "TRVL 149 50", 0
straightF2000mmFast             byte "TRVL 596 100", 0
straightF1000mmFast             byte "TRVL 298 100", 0
straightF500mmFast              byte "TRVL 149 100", 0

leftTurn                        byte "TURN -90 50", 0
rightTurn                       byte "TURN 90 50", 0
leftTurnFast                    byte "TURN -90 100", 0
rightTurnFast                   byte "TURN 90 100", 0
left180                         byte "TURN -180 50", 0
right180                        byte "TURN 180 50", 0
leftSpin5Rev100                 byte "TURN -1800 100", 0
rightSpin5Rev100                byte "TURN 1800 100", 0
rightSpin10Rev50                byte "TURN 3600 50", 0
leftSpin10Rev50                 byte "TURN -3600 50", 0

    Seven years ago, I tried making my own robot remote. I used a PlayStation 2 controller with touchscreen and a couple Propeller 1 chips to run it all. I had fun with it but it was also crazy complicated. Many of my Propeller 1 projects ran into trouble because of the limited RAM.

    I'm certainly not against reinventing the wheel (or robot control system) but I often wonder if I should be learning to use some of the available resources others have developed. The Eddie firmware could be controlled by the Robot Operating System (ROS) but I haven't used ROS myself. Another established control system is the ArduPilot/ArduRover software. I'm presently trying to learn how to use this software. ArduPilot uses MAVLink for communicating. I haven't learned enough to give an educated opinion about this system but it's something I'm presently trying to learn about.

    One of the dilemmas when making your own communication protocol is the decision to use ASCII characters or not. ASCII protocols like the one used with the Eddie firmware are easier for a human to interface. The problem with ASCII protocols is they are so much slower than a digital protocol. A digital protocol needs a way to establishing packet sizes and usually have a checksum field to make sure the data is complete. I've used both types of protocols many times myself. If a user is giving commands over a keyboard, often ASCII is the my preferred choice. If I have large amounts of data to move, then I use a digital protocol and required housekeeping fields to make sure the data isn't corrupted.

    Sorry for the long post. I think a lot about this sort of stuff and when asked about this topic, I have a hard time giving a short answer.

  • nchlornchlor Posts: 21

    Duane:

    When I suggested a uniform RCL, I meant it in terms of the syntax, not the control language actually used (forth, MMbasic, python, even Spin). I Have looked into ROS and found it too complex. This complexity is evident in your examples. For example, straightForward2000 would be 2000 GF (forth) or GF[2000] (basic or python) at a specified speed. I believe the RCL should be simple, eg, If I want to rotate a robot to the right I execute RR. If I want to turn a specific angle, I execute 45 GTR or GTR[45].

    You mention digital protocols. This is used by Sphero's RVR robot, which require sending api's to the robot. I have used Tachyon to define the necessary api's to control the RVR with a propeller.

    Nick

  • MicksterMickster Posts: 2,698

    I no-longer use this device but I really liked the protocol (binary) and so I adopted it as my standard using the E-100 as the master:

    See attached.

    Regards,

    Craig

    pdf
    pdf
    picsrvsc.pdf
    294K
  • nchlornchlor Posts: 21

    Craig:

    Thanks for the info on this device.

    Nick

Sign In or Register to comment.