System Implementation 5/9/2018

Overall System Status

 

The current system consists of rover hardware assembly, sensor suite, actuator suite, state estimation subsystem, entrapment detection subsystem, docking and towing subsystem, path planning and simulation subsystem, and motion control subsystem. In addition, rovers are also equipped with communication modules, power modules and necessary computing resources.

 

Sensors

The sensor suite includes wheel encoders, an IMU, the VIVE tracking system, and a force sensor on the claw and a camera. The wheel encoders, IMU and the VIVE tracking provide different aspects and different accuracy-level of pose information, which will go to state estimation and entrapment detection subsystems for further processing. The camera provides real-time first-person-view (FPV) live video stream, which fulfills requirement MN.0 and can also serve as an input to the visual odometry module (future development).

To autonomously dock this project requires relative pose estimation. To directly measure relative pose we used a new device called the Vive Tracker. The Vive Tracker requires least two components, a base station and the Tracker itself. The Base Station sweeps a planar laser horizontally across the scene, a planar laser vertically across the scene, and emits a syncing pulse of LEDs between laser sweeps. Multiple photo diodes embedded in the Vive Tracker detect the syncing pulses, and the time taken for the laser sweeps to reach them, and then solve for their horizontal and vertical angles. With the angles of each photo diode, and a known constellation of photo diodes the complete position and orientation of the Vive Tracker can be solved for relative to the Vive Base Station, within 2 millimeters of position accuracy and 2 degrees of orientation accuracy.

 

State Estimation Subsystem

 

The current state estimation subsystem uses an extended Kalman filter (EKF) to merge different sensor mea- surements from the wheel encoders (wheel odometry), the IMU and the VIVE tracking system. The output of the state estimation subsystem is a filtered odometry that provides optimal estimation of a rover’s current pose.

The IMU directly measures the rover’s acceleration, orientation and angular velocity in 3D, which are merged into the EKF loop in the prediction stage. The wheel odometry is derived from the raw measurement from the wheel encoders, where the current rover velocity, position and orientation are given in 2D. And the VIVE tracking system can give high-accuracy measure of the rover’s position, orientation, linear velocity and angular velocity with respect to the VIVE lighthouse (within certain range of operation). The wheel odometry and the VIVE odometry are merged in the update stage into the EKF loop.

An advantage of using the VIVE tracking system is its measurement accuracy, which can be within 1 mil- limeter in position and less than 1 degree in orientation. But the drawback is that it relies on the VIVE lighthouse, which means the VIVE tracker must be within a 5-meter envelope of the VIVE lighthouse to function. So the VIVE tracker will stop publishing measurement if the VIVE lighthouse is not reachable and the current EKF module will then rely only on the IMU and the wheel odometry. An improvement during the spring will be addition of GPS and/or visual odometry to the sensor suite so as to provide additional pose measurements (when operating beyond the VIVE lighthouse range) to the state estimation subsystem.

 

Entrapment Detection Subsystem

The entrapment detection subsystem takes in multiple sensor readings and provides real-time entrapment status estimation along with a likelihood indicating the confidence of the estimation. An entrapment of a rover is for- mally defined by the divergence (disagreement) of the assumed rover velocity derived from the wheel encoders, and the ground-truth rover velocity which can be approximated by the measured rover velocity given by sensor readings from other than wheel encoders. Intuitively, a rover is considered entrapped if its true velocity is nearly zero and the assumed velocity disagrees with its true velocity.

Practically, the rover velocity estimated from the wheel odometry is used as the assumed rover velocity, and that from the VIVE odometry, which will be later replaced with GPS or visual odometry, is used to approximate the ground-truth rover velocity. Prior knowledge of the variance of static rover velocity measurement and acceptable velocity divergence are assumed to conform to a Gaussian distribution and the parameters of the Gaussian models are derived by data collected from experiments. The rover statics probability and velocity agreement probability are then treated as inputs to a Bayesian process to give the likelihood of rover entrapment.

