05 July 2020

SRC2 - Explicit Steering - Wheel Speed

SRC2 Rover
This fourth post about the qualifying round of the NASA Space Robotics Challenge - Phase 2 (SRC2) addresses the speed of the wheels of the rover, shown to the right, under the various possible motions. The rover uses Explicit Four Wheel Steering which allows the orientation of the wheels to be independently changed. The second and third posts explored the geometry to determine the position of the wheels for a turn, pivoting in place, and crab / straight movement. See the first post for the basics of the competition. 

Wheel Orientation

The orientation of the wheels on the rover determines the speed for the wheels. In straight or crab movement the speed is the same for all wheels. When turning, shown in the diagram below, the speeds are different for the inner and outer wheels. The requested overall speed of the rover, determined at the center of the rover, is used to calculate the inner and outer speeds. 



 Term        Description
 ICR Instantaneous Center of Rotation
 Rr Radius from ICR to center of rover
 RiRo Radius of  rover's inner (i) and outer (o) sides through ICR
 Wb, Wt Wheel base and wheel track of rover. Lengths are representative of actual size.
 WRi, WRo Radius of inner(i) and outer (o) wheels
  δiδo  Steering angle for inner (i) and outer (o) wheels

Visualize on the diagram three concentric circles drawn from the ICR. One circle passes through the center of the rover while the others pass through the inner and outer corners, or wheels, of the rover. The second post calculated the wheel's turning radius as:


The rover radius is Rr, the distance from the ICR to the center of the rover. 

