search

laurensvalk / segway

Code for robots balancing on two wheels, made with various robotics platforms.
MIT License
42 stars 22 forks source link

Doesn't balance well... What's the wheel size? #8

Open pipothy opened 7 years ago

pipothy commented 7 years ago

Just ran it on my EV3 and unfortunately it doesn't seem to balance well.

Trying to find out why, I think the wheel sizes may be different? Are you aware of what size wheels are needed for this program to work? I am using the ones that came with my EV3 Education kit, but they look different to those pictured in the link given. If the wheels are different sizes, that's probably the issue!

laurensvalk commented 7 years ago

I'm using the wheels that come with the EV3 31313 kit. They're 43 mm in diameter.

You could also retune the feedback gains to make it work with your wheels.

But perhaps a first attempt --- which amount to changing the gains all at once rather than individually:

Just before applying it to the motors, try scaling the duty cycle like this:

motorDutyCycle * 43 / D

D is your diameter, in milimeters.

laurensvalk commented 7 years ago

Those wheels are in the Education Expansion kit too, in case you have it.

pipothy commented 7 years ago

Hi,

Thanks a lot. I don't have the education expansion kit. I tried retuning them myself but it rarely lasts longer than 30 seconds. Is that expected?

I'll try scaling the duty cycle and let you know!

laurensvalk commented 7 years ago

You mean it falls down within 30 seconds? Once tuned well, it should balance until the batteries run out.

Given that yours already "almost balances", you have a nice starting point for tuning. It's harder if it doesn't balance at all to begin with.

pipothy commented 7 years ago

Hi,

Unfortunately, scaling it didn't seem to do the trick, still falls over within 30 seconds.

I've ordered some new wheels, I'll see if before then I can find some good changes to the values that allow it to balance with the 56 wheels, and can post them here for other people.

laurensvalk commented 7 years ago

It certainly can be done with the bigger wheels as well, [see, for example, the old version of this code for GyroBoy] but tuning can take a while.

I've also found that the EV3-G code gives very reproducible results, allowing many people to get it to work without tuning at all. The Python version isn't as robust somehow, which seems largely related to the variability of the loop time, which varies greatly especially when the kernel decides to do something important.

pipothy commented 7 years ago

Hi, sorry for the long delay.

No luck it seems. I've got the wheels that are included in the normal kit and they don't work. Can you just confirm that you did this using the 30.4mm diameter wheel with 43.2mm diameter tyre? EDIT: (Scratch that, you've already confirmed that above). I've tried lots of tricks with nothing getting better results, only worse. I played with the accumulated motor error gain and that improved things marginally but nowhere near the results one would expect.

Are you supposed to initialise the robot with the angular sensor pointing straight up (i.e. the robot at a completely straight position) or at the robot's balance point? I've tried both, but it could perhaps be that the robot is built slightly differently to the one in the tutorial? Even then, I can't see why small changes to the body would make a noticeable difference.

Beyond the wheel size being wrong, I can only think some of the parts are faulty? I can test for that but I'd be surprised if the motors are below functional. The battery is fully charged so it's not lacking in power.

Exactly how do you instantiate the robot? Perhaps I am doing something wrong there.

laurensvalk commented 7 years ago

Are you supposed to initialise the robot with the angular sensor pointing straight up (i.e. the robot at a completely straight position) or at the robot's balance point?

The robot's balance point is preferred. (A slight deviation shouldn't matter, but that's your best bet.)

could perhaps be that the robot is built slightly differently to the one in the tutorial?

Could you share a picture of your design? You can just drag/drop it into one of these comments.

Are you using 6xAA batteries or are you using the rechargeable battery? Either should be fine, but maybe my Python code isn't as robust as my EV3-G code. Could you perhaps try that code?

You'll also find some instructions how to start the robot there.

pipothy commented 7 years ago

Hi, just ran the EV3-G code (Balancer basic) and it was fine. Hard to instantiate and quite fragile to if it was started even a bit off the balance point, but when it was, it worked very well. No random jerking or falling over.

As such, it's unlikely to be any of the parts being broken (motor/sensors) or the build being substantially different.

Any idea why Python might be playing up like that? All I did was download segway.py, change the input ports to the ones I am using and then ran it. Could it be that? I'll give it a shot changing Gyro back to 2. It could be that something doesn't like the gyro sensor being in another port, possibly...

Any other suggestions?

pipothy commented 7 years ago

Just tried changing it back to port 2 and it helped, but it still doesn't last long.

It's fine at the start, but starts oscillating quite quickly, and eventually this topples it over... implying maybe some kind of integral or predictive term is building up in the code?

Want me to send you a video of it so you can see what I am on about? Any ideas what might be causing this?

laurensvalk commented 7 years ago

Hi, just ran the EV3-G code (Balancer basic) and it was fine. (...) As such, it's unlikely to be any of the parts being broken (motor/sensors) or the build being substantially different.

Good to know!

Any idea why Python might be playing up like that?

I haven't tried my code on the latest ev3dev build. I do know that the run speed of a Python program can change performance drastically. I'm wondering if any recent kernel changes are making any significant differences here. I'd have to retry with the latest version, but I'm not sure when I'll be able to do this.

All I did was download segway.py, change the input ports to the ones I am using and then ran it. Could it be that?

The ports shouldn't matter. However, when you unplug and plug the sensor back in, even in the same port, it resets itself, so that might explain why the response looked a little different.

It also helps to keep the sensor still when you plug the sensor (or when you boot the EV3). It doesn't have to be vertical, just stationary. But since you've had it working with the other code, this shouldn't be the cause.

pipothy commented 7 years ago

I'll try play around. Unsure if I can jump back to an earlier EV3Dev build, but would be keen to know if the current one messes it up. When you eventually get time to try it, let me know. I'd be grateful!

laurensvalk commented 7 years ago

Some findings with regards to ev3dev loop times are here.

That was C++ rather than Python, but I can imagine similar things happening (Likely worse).

On the other hand, the LEGO byte code interpreter also runs on Linux, so absolute speed should not be the issue.

The main developer of ev3dev is also working on a version of the LEGO interpreter. In essence, it lets you run EV3-G code on top of ev3dev. It would be interesting to run the EV3-G segway code with that.

pipothy commented 7 years ago

Hi,

Interesting read! Any idea where I can find a date estimate on the LEGO interpreter being released?

I'm unsure if it is the loop time, the oscillations seem quite consistent. I'll give it some more runs and get back to you, I'll try dig to find out what it is.

laurensvalk commented 7 years ago

It's already available for testing.

If you install the latest ev3dev-stretch image from here using the normal procedure, you can try out the interpreter by following the steps in the readme of this repository to activate it.

pipothy commented 7 years ago

It was incredibly slow... Not sure if this was just the specific environment with the lms2012 addition, or it is indeed indicative of Python being much slower as a result of something they've recently added to EV3Dev. I assume you've found it to be slower on their lego interpreter version too?

As such, I'm unsure where to go from here and how to fix the code to be more responsive.

laurensvalk commented 7 years ago

I hadn't tried the segway code on the lms2012 addition myself yet. It looks like you've found that that's too slow. Sorry about that.

I will let you know in this thread when I've tried the Segway again with the most recent version of the Python code and the most recent ev3dev build.

pipothy commented 7 years ago

Great, thanks :) Do you have any idea how long in the future that might be? Doing some work with the robot so could do with planning other projects to fit in in the mean time!

