May 11, 2014 - The aim of our project is to design a Segway-like, self-balancing robot, using Lego. Meanwhile, the main thread waits for a keypress, after which the program. NXT SEGWAY with Hitechnic Gyro Sensor, online at.
Hello everbody. Im a student from germany. Im a member of a project group (3 students). Our project topic is to build a NXT Segway (with the HiTechnic Gyro Sensor) and to implement a program to balance it with NXC.
We have used the building instructions from to build our segway. Now we implemented a code in NXC to compute the P,I and D-Part. We experimented with the scaling factors but it doesn't work properly. It would be very nice if someone of you could give us a hint or something to solve this problem?? Hello JeyTe, NXT segway is quite complicated problem. In my interpretation balancing is quite far from a linear system (PID works fine with linear systems).
Until the tilt angle does not exceed a little value, PID might work fine - however, setting the PID parameters by 'try-fall-repeat' will be a tremendeous work. You might want to do some maths to achieve a quite good model of your robot.
Solid state gyro sensors produces a very low quality signal, in terms of the output has a large drift, short term and long term bias, sensitivity to temperature, and also dynamic noise, generated by the NXT motors themselves and the uneven surface of rubber wheels on a possibly uneven surface - you will have to compensate drift by introducing the motor output variables within your model and introduce a filter that passes only 'credible' values of the gyro sensor. Credible the change betwee 'new' value and 'previous' value shall be in line with the physical state of the model (i.e. Tilt angle and angular velocity). NXT motors have quite bad hysteresis i.e. When changing the direction the motor encoder will have to turn approx 5 degs before the output axle starts turning the opposite direction - a robot might balance without compensating the hysteresis, but it will oscillate to some extent.
I make experiments with an 'older' Lego motor (the 9V 'cube' form robot with an internal gearing). That motor has much less power and no angle transmitter, but also much lower hysteresis. Fri Apr 24, 2009 5:03 pm.
![Nxt Nxt](/uploads/1/2/5/5/125528643/919979197.jpg)
The state you can use: 1x Gyroscopic Sensor. Sensor config You can leave the HT Sensor in nxt-analog mode. That will give you the full resolution. The code is already set up to do the appropriate conversions. We just need to change a scaling constant, as explained below.
Here is the part you'll want to change. Keep in mind that the sensor is automatically correctly set up, but the ev3dev Python library is used to easily find the location of the 'value0' file that contains the sensor value. # Gyro Sensor setup gyroSensor = ev3.GyroSensor # Replace by something like nxt-analog (not sure about its name) gyroSensor.mode = gyroSensor.MODEGYRORATE # Remove this. The HT Gyro can only provide the rate anyway gyroSensorValueRaw = open(gyroSensor.path + '/value0', 'rb') # This opens the value0 file containing the sensor value we want. If there is nothing like 'analog' in the Python library, keep only the last line, and provide the path yourself (/sys/class/lego-sensor/path/to/value/0/file) Converting the units The code was designed with support for other sensors in mind.
The angular rate is calculated like this: gyroRate = (gyroRateRaw - gyroOffset).radiansPerSecondPerRawGyroUnit # Don't change this formula, it's just here to explain it The offset and the scaling vary between the sensors. The offset is automatically calculated by the program in the calibration step, so you won't have to change that. The scaling is configured by this constant: degPerSecondPerRawGyroUnit = 1 # For the LEGO EV3 Gyro in Rate mode, 1 unit = 1 deg/s For the HiTechnic sensor, use 0.2084 for this constant.
I think the positive rotation rate was the same for the HT Sensor as for the LEGO Gyro. But if it isn't, you can mount the sensor on the other side of the Brick (swap it with the Touch Sensor.). Status Running EV3-brick on Image: ev3dev-stretch-ev3-generic-2017-10-24 Updated and added several packages I like; e.g. Figlet bc joe bash-completion logwatch and more So it's NOT a clean image anymore.
Connect via ssh over wifi as user robot cd mkdir testsegway cd testsegway/ wget wget chmod +x segway.py. Status of segway.py and parameter.py according to github: Latest commit 20 days ago laurensvalk Tuning. HiTechnic Gyro sensor at default ANALOG-0 mode.
To be sure: Test unadapted segway.py - fails as expected; Oke. Modifications Software change: Adapt segway.py: Changed this: # Gyro Sensor setup /BL 20171030 # gyroSensor = ev3.GyroSensor # gyroSensor.mode = gyroSensor.MODEGYRORATE # gyroSensorValueRaw = open(gyroSensor.path + '/value0', 'rb') Into this: gyroSensor = ev3.Sensor(address='ev3-ports:in2') gyroSensorValueRaw = open(gyroSensor.path + '/value0', 'rb') Hardware change: Added touch sensor as building instructions I used did not yet have it:-). Swap the touch sensor and the gyro sensor as the wheels turn 'the wrong way': Touch sensor on the 'speaker-side' Gyro sensor on the 'sd and USB' side Seen results:. FUN.
Still all debian services active and using wifi: A bit jerky but stable. Stays up for a minute or a bit less sometimes and then oscillates out of control and drops. A very slight turn to the left while balancing. Sometimes a rush forward or backward occurs 2040cm and is recovered. start balancing is a bit picky with how correct I keep the robot up-right, sometimes almost direct dropdown Question (I am not a python expert - far off even ) The 'Platform specific constants and conversions' are within the main loop.
Assume they do not change while running. Might it help a tiny bit for speed to move them to the part where the sensors/motors are setup? I ask because this may improve simple usability: The type of giro could be determined in the program without modification and at the same location set the constatns accordingly.
Thanks for the detailed response! GyroSensor = ev3.Sensor(address='ev3-ports:in2') Thanks for working this out, that is useful to know. I'll look at adding something like this to the code. FUN ? A very slight turn to the left while balancing Since you've tried the EV3-G version you probably noticed that it compensates for this. Maybe I should add this feature here too. The steering is caused by a slight difference in friction of the motors, which is especially apparent at low speeds. Swap the touch sensor and the gyro sensor as the wheels turn 'the wrong way' I'll look at implementing the orientation in software.
Changing minus signs quickly gets very confusing, so I am not going to suggest you try that. The 'Platform specific constants and conversions' are within the main loop. I don't think that's currently the case. Note that there are two loops. The outermost loop defines the constants and resets sensors, prior to starting the balancing loop with the Touch Sensor. Just too tempting. Try changing 0.2084 to -0.2084 instead of mounting the sensor on the other side.
Thanks Laurens. Just too tempting.
Try changing 0.2084 to -0.2084 instead of mounting the sensor on the other side. Maybe just to make it a bit clearer to the reader: set it as # Negative value for the HiTechnic sensor to prevent turning the wrong way: degPerSecondPerRawGyroUnit = 0 - 0.2084 # Tried this and that works, so there is no hardware mod needed.
I don't think that's currently the case. Note that there are two loops. The outermost loop defines the constants and resets sensors, prior to starting the balancing loop with the Touch Sensor. Correct of course. I just want to keep the setting of the constants together as best as possible. And the degPerSecondPerRawGyroUnit needs to be set near the gyro setup.
There is not much spare time for me the next days, but if I can test, just ping me.