Real-Time Motion 3D Graphical Model of an FRC Robot

1
Real-Time Motion 3D Graphical Model of an FRC
Robot

• 2006 FIRST Robotics Conference
• 4/27/2006
• Team 176 Aces High
• Tony Zurolo Roger Ignazio III

2
Motivation

• Hardware is not always available to test ideas
• The robot may not be ready until late in the
  design / build period.
• Limited time for control system software checkout
• Visualization of sensor data is difficult
• This is especially an issue for autonomous period
  programming

3
Brief Overview of the Project

• Program to display a 3D graphical model of the
  robots arm
• Can select between three data sources
• GUI controls
• Live Robot Data
• Recorded Data file
• Can Record the selected data source to a file

4
Software Architecture
Robot Object Model
Claw / Wrist
Forearm
Dashboard Port
Abstract Robot Data Interface
Position Data
Upper Arm
Recorded File Data
GUI
Body
Shoulder
Shape-drawing commands
View Manager (GUI Event Handler)
GUI Events
View Commands
Heavy use of Open Source packages
wxWindows / OpenGL
5
Software Architecture

• Inter-object linkage
• All you have to do is connect the parts
• Display update is independent of model state
• Important for timing considerations
• Model parameter update is event-driven
• Multi-threaded application

ras1.connect_to(rasb1) ras2.connect_to(ras1)
claw1.connect_to(ras2)
6
Robot Parts

• The parts are concrete instantiations of an
  abstract base class.
• They respond to change events
• They know what they are connected to

Claw
SwivelBase
ArmSection
7
Robot Parts

• What theyre made of
• Normally drawn with OpenGL Quad Strips and
  Triangle Fans

8
Software Architecture

• Class Hierarchies

SolidCylinder
Pipe
ShaftBearing
AngledBlock
RectangularBlock
9
Software Architecture

• Class Hierarchies

RobotMovablePart
RobotArmSection
RobotClaw
RobotArmSwivelBase
10
Software Architecture

• Event notification
• Transforms
• Optimization
• Lazy evaluation
• Caching
• CPU is swamped without these

if (claw1.set_angle(new_angle)
notifier-gtnotify_of_change()
11
Software Architecture

• Recorded data format
• Delta time, but summed to keep in sync with
  absolute time

0 -0.184 -1.93 0.202 0.589 1 0 0 130 -0.202
-1.93 0.202 0.589 1 0 0 30 -0.184 -1.93 0.202
0.589 1 0 0 70 -0.202 -1.93 0.202 0.589 1 0
0 170 -0.184 -1.93 0.202 0.589 1 0 0 100 -0.202
-1.93 0.202 0.589 1 0 0 30 -0.184 -1.93 0.202
0.589 1 0 0
12
Hardware Architecture

• Potentiometers connected to controller A / D
  inputs
• Limit Switches connected to controller digital
  inputs
• 115kbps Serial link to laptop

13
Robot Controller Programming

• Dashboard packet overview
• Slots available for user data
• Custom packets (for EDU controller)
• Sync byte
• Checksum
• Controlling packet timing

14
RC ProgrammingEDU Packet Overview

• Data is sent from the EDU controller to the
  RoboSim program via the IFI Dashboard packets
  user byte reserves.
• Sync packet (0xFF) does not appear anywhere else
  in the IFI dashboard packet. RoboSim can scan for
  this, and when found can sync up with the
  Operator Interface.
• EDU Program then sends all other bytes for base
  angle, shoulder angle, etc.
• As the bytes are sent, they are added to a
  checksum in the EDU controller.
• At the end of the packet, all values have been
  added to the checksum and it is sent as the final
  byte of the packet.

15
RC ProgrammingAn Excerpt from user_routines.c

• AHPrintChar(0xFF) // start
  byte
• AHPrintChar(base_angle) // put the
  base angle in the packet
• checksum base_angle // include
  the base angle in the checksum
• AHPrintChar(shoulder_angle) // put the
  shoulder angle in the packet
• checksum shoulder_angle // include
  the shoulder angle in the checksum
• AHPrintChar(elbow_angle) // put the
  elbow angle in the packet
• checksum elbow_angle // include
  the elbow angle in the checksum
• AHPrintChar(wrist_angle) // put
  the wrist angle in the packet
• checksum wrist_angle //
  include the wrist angle in the checksum
• AHPrintChar(claw_byte) // put
  the claw bits byte in the packet
• checksum claw_byte //
  include the claw byte in the checksum
• AHPrintChar(checksum) // end the
  packet with the checksum

16
RC ProgrammingControlling Packet Timing

• Controlling packet timing is essential to prevent
  overload on the RoboSim program as well as the
  transmission between RC and OI.
• To do this, we use a counter that will only send
  a packet every X number of iterations.
• We currently use a delay of 2, which means that a
  packet is sent every other iteration.
• After the counter hits 2, it will reset to 0 and
  begin the process again.

17
RC ProgrammingControlling Packet Timing (cntd.)

• Excerpt from user_routines.c
• //Routine starts
• delay_counter
• if(delay_counter gt 2)
• / The packet routine goes here /
• delay_counter 0

18
Out-takes

• Whats your sign?

19
Out-takes

• Haste makes waste

20
Out-takes

• Bad Hair Day

21
Demo

• GUI Control of model
• Zoom, Pan
• Live Robot Data
• Recorded Data

22
Applications of this Project

• Visualization and Prototyping of ideas
• Driver / Operator Practice
• Training films using the recording feature
• Can serve as a basis for learning graphics
  programming

23
Continuing Development

• Rapid Prototyping of Robot / Simulation
• Robot construction set
• Reconstruction of robots sensor view of its
  world
• Sensor calibration
• Two-way communication for closed loop control
  development
• Students will have an opportunity to continue the
  work

24
Acknowledgements

• Aces High team 176 Windsor Locks / Suffield HS
• Provided use of the mini-controller and
  electromechanical parts http//www.aceshigh176.com
  /
• Implementation of a virtual trackball
• Implemented by Gavin Bell, lots of ideas from
  Thant Tessman and the August '88 issue of
  Siggraph's "Computer Graphics," pp. 121-129.
• Open Source Asynchronous com port interface
• Thierry Schneider
• wxWindows Open Source GUI framework
• Julian Smart, Robert Roebling, Vadim Zeitlin,
  Robin Dunn, et al (http//www.wxwindows.org/)