laurensvalk commented 7 years ago

Practically speaking, due to current deadlines and upcoming holidays, hopefully the end of september.

By all means, go ahead and build some other robots in the mean time :)

pipothy commented 7 years ago

Hi there! Just a bump to remind about looking into this!

laurensvalk commented 7 years ago

Thanks for the reminder :)

Not sure it should make any difference, but would you mind checking which sensor hardware revision you have? See slides 6, 7, 8 of this document.

laurensvalk commented 7 years ago

I've been updating the code. Looks a bit different now, but the controller is still the same.

Running the program and tuning should be much easier now.

I've done some preliminary tuning, but it isn't quite there yet.

laurensvalk commented 7 years ago

I've tuned it for a robot that's pretty close to BALANC3R's design. There is now also some scaling for battery level, which might help.

Curious to hear how this works for you.

pipothy commented 7 years ago

Hi,

I own 38N4.

I'll give it a run tomorrow and let you know! Do you know what exactly changed in this code and the previous edition?

laurensvalk commented 7 years ago

You can view all the changes here on Github if you're interested.

I do recommend that you use the latest build (ev3dev stretch 2017 sept 14)

Briefly, I modified the code to:

There are also a few minor changes to the balancing code:

On Sun, 24 Sep 2017 at 22:09, pipothy notifications@github.com wrote:

Hi,

I own 38N4.

I'll give it a run tomorrow and let you know! Do you know what exactly changed in this code and the previous edition?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/laurensvalk/segway/issues/8#issuecomment-331736666, or mute the thread https://github.com/notifications/unsubscribe-auth/ALwVYX1VqDtJHLLwuYH4LxVgSNaKzzI3ks5slrb9gaJpZM4OIQVg .

pipothy commented 7 years ago

Hi there,

Invalid Syntax on Line 26 of segway.py at the args print(args, file=sys.stderr, **kwargs)

Am I missing something? Read the readme, seemed to be identical to before. Anything differently to running the code?

laurensvalk commented 7 years ago

Are you running the latest ev3dev stretch from 2017 sept 14?

laurensvalk commented 7 years ago

Also, how are you currently starting the program?

pipothy commented 7 years ago

Yep, latest stretch.

And I transferred the files over, SSH'd in, chmod the segway.py file then ran python segway.py.

I don't need to do python3 segway.py do I? Dumb question maybe?

laurensvalk commented 7 years ago

then ran python segway.py.

That means you ran the code as Python 2, which explains the error.

You can either do: 

python3 segway.py

Or simply

./segway.py