The speed (Sr and turn radius of the rover determine the time (Tr) to complete a full circle, as shown in the first equation below. The next equation calculates the speed of either set of wheels (WR) using the circumference of the respective circles. Subsequently, that equation can be simplified as shown in the formulations that follow. 



Twist Calculation

The standard ROS movement command is the twist message. It contains two 3 dimensional vectors. One specifies the linear movement for the x, y, and z dimensions. The other specifies the orientation, also as x, y, and z, but meaning roll, pitch, and yaw respectively. 

The calculations for steering orientation and speed are all based on the radius of the turn. That turn radius needs to be calculated using the X velocity and the Yaw from the message. Recall from post three that turning during a crab movement is not under consideration so the linear Y value is ignored. 

Getting to how to do the calculation requires some interesting analysis but the final, actual calculation is extremely simple. The starting point is the Yaw in radians / second. The first equation determines the time it would take to turn a full 2𝜋 radians at the Yaw rate. Or, how long to traverse a full circle. 



Next, that time is used to determine the circumference of the circle using the X speed. Knowing the circumference the radius is determined. The equations show the individual steps but then combine them to reduce them to a simple calculation. Everything should reduce to such simplicity. Note that dimensional units are included to assure the final units are valid.

03 July 2020

SRC2 - Explicit Steering - Crab, Straight, and Pivot Movements


SRC2 Rover
This is the third in a series of post about my involvement with the qualifying round of the NASA Space Robotics Challenge - Phase 2 (SRC2). The first post introduced the basics of the competition. One aspect of the challenge is there is no controller for the rover depicted to the right. It uses Explicit Four Wheel Steering which allows the orientation of the wheels to be independently changed. This provides multiple ways for the rover to move, e.g. straight, crab, turn, pivot.

The second post explored the geometry on positioning the wheels for a turn. This post will address pivoting in place and crab movement, i.e. moving sideways. It also addresses the trivial crab case of moving straight forward or back. 

29 June 2020

SRC2 - Explicit Steering - Wheel Orientation for Turning

SRC2 Rover

The first post in this series explained I'm currently involved with the qualifying round of the NASA Space Robotics Challenge - Phase 2 (SRC2). The competition requires controlling the rover to the right. It uses Explicit Four Wheel Steering which allows the orientation of the wheels to be independently changed, This provides multiple ways for the rover to move, e.g. straight, crab, turn, pivot.

The challenge is there is no controller for the rover in the Robot Operating System (ROS) because the rover wheels are controlled by effort, not the typical speed control.
This article address the geometry of controlling the rover when it is turning. The diagram below illustrates the rover making a counter-clockwise turn around the Instantaneous Center of Rotation (ICR). The arrows represent the wheel orientation. The dotted box is drawn proportional to the wheel base and track of the rover. Note the orientation of the X/Y axis which is ROS standard for robots.
Explicit Steering - Rover Turning


 Term        Description
 ICR Instantaneous Center of Rotation
 Rr Radius from ICR to center of rover
 RiRo Radius of  rover's inner (i) and outer (o) sides through ICR
 Wb, Wt Wheel base and wheel track of rover. Lengths are representative of actual size.
 WRi, WRo Radius of inner(i) and outer (o) wheels
  δiδo  Steering angle for inner (i) and outer (o) wheels


NASA Space Robotics Challenge - Phase 2


Another NASA Centennial Challenge began earlier this year. It will be the 3rd I've entered. I also entered the 2019 ARIAC competition which makes 4 competitions. The current competition is the Space Robotics Challenge - Phase 2 (SRC2). In this competition robotic mining rovers explore the Moon to detect volatiles and collect them, detect a low orbiting cube sat, and position one rover aligned with a fiducial on a processing station.

Links to Follow-on Posts


In the following posts I'll explain what I can about this topic. There are a number of research papers available however my posts will provide a simplified explanation. 

Explicit Steering

The biggest challenge in this competition is controlling the rover. It is the size of a small SUV with Explicit Four Wheel Steering, i.e. each of the four wheels is steered separately. If you've seen the Mars rover it is a similar design. That's the base rover, above.

Explicit steering allows flexibility in movement of the rover. It can turn all four wheels to the same angle to move sideways in a crab movement. This also provides straight forward movement. By orienting the wheels at different angles the rover can turn. An extreme example of this is pivoting in place.

Robot Operating System

The base software for the competition is the Robot Operating System (ROS) which consists of the fundamentals for communicating amongst software nodes and a large number of packages that provide useful capabilities. Unfortunately there isn't one for controlling the SRC2 rover.

There are two ways of controlling the wheels for locomotion. The predominant one is issuing a speed command. A number of ROS controller packages provide this capability. Another specified the effort or torque. There are effort controllers but none directly apply to the SRC2 rover.

The location of the rover on the surface is required for reporting the position of volatiles, moving to them, and generally controlling the rover's movement. This requires deriving odometry from wheel movement, vision processing via stereo cameras and an inertial measurement unit (IMU). Again, this is not provided. It is especially challenging due to the low friction between the wheels and simulated Moon surface which allows slippage of the wheels.

28 January 2010

Thinking Aloud - Long Ago Neural AI

I got thinking about way back when in 1972-74 in undergrad school. I was doing some work in AI, albeit within the psych department. This was before the heyday of neural network although there was some activity in the area. I ran across the book, Intelligence: Its Organization and Development by Michael Cunningham. He proposed a rigorous, testable way in which intelligence organizes in the infant. I guess it didn't work out since it didn't make the front page of the New York Times as a major breakthrough sometime in the intervening decades.

Interestingly, a web search turns up little information beyond citations. None of the titles in the citations indicate a successful implementation or breakthrough based on the work.

I still have a paper I wrote about the book and a description of a FORTRAN implementation that never got finished.

One of the challenges back then, and remains so somewhat today, is that testing ideas like this requires a simulation environment that can be as complex to produce as the actual ideas you want to test. But I realized that today I do have a physical device, my Create robot, that could be used for testing.

I'm not going to layout all the details of Cunningham's proposal since he took a book to develop and describe the idea. I won't even list the roughly 2 dozen specific assumptions in the model. What I am going to do is walk through some thoughts on how a project might proceed to see if it is worth pursuing.

You start with input and output elements - sensors and actuators in today's robot parlance. There are some reflex connections between these elements. For example, a pain reaction reflex so if an infant's hand touches something hot it jerks away. Or if the side of the mouth touches something the head turns in that direction in an attempt to suckle.

Jumping over the start up process (which is always a pain), lets assume the robot is moving forward and hits a wall. The bumper switch closes but there is no reflex to shut down the motors. The motors keeps turning and you get an overload reading. There is a reflex for this and it stops the motors. Now the motors are stopped and the bump switch is still triggered.

There would be a number of elements. Each sensor input on the Create could have an input element. Each actuator would have an output element. As indicated, the over current input element could be connected to an output element that stops the motors. Note - A point to consider that there might be output elements that don't directly connect to actuators but instead inhibit actuators. Continuing the thought, there might need to be backup, stop, and forward elements for the motors. In the situation described, these elements would have high levels of activity. Other elements, like a push button, would have no activity. The Cunningham model proposes that those elements with high activity are connected through a new memory element. The inputs to the input side of the memory and the outputs to the output side. What might happen is a connection is created between the bump switch, the over current and the motor stop elements through the new memory element. In the future, a bump switch closure would stop the motor.

I now recall one result from my work with the FORTRAN implementation. This is the need to have multiple elements to represent the state of input and output elements. My note above reflects this. For example, the bump switch needs two elements - open and closed. The motor needs forward, reverse and stopped. It may need even more indicating speed, although I would first try relating the element activity level with the speed.

The activity level of an element decays if it is not triggered. So the bump switch closing triggers activity that decays over time. The motor activity decreases until the motor stops. An issue would be to keep the bump switch closed activity going long enough for the over current activity to shutdown the motor and get the new memory element built. Note: maybe an input triggers again after a period of time?

How do we get the bump switch open? The only way is by getting the motor to reverse. Infants in a situation like this flail. They randomly move. Sometimes they do this happily while cooing and sometimes angrily while crying. It appears to be a natural reaction to try something, anything to make things different. (A really ugl phenomena in an adult but you still see it. If not physically at least mentally. Ever had a boss whose reaction was, "Don't just stand there! Do SOMETHING.") I don't recall the model addressing this situation. (I did find used copies of the book and have one ordered so I can refresh my thinking.)

Somehow some general level of activity has to increase which can generate activity at outputs. Sometimes this would be through inputs. For an infant this could be sound, pressure on skin, internal senses, and vision. I dislike simply generating random activity levels to cause something to happen. Maybe the general inputs of the Create - power levels, current readings, etc are sufficient to generate activity.

Clearly, a dropping charge level in the battery could be tied to a "hunger" reaction which sends the robot searching for its charger. That brings in using the IR sensor to control the drive for the docking station. That probably requires external guidance to train the IR / motor control coordination to execute the docking maneuver. That opens up an entirely different set of thoughts.

Which is enough for today... No conclusion on trying to implement this. But no conclusion not to do so, either.

Exploring AGI Using AI

I have long been interested in Artificial Intelligence (AI) and what is now called Artificial General Intelligence (AGI). How long? Check ou...