RE: LoadCape and Trying/Seth

Linux - Win IoT
41

Hello Dave,

No issue. I got some software up and running for the motors. I have been messing around w/ a set of software that is supposed to run both motors but the silly software is giving me trouble.

It is almost like I am trying to fit a cube in a cylinder right now. Yea, you are right. I do not have extreme practice w/ wiring and electronics.

…

GitHub - silver2row/loadcape: LoadCape is what I have been working on so far. If you get time to look it over, that would be nice. If not, that is okay too.

Seth

P.S. I have two classes but I may need to add an additional one or take one away to use a wrapper instead. I am just not sure right now.

42

ok, so here’s how I would troubleshoot the code you presented. Note, I’ve got virtually no idea about Python :slight_smile:

I would get things working in a single class for a single motor.
Car(leftMotor=BrushedDC(m1=“P9_42”)
Prove you can make one wheel do all your primitives - forward back etc
Now, prove the other one works.
Car(leftMotor=BrushedDC(m1=“P9_41”)
(note the change of GPIO for this one)
Prove you can make one wheel do all your primitives - forward back etc

So now you know your code works - it can independently control two different wheels.

Then you need to think about how you combine this - obviously using class structures makes sense, right? edit: I changed this for clarity. So I’d potentially change your current “BrushedDC” class to be “Wheel”, and it should have only primitives such as forward/back/stop. Then your “Car” class needs to have two “Wheel” objects, like you started to do, one left and one right, and introduces concepts like pivot & turn as combinations of primitives where you act on only one wheel or both, in different combinations.

One other thing I think I would change is how you treat the “wait” parameter - without knowing what you think your behaviour is in some detail, this might be an idea to look at. I consider a primitive like “forward” for a duration to be “start”, a “wait”, then a “stop”. Same with back, it’s drive/wait/stop. If your intent in putting waits at the end of each definition like the one below was to have that define the length of time that the motor drove for, then you’re relying on the next step to stop what you were doing, which it may not do - and I notice you have added stop() to the start of a few primitives - that’s actually in my view a bandaid that is more confusing.
def reverse(self, wait=0):
self.leftMotor.reverse()
time.sleep(wait)
# self.leftMotor.stop() # missing
Think about two forward steps:
myCar.forward(5)
myCar.forward(5)
myCar.stop(2)

This calls what I’ll term wheel.Forward, which does a stop then turns on, then waits for 5, then the next call invokes and it calls stop, turns on, waits 5, then the final statement calls stop. While this sequence may seem to generate reasonably close to the correct sequence, it’d be better in my view for Car.Forward to be Wheel.Forward() + wait + stop. Then all you have to do is call Car.Forward(5) twice.

43

Hello Brett,

Okay…I read what you posted. I do not know when you viewed my software but I am thinking very recently. I will take into account that starting is easiest to call in the software once wait and stop have been invoked.

Seth

P.S. I will also test both motors, i.e. one at a time until I can get both working simultaneously. I think you got what I was gearing towards in the software that I updated recently. I can make the motors move now, which is better than one, in one amount of software but they are not working in sync like I am going to finally make them work.

44

I reviewed the GitHub repo some time between when you posted the link to it and when I replied. I had the .py file open when Io was replying.

Yes, I get what you were trying to do in your code. Since you were brief in describing what you were seeing in code, I helped how I could - to help you address the discrepancies in how you treat directions than anything.

I’ve had some more thoughts about where you should be controlling the stop as well - because some actions want to be performed at the same time (eg drive both wheels) you need to have two different calls. Wheel.Forward() and Wheel.Forward(time). When there is no time, it just runs until it’s commanded to stop.

If Python classes are like other language classes, you should have no problem creating two objects using the same class - so your CAR class would have a LeftWheel = wheel(leftGPIO) and RightWheel = wheel(rightGPIO).

From there, your car.forward() will do something like:
LeftWheel.forward()
RightWheel.forward()
sleep(waittime)
LeftWheel.stop()
RightWheel.stop()

Your car.turnLeft() might do:
LeftWheel.forward()
RightWheel.reverse()
sleep(waittime)
LeftWheel.stop()
RightWheel.stop()

hope that helps

1 Like
45

Hello Brett,

Seth here. Good idea! I should try to control both motors as one at times. “Almost like a transaxle w/ brakes.”

…

I will test out your idea(s) soon. Python is similar to other languages in way of classes (I think). I am by far a pro. in this field as of now. I just tinker w/ items until I can use them and address concerns from others w/in specific categories of that item.

Anyway…

I will test it out soon.

Seth

P.S. I will reply and let you know exactly if I altered the configuration to better suit this “transaxle” idea w/ two motors.

46

Hello Again,

I am using this software now to test two motors at different times: https://github.com/silver2row/loadcape/blob/master/SinkOneII.py My def functions should be reusable, right.

…

Okay…

So…I reuse them at the end but inevitably, this is not what I need. I plan to do something like this w/ the software in the end: https://github.com/silver2row/motocape/blob/master/MotoCape.py. Lines 24 - 56 is what I am describing w/ the imports of my choosing.

…

Although that software cannot move backwards, someone on Freenode at #beagle showed me a way to make a wrapper w/ classes.

…

Okay…back to the subject at hand. I am going to make a separate set of software w/ what I believe you are telling me is a good idea. I agree but I need to produce this effect to show you in case I am incorrect. I hope that makes sense.

…

I will turn the software into what I think you are telling me to do (I know these are just your recommendations on ideas). Do not worry. I do not have to base my entire ideals around what you are saying so I can complain later.

…

Brb. Off to make this gibberish a reality.

Seth

P.S. Here is that bunch of my gibberish into software: https://github.com/silver2row/loadcape/blob/master/SinkerOne.py. I hope this will provide how incorrect I am at the moment. I tried to understand. I will revisit your ideas soon to make corrections.

47

all your code is unclear to me what you’re trying to achieve. There’s PWM scattered in one of them (for what?) and it’s not clear what you’re focussing on or how you’re “developing” this.

Start with a single file, that represents a single intent, and focus…

As I’ve shown you, you want to have “primitives” that don’t do a wait. You’ve not considered that. in your last file, SinkerOne.py, you are somewhat there. But some of your code is weird.

Left.forward(5)
Right.forward(5)

So this will start the left wheel, and wait for a count of 5. So in that time, the vehicle will have slewed one way (assuming the right wheel won’t freewheel). Then the right wheel kicks in, and the code waits for a count of 5. The vehicle will essentially drive straight forward (but not the way it was faced when you started). And then the motors are still left running.

Left.stop(5)
Right.stop(5)

So now you stop the left wheel, and wait for another count of 5. In this time the right wheel is still driving, and so it’ll straighten the vehicle to approximately the way it was facing originally, and then it’ll stop the right wheel (it’s now doing nothing) and then you make it wait 5 again.

Left.reverse(5)
Right.reverse(5)

Now you do the whole thing in reverse, slew one way, wait 5, start the other motor, wait 5…

Left.stop()
Right.stop()

And now you stop them both instantly. So at this point, the vehicle is not pointing the way it was originally.

As you can see, these will make a vehicle do stuff - but honestly ordinarily what you want the “higher level” control to do is to direct the vehicle in small iterative steps, not turn it on, wait 5, and hope you get what you want… you really need to distil your primitives even more. Think logically - you’ve done well on your “motor” object, that is all it can really do, but when you start talking about a “wheel”, you have some things that just don’t make logical sense in their own object:

def leftTurnForward(self, wait=0):

self.leftMotor.stop()
time.sleep(wait)

What does that mean?? It just stops the wheel and then sleeps - pointless isn’t it?

def rightTurnForward(self, wait=0):

self.LeftMotor.forward()
time.sleep(wait)

Same here, it’s not a meaningful construct of other functions of a motor.

These are relying on the fact that the other constructs are operating in some way - where what you really want to do is to make them do their own thing and not assume something else is going on.

48

Hello Brett,

Seth here. Thank you for the clarification. I get what you are saying. Why would a motor stop and wait while the stoppage time is ongoing already? Understood.

…

Oh and that bunch of software produced is from many related books and articles, some help from Freenode people, and a few additions from me. The /silver2row/motocape/ stuff is what I came up w/ for the MotorCape from GHI and BeagleBoard.org.

…

I will try to make more sense in the /silver2row/loadcape/ software and report back. Who knows? You may teach me more than I expected on relationships b/t motors and software.

Seth

P.S. Give me about a week so I can come up w/ more ideas on the subject at hand. Oh and I know you are not relying on my return of service but this forum is nice!

49

Hello,

Christmas time w/ the BBB. I am sure everyone will get to this whenever people feel like it. So, w/ that in mind, I shall not rush anything.

…

I have changed some software over time and I have tried things that are not usual to me for using two motors simultaneously.

For instance…I want both to start and stop at the same time. Okay, I got one down pat. I can make it do all sorts of things w/ the GPIO availability from user space and Python w/ the Adafruit_BBIO.GPIO library.

I have been unable to make GPIO understand both directions and both motors need to listen to me. Although this is my issue, any resolution would be helpful. What type of wrapper would I need for GPIO or do I need to use both GPIO (P9_42 for Sink1 and P9_41 for Sink2) in my first class?

I think I have tried both actually. Right now, w/ the Christmas spirit and all, I will not have time to annoy everyone w/ my ideas on wrappers, Python, and the nice Cape. Just a reminder, I am dealing w/ the LoadCape from GHI and beagleboard.org from this GitHub repo: GitHub - silver2row/loadcape: LoadCape

…

So, to Brett, I tried changing my class many times, I changed the number of GPIO pins I had available in them, I also changed the wait=0 to a blank section (nothing), and I tried to change, when I had the first two classes available, line 124 and line 126 to better suit the testing which can be found here: https://github.com/silver2row/loadcape/blob/master/SinkerOne.py.

I know you, Brett, are used to handling these issues and if you can find time, please do reply.

I sure could use as boost of ideas.

I have gone through the Python.org section on classes many times. Since I am dealing w/ physical items (motors), I think their class structure is detailed but in another category of ideas. I have checked online for other ideas.

I have found some but people keep using PWM for use w/ motors. This is something that has been beat to the core.

…

Seth

P.S. Oh and no need to rush, unless completely bored from odd family members (odder than me), to reply. I am okay not knowing half of what I thought I could achieve for now.

50

I don’t have time to help in any significant way, so I will just reaffirm what the test path I want you to have is…

Write a set of code that allows you to control one (and only one) motor with the correct front and back controls. Please ignore PWM at this time, it’s an advanced capability and may not work for your motors and controllers - think of the load module as a forward and reverse switch only, no speed control.

Please write the code so you declare pins that you’re using in one area - so you can change them. Again, make sure it works and you haven’t broken anything.

Once it works for one motor, without changing the code, JUST change the pins that it talks to. Make sure it now works for the other motor and the behaviours are all correct. So that means you now have a block of code that works and all you needed to do was change the pins. You can now consider that block of code a “class”, in that you create TWO objects that uses that code but are created with different pins.

Then you should be able to operate on each motor within the one application block just by using those two objects.

51

Hello Brett,

No issue w/ the support on a software idea. Thank you for the route to take, too. I will test out the ideas over and over. I will make one move in formation (forward and reverse) and then make the second motor do the same.

Just for reference, I could not make the motors move simultaneously. For instance, they start and stop at seconds apart so far.

…

So, I will get to it again and get back to you in case you have any other ideas that are worth your time.

Seth

52

last time I looked, you had sleep() sprinkled in your code. You needed to get rid of that, and it’s probably the cause here !!!

53

Hello,

Okay. I will try that avenue out.

Seth

54

Hello Everyone,

Seth here (again). I know…we should stop meeting this way. Anyway, I have a couple of questions about the LoadCape still.

I saw in the page located here, GitHub - beagleboard/capes: Official BeagleBoard.org capes, that there are actually two “forms” of P9_42 for Sink1. What does the a/b mean for the this specific pin?

Seth

55

If you want to control 2 motors both for direction and speed, I suggest you purchase the MOTOR CAPE.

The LOAD CAPE is not designed for motor direction control without additional external parts. It is really designed for relays or single direction motor control.

I think this would make your project much simpler and quicker to develop.

When if come to software, you need to remove all of the sleep commands and use a timer. This way you can run to motors at the same time and stop them at the same time too.

56

Hello,

Seth here. No issue. I will quit replying here. I did purchase the MotorCape and RelayCape too. I just wanted to find out what the LoadCape had to offer since it was nicely priced.

Seth

P.S. Consider this the last post on this idea for the LoadCape. Sorry for not understanding right away.

57

The Load cape is definitely a different beast - and as Dave says there are better things to do full motor control with.

But you should still be able to get the fundamentals going. We’re not trying to push you away, just trying to help you as best we can, since most of us don’t own these capes

58

Yea Man,

No issue. I just understood the concept of this Cape incorrectly.

Seth

1 Like