Because of the first line in the file (#!/usr/bin/env python3), the latter command will automatically select Python 3 for you.

laurensvalk commented 7 years ago

There is also a neat VS Code extension for ev3dev. A nice IDE with easy transferring files to the EV3 and running them.

pipothy commented 7 years ago

Traceback (most recent call last): File "segway.py", line 63, in irRemote.mode = irRemote.MODE_IR_REMOTE File "/usr/lib/python3/dist-packages/ev3dev/core.py", line 1711, in mode self._mode = self.set_attr_string(self._mode, 'mode', value) File "/usr/lib/python3/dist-packages/ev3dev/core.py", line 224, in set_attr_string return self._set_attribute(attribute, name, value) File "/usr/lib/python3/dist-packages/ev3dev/core.py", line 211, in _set_attribute raise Exception('Device is not connected') Exception: Device is not connected

Any idea on this one? Sorry for all the bothering!

pipothy commented 7 years ago

Just found your thread about an IDE, can't seem to find the actual VS code extension, mind throwing me a link to it?

laurensvalk commented 7 years ago

Any idea on this one?

Just to help you debug this a little:

irRemote.mode = irRemote.MODE_IR_REMOTE
...
Exception: Device is not connected

Any thoughts on what that might imply? Sometimes error messages really are helpful :)

laurensvalk commented 7 years ago

actual VS code extension, mind throwing me a link to it?

I linked to it in my previous comment.

pipothy commented 7 years ago

Sorry, I am being very slow! I'm rather unwell today so thanks for your patience.

I checked and all the sensors are connected. The connection to the robot is fine, and an internet connection isn't needed. As such, I had no further ideas.

I clicked every word in your comment about it, but none of them linked. Am I being oblivious? Couldn't find anything else on it in this thread. Do you mean your message that stated "There is also a neat [VS Code] extension for ev3dev. A nice IDE with easy transferring files to the EV3 and running them."?

pipothy commented 7 years ago

Oh Derp, I'm not using an infrared sensor.

I apologise, I'm very slow today -_-

laurensvalk commented 7 years ago

As for the link, try refreshing this page. Maybe my edit didn't get through yet.

pipothy commented 7 years ago

It seems to work! The ability to stop and start it with the touch sensor is amazingly useful, thanks for the work!

It seems better, but I haven't had chance to run it for extended sessions. I will likely be doing so on Wednesday/Thursday when I have time to do proper tests. But at the moment, it seems to be performing well!!!

laurensvalk commented 7 years ago

The ability to stop and start it with the touch sensor is amazingly useful

Yes, it's the only way to stay sane while tuning. I originally developed it for the ballbots/BB8-robot which took a lot longer to tune :smile:

It seems to work!

That's awesome!

pipothy commented 7 years ago

Hi, alas it seems I was simply lucky. The controller still seems to struggle and oscillates a lot. I tried 10 times, it lasted at most 40 seconds.

Was yours more reliable than this? If so, I'll have to examine differences in our build or technique for starting the robot I guess....

laurensvalk commented 7 years ago

I haven't tuned this latest code revision extensively, so it's possible it's not as robust as it could be.

However, having it balance for more than 10 seconds or so is a useful starting point for further tuning. (Getting to this point is the trickiest.)

pipothy commented 7 years ago

Hi, Great, wasn't sure how much you'd tuned it. I'll have a play and let you know! If you haven't extensively tuned it, I'll give it a go and see if I can get any improvements :) Wish me luck! I'll let you know the winning numbers, if I find them...

laurensvalk commented 7 years ago

Good luck. It should be less time consuming than before at least :smile:

Depending on how you're currently doing it, there may be pretty convenient ways to speed it up.

pipothy commented 7 years ago

Hi,

Just to clarify, why 1.51.1? As in, why two multipliers? Also, 1.5 seems a rather large increment...

laurensvalk commented 7 years ago

This was just an example of two incremental adjustments (e.g. 50% first and then 10% because you feel like you need some more gain).

By writing the increments like this, you have more or less a history of what you have been doing, and you can easily undo recent changes or return to the "original" values.

perkinbr commented 7 years ago

I had similar issues using the Hitechnic gyro

This commit in my fork seems to solve the issue for me: https://github.com/perkinbr/segway/commit/838ae21b1287f2d88de7b85f57875dcba2d51f34

The code was using time.clock() as a time reference, which gives cpu time used by the program. I switched to time.time() and got much better results once I decreased the gyro angle gain by a factor of two. I didn't do any extensive tuning.

laurensvalk commented 7 years ago

The code was using time.clock() as a time reference, which gives cpu time used by the program. I switched to time.time() and got much better results

Ah, yes. I had done this for the ballbot extension of this code, but forgot to update it on this repository.

Thank you for pointing this out!

I'll make those changes and have another look at the tuning parameters this week.

Combined with the voltage scaling in the recent update, we'll hopefully see some more consistent performance across our robots, with less dependence on the tuning parameters.

pipothy commented 7 years ago

Great. Is the HiTechnic Gyro much better? Should I be buying one of those?

laurensvalk commented 7 years ago

The HiTechnic sensor has have a slightly higher resolution than the EV3 gyro, but it's not that noticable.

The HiTechnic gyro was originally made for the NXT, at a time when LEGO didn't make that type of sensor. LEGO introduced their own gyro sensor with the EV3, more or less making the HiTechnic sensor obsolete.