Please refer to this article for details: Naive Bayes Entrapment Detection for Planetary Rovers (https://arxiv.org/abs/1801.10571)

 

Estimating the Kinematic Constraints of the Rovers

The approach angle and the planned path for a mobile rover are reliant on the known motion capabilities of the rover. Henceforth, these motion capabilities would be referred to as primitives or specifically motion primitives. The motion primitives are determined based on the design and calibration of the fabricated and assembled rover.

Also, we developed the mathematical model for describing the kinematics of the rover. This would be necessary for the behavioral and motion planner included in the functional architecture.

 

 

In order to effectively execute the planed path, we would need a state space controller model of the robot. But prior to that, we could use the kinematic model determine the [x, y, θ] pose (motion along Z axis assumed to be zero, planar motion) of the robot in task space given its joint angles ( φ_i wheel encoders, θ steering angle). This is the forward kinematics of the model. Further, for the execution of the planned path – the actuators are receptive to updated joint angles only. This is accomplished using the inverse kinematics model. Along the lines of developing the kinematic model of the rover, we have completed the frame assignments and derived the homogeneous transformations that will now form the core for deriving the equations of motion.

The motor control board we are using (Ion Motion Control’s Roboclaw (20A) variant) has an automatically adjusting PID loop that operates on the task space velocity of the rover and position controls the rover’s steering angle – and the outputs necessary power to the actuators. We will include the kinematic model as part of the path-planning simulation and continue testing ongoing work on the docking and towing scenario using the existing controller model.

Although from a first glance it appears that the state [x, y, θ] of the rover is function of 4 joint angles (wheels) and 2 Ackermann steering units, the steering units mirror the position of the one another (one single variable controls both the steering units) and same is the case with the front and rear differential drive units. And because we have a differential drive, we only need to control the one motor per drive axle. Therefore, we have only 2 actively controlled joint spaces that control pose [x, y, θ] of the robot. Although the existing model is an under-representation of the physical capabilities of the rover, it was sufficient for scope of FVE i.e., move, dock and tow.

 

Path Planning Subsystem

 

The Path Planning sub-system provides the functionality of planning a path from the rovers current pose to the desired goal pose (including the desired orientation) while avoiding obstacles and respecting the kinematic constraints of the rover.

 

Power Distribution

 

To protect the rovers and batteries several components were added. First all batteries plug directly into a circuit breaker, limiting the current to the maximum rated by the batteries. Then the batteries connect to a parallel harness adapter which is only used for hot-swapping the batteries. This introduces some risk of batteries catching fire, but that risk is somewhat mitigated by a warning and explanation placed in the battery box. The current then flows through a fuse which limits the current to the minimum current specified by our electronics. The current flows through a Low Voltage Cutoff device which disconnects in the event that our voltage drops too low. In our case we cut off current if the cell voltage in our batteries reach 3.8 volts. This precludes damage to the batteries. Finally power is then distributed to all 12 volt components, and a UBEC converter provides 5 volts to our computer and powered USB hub.

 

Towing Mechanisms

Winch

The winch subsystem consists of a COTS servo and gearbox mounted into one of the rover’s top plates, with a 3D printed spool for holding the tow cable. The tow cable is currently 1/8 inch paracord rated to 160lbs. The gearbox has a 7:1 reduction, and the servo itself has a maximum torque rating of 12 kg/cm, giving an effective torque of 12kgf cm ∗ 7 = 96kgf cm. The rovers weigh 18kg. In the worst case scenario where the paracord is almost fully wound, the distance from the central axis of the drive shaft is approximately 2.5 cm, the pulling force on the motor is 18kgf ∗ 2.5cm = 45kgf cm. In theory, this servo and gearbox combination are sufficient to tow the rovers. In practice, the seven to one gear reduction on a servo operating at approximately 60 RPM makes for a very slow winch, and it is relatively easy to create scenarios where the stall torque of the winch is insufficient to pull a rover out of its entrapment. For the above reasons, we are also considering a COTS electric deep sea fishing reel or similar device to replace our current winch setup.

The tow cable runs through a simple eyebolt on the mount plate to act as a fairlead, and then through a 3D printed mount for the ring the claw grabs. The ring mount went through several iterations in its design as we realized that it would need to rotate the ring a quarter turn as it pulled it up flush with the front plate of the rover. We eventually settled on an asymmetric design that forces the ring to a slant and then spins it as more force is applied by the winch.

Claw

The claw assembly (Figure 19) is also mostly a COTS grappling hook with a small linear actuator attached to it. To determine when an object has entered the graspable region of the claw, a spring loaded length of string was run across the mouth of the claw. When an object depresses the string it pulls a potentiometer which is read by the Arduino to determine whether or not the claw should close.

This system proved to work extremely well; once it was complete and calibrated it was cycled over a hundred times during the course of our testing and almost never failed, and proved extremely easy to fix when it did so.

Our original plan was to use magnets to link the rovers, but in practice that idea has a much smaller successful linking envelope and would have made significantly less strong connections.