So., I am currently trying to program a Hytechnic Gyro on an NXT kit; I have a program that I have programmed myself with help from the web and it.

Introducing the HTWay, a Segway type self-balancing robot. This robot uses the as well as the. The Gyro sensor is used to maintain balance while the IR Receiver allows it to be controlled with a LEGO Power Functions remote. Essentials: Update(Nov 8, 2010):The NXC version was updated to fix a bug that caused the program to crash when the optimization level was set beyond 1. Update(July 28, 2010):The NXT-G Program in the download above has been updated to use the new 2.0 Gyro sensor block available for download from the Downloads page. If you are using the original 1.0 Gyro sensor block, you must update it to the new 2.0 block for use with this program.

Both the NXC and NXT-G programs work essentially the same way. The programs take advantage of floating point math that is new with LEGO Mindstorms NXT 2.0. The original 1.0 NXT only supported integer math. While using floating point math is not essential when programming a Segway type robot, it makes the program much easier to understand and to work with. Update for NXT-G: For the NXT-G program, make sure you also download and install the Gyro and IR Receiver blocks from the LEGO Mindstorms software.

You can find the them on the page. If you usually program in NXT-G with LEGO Mindstorms 1.0 or 1.1, then this is a great opportunity to give NXC a try. If you install the development environment, you will get NXC as part of the package. For the HTWay you will also need LEGO firmware 1.26 or higher. This firmware is fully compatible with the earlier version and will still work with your LEGO Mindstorms 1.0 and 1.1 software. You can even use BricxCC to download the firmware to the NXT; from the Tools menu, select Download Firmware. You will also need to make the NXC compiler target the 2.0 firmware to take advantage of the floating point math.

You can do that by going to Edit->Preferences, then click on the Compiler tab and then the NBC/NXC sub-tab. Now check the option for “NXT 2.0 compatible firmware”. Update for NXC: In order to take advantage of the floating point math support you will also need to download and install the latest of BricxCC. After you download the zip file of the test release, copy the contents over your existing BricxCC installation.

This will most likely be c: Program Files BricxCC. When you run the program, the first thing it will do is let you select the wheel size that you are using. There are three options: Small (NXT 2.0), Medium (NXT 1.0), and Large (RCX). Use the arrow keys to choose and the Orange Enter button to select. The robot will now need to get an initial gyro offset. You can think of this as a Gyro Sensor calibration.

In order to get a good gyro offset, the robot will need to be copletely still. If you hold the robot in your hand it will wait until you you put the robot down, and it is not moving, before it will get the gyro offset and go on. HTWay will now start beeping indicating that you have five seconds to get the robot vertical and as balanced as possible. At the end of the long beep, let go. The robot should now be balancing and is ready to be driven with the LEGO PF remote.

You can control it like you would a tank. Both levers forward and the robot drives forward. Both lever back and it reverses. One lever only and it will turn around one stopped wheel and both levers in opposite directions and it will turn in place. Background This is a classic problem in control theory. Prior to the, it was more commonly known as the problem.

Normally when you think of a pendulum, like on a clock, it hangs down below the pivot point where it is stable; the inverted pendulum is one where the center of gravity is above the pivot point in a position that is inherently unstable. To keep it up, the pivot point has to move to catch it when it begins to fall. That is in essence the same problem as making a segway robot balance.

With LEGO robotics, this challenge has been taken up many times. First came Steve Hassenplug’s using the RCX and two EOPD sensors. These RCX EOPD sensor were early HiTechnic products that functioned essentially the same as the current NXT EOPD sensors. These sensor were used to tell the distance to the floor. If the robot was leaning forward, then the sensors would be closer to the floor so the RCX could tell that it was leaning forward. If it leaned back, then the sensors would be further away from the surface.

This was a fantastic creation and Steve even got a place on cable TV fame with this amazing robot. Not only could it balance exceptionally well, it could line track and even spin in circles to impress the crowds. With the NXT, Philippe E. Hurbain built the using the NXT Light Sensor in a way similar to Steve Hassenplug’s LegWay. Under controlled conditions, the LEGO Light sensor can also be used to tell distance. As long as lighting and surface are consistent, the robot can tell if it is leaning forwards or backwards based on the light sensor value.

Given the poor resolution of the light sensor, this was an impressive accomplishment. The first gyro sensor based NXT Segway robot came from Ryo Watanabe at Waseda University in Japan. The original HiTechnic of a balancing robot was in fact Ryo Watanabe’s very impressive robot that was using, at the time, a prototype HiTechnic Gyro Sensor. Ryo did an amazing job of describing the physics and his solution that were very valuable in the creation of the current HTWay model.

More recently Dave Parker at created an amazing NXT 2.0 one kit robot using the LEGO Color sensor in a similar way to Philo’s NXTWay. Dave Parker came up with the original idea of using the third motor to offset the balance and to it use to make the robot go forwards or backwards, in a way similar to the real Segway PT which is also controlled by the human rider leaning forwards or backwards.

Laurens Valk has also recently published a Segway type robot that uses the HiTechnic Gyro Sensor. He calls his creation the.

Like the HTWay, his program is also written in NXT-G. Laurens’s project inspired some ideas that were used in the creation of the HTWay including the idea of letting the user choose wheel size with the button interface in the beginning of the program.

How it works First of all, you don’t have to understand exactly how it works to make this robot. You can build it and put the NXC or NXT-G program on it and have fun with it even if you don’t fully get the math that makes it balance. Both the NXC and NXT-G programs are written such that the control code is separate from the balance code. If you want to use other sensors, such as the Ultrasonic or Light sensor, in addition to the Gyro sensor that is essential for balancing, you can do that. All you need to do is have your own control code which can in turn drive the robot by changing two global variables, motorControlDrive and motorControlSteer in NXC and controlDrive and controlSteer in NXT-G. Both of these variables are in degrees per second.

The steering control is based on the desired difference in the motor encoders. Above you will find the download links for both NXC and NXT-G programs. These programs have been written so that they work as much as possible the same way. Below I give some code snippets from the NXC program. If you are a NXT-G programmer, try to follow along. You can also look at the actual NXT-G code in the LEGO Mindstorms software and follow along there.

Since some of the math equations get quite big in NXT-G, it may be easier to understand the NXC program. In order to balance, the robot has a control loop which takes four pieces of information into account and then decides how much motor power is needed to stay upright.

In a simplified form, the NXC code for the main balance loop looks like this. #define KGYROANGLE 7.5 #define KGYROSPEED 1.15 #define KPOS 0.07 #define KSPEED 0.1 A note about wheel size making it go In the HTWay program you can select the wheel size you are using with a three button interface. What this does is it sets a global variable called ratioWheel to either 0.8, 1.0, or 1.4 for respectively the small NXT 2.0 wheels, the medium sized NXT 1.0 wheels and or the large RCX wheels. So what does this actually do?

Well the actual balance equation is a little different then what was shown above, here is the full expression used in the program. Carmor Wood Stove Manual. Power = (KGYROSPEED * gyroSpeed + KGYROANGLE * gyroAngle) / ratioWheel + KPOS * motorPos + KDRIVE * motorControlDrive + KSPEED * motorSpeed; It turns out that the wheel size only needs to play a role with the two gyro sensor terms and not the motor terms. The reason that wheel size is important is because bigger wheels need less power to compensate for being out of balance. Since bigger wheels move further, given a certain amount of input, you need less of it to achieve the same amount of movement. So why not take the wheel size into account on the motor terms? The reason is that these terms are effectively self-relative.

If the robot is, for example, one inch too far forwards, then this will be represented by a higher motorPos value for small wheels than for big wheels. Effectively, for the small wheeled robot this will result in a higher influence on the motor power than what will happen for the same distance using the bigger wheels.

In the code above you will also see that the motorControlDrive also plays a role in the balance equation, this is not actually what drives the robot. This term is used to help get the robot going as well as to slow it down whenever the motorControlDrive term changes. When you start driving the robot, this term will cause the robot to first drive backwards a little to quickly get going, then when you stop it will give the robot a little extra boost to help it lean back to slow down. The actual driving comes from this line right above the power balance equation.

MotorPos -= motorControlDrive * tInterval; Every time through the loop, the motorPos variable is adjusted proportionally to the global variable motorControlDrive. MotorControlDrive is in degrees/second so by multiplying it by the interval time, we are adjusting the motorPos by the amount that the robot should move each time through the control loop. This moves the target position along which is what makes the robot drive. Integration If you are a young robot builder, you have probably never heard of integration. If you are older, you probably wish you never had.

It turns out that integration is really useful and essential for this project. And actually not that hard to understand. The problem is that the Gyro Sensor does not give you an actual angle. You can’t just read the Gyro Sensor and tell if the robot is leaning forwards or backwards. All you can tell is the angular velocity, in other words, how fast it is falling. So if you know the angular velocity, how can you get an angle?

Well that’s what integration does. Integration is simply the act of adding an infinite series of values over time. Let’s say that at a given time you know the robot angle, we keep that in a variable called gyroAngle.

Each time through the loop we get from the Gyro Sensor the angular velocity in degrees/second. So if we know the interval of the loop, then we can update our gyroAngle by the amount that we know the angle has changed. Since our loop is running at about 100 times per second, the interval time is 0.01 seconds. To update the gyroAngle, we simply add the gyroSpeed times the interval time (0.01 seconds) into the gyroAngle to get a new value. Here is the NXC function for getting the gyro data that does this. Hi sorry, for the slow response. Things have been pretty busy lately.

Dark Angel Season 2 Episode 1 Download. You can use the acceleration sensor along with trig functions to get a tilt angle. The problem with that is that it only works when the sensor is stationary. If you move the sensor around then you also get acceleration due to movement and then you can’t reliably get an angle. In the worst case, a sensor mounted on a falling robot will essentially be falling due to gravity. In this case it will not detect anything is wrong until it hits the ground. You need a gyro sensor to make a balancing robot.

I have never seen it done with an acceleration sensor. Verdonko, first of all, the NXT EOPD and Gyro sensors will not work with the older LEGO RCX, even with a conversion cable.

The cable allows the RCX sensors and motors to be used with the NXT but not the other way around. (Actually the NXT motors will work). An NXT LegWay type robot that uses the EOPD sensors could be build similar to what Hassenplug did with the RCX. The problem with the EOPD sensor is that it will be sensitive to the nature of the surface that it is running on. If you try to drive the robot on different color surfaces or something like carpet then it will either not work or require re-calibration to that surface. Some surfaces will not work at all such as a dark mat which absorbs almost all the light.

It will also not handle slopes since being balanced requires a different angle to the surface when you are on a slope. Hi, I’ve built your HTWay carefully and it seems to work, up to some extent. It balances, it turns, but as long as I push both PF remote levers in the same direction (forward or backwards), the robot starts moving forward or backwards but almost immediately it looses the balance and falls to the front or to the back respectively. Nothing like you demonstrate on your video. I’m using NXT firmware 1.31, the correct wheel sizes, etc.

I experience the same problem, both with NXT-G and NXC. My NXC Compiler is targeting 2.0 firmware and optimizations levels is 2. Do you have any idea, about what might be going wrong with my robot? Many thanks, in advance. Controldrive is the speed setting for the robot is degrees/second (measured by the sum of the two motors.) controlsteer is the rate of turning of the robot (the difference of the motors), also in degrees per second.

To line track you want to set the controldrive to a fixed amount (I would suggest starting slow, like 100 or 200 deg/second. Then in the control loop you want to look at the light sensor value, subtract a mid point constant (the value half way between white and black) and then multiply that by a constant to scale it up to something that will get it in the range of about +- 200, then set that to the controlsteer. The robot should now steer toward the edge of the line. Actually, you should start with a controldrive speed of 0 and just get the robot to steer toward the line in place first. Once that works, make the robot move along the edge of the line. The sensor should be slightly in front of the robot. You will need to experiment on the best placement.

If too far forward then the forward/backward movement of the robot will results in a lot of value variation. If too close to the center line of the robot then not enough look ahead to track the line. If you have purchase the IRReceiver sensor, as well as the Gyro sensor, then the 8879 remote should work. This remote gives variable power to the left and right more so may be a little more difficult to operate the robot than the simpler 8885 remote which simple has two levers (my personal favorite).

Have you built the HTWay with both the IR Receiver and the Gyro sensors and not able to make it work? Are you getting an error? Have you downloaded and installed the IRReceiver and Gyro Sensor blocks? If you can’t get this to work I suggest you contact me using the support form on the HiTechnic website.

So., I am currently trying to program a Hytechnic Gyro on an NXT kit; I have a program that I have programmed myself with help from the web and it for the most part works. I have attached a picture of it to this query.

How do I go about adjusting the wheels to turn to auto correct the pitch of the robot? And how do you record on the Front Panel what is happening? I know this doesnt sound very clear, but I want to have an example to look.

I have near no labview experience and so it would help if anyone could explain in depth. Also, can I turn this Gyro Calculating program into a subVI? Also i have attched a picture of the prototype so that you can know what I am working with.