Sunday, March 18, 2012

BricxCC and HTWay Analysis

Now that I've identified BricxCC is a workable environment, it's worth looking into a bit deeper. Bricx Command Center, or BricxCC for short, is an integrated development environment for programming LEGO microcontrollers, such as the NXT. It provides a lot of great tools for operating the NXT. I've found a lot of utility with the direct control tool, the file explorer, and the register watcher while experimenting deploying code to the NXT. I also came across a very interesting similar project online that's worth comparing parallels with.

HiTechnic's "HTWay"


HiTechnic, a 3rd party sensor manufacturer for the Mindstorms platform, has also created a self balancing robot. Here's a video overview of their design in action.



Their robot is similar in design to what I'm working with. At it's heart, it build from LEGO Mindstorms components including the NXT. Their version is more complex including remote control via a infrared remote, and they have added considerations for when the robot has fallen over, and allows you to adjust the wheel sizes when starting the program for the first time. They are also using a gyroscope to detect their robot's tilt angle and velocity. For more information on the HTWay, take a look at their blog page, which also has links to build instructions and code in different languages.

HTWay Control Law


From the NXC code, here is the control law that keeps this balanced.

power = (KGYROSPEED * gyroSpeed + // Deg/Sec from Gyro sensor
    KGYROANGLE * gyroAngle) / ratioWheel + // Deg from integral of gyro
    KPOS * motorPos + // From MotorRotaionCount of both motors
    KDRIVE * motorControlDrive + // To improve start/stop performance
    KSPEED * motorSpeed; // Motor speed in Deg/Sec

The control law takes the gyro's velocity and angle as well as the motor rotation and velocity. The variable motorControlDrive is used as part of the remote control system of the robot. For this analysis it can be considered equal to zero since my project doesn't include any remote control. The gains, set as macros, are given and not calculated. There's no background information as to how those were chosen that I came across.

The state space model that my hardware is based off of, originally discussed in 2009, is very similar to this. My state is defined as the derivative to angle and the angle itself, as they have in their control respectively. This is promising that this is a sound state to be using. And in fact, if I were concerned with where the robot was, or how fast it was traveling, I could also add the position and velocity of the base. Since I'm not doing any remote control, this can be neglected, and left perhaps as an opportunity for expansion later on.

Sensor Considerations


Another interesting piece of information that has come out of this evaluation has to do with the gyroscope. When the gyroscope is run over time, it tends to drift. One way of combating this is using a filter before determining the angle. The NXC code for this on the HTWay is this.

gyroRaw = SensorHTGyro(GYRO);
gOffset = EMAOFFSET * gyroRaw + (1-EMAOFFSET) * gOffset;
gyroSpeed = gyroRaw - gOffset;

gAngleGlobal += gyroSpeed*tInterval;
gyroAngle = gAngleGlobal;

In this code, the raw value from the gyroscope is read, then passed through a filter in the form of a weighted sum to determine the "true" offset. The offset is used in calculating the speed of rotation. The macro EMAOFFSET is given as 0.0005 and not calculated. Conceptually, the majority of the "influence" over the "true" offset value is driven by the previous value of the offset. This further enlightened me to the fact that sensors are faulty and need to be accommodated.

Unfortunately, I only have an accelerometer on hand. I will attempt to work with it before ordering a gyroscope. If it comes to using a gyroscope for tilt angle calculations, I will attempt to leverage the accelerometer I have to aid in the gyro's drift accommodations.

No comments: