- Posts: 130
- Thank you received: 25
Microbasic code library?
Speed position mode will, as you've already seen, give you great constant-speed motor control at low RPM. It is comparing position of the motor's rotor at each moment with where it should be based on the RPM you've commanded. It will not let you start or end turns at particular positions. This is actually explained quite well in the manual.
Do not throw away your V 1.7 of Roborun - you can still use it to download scripts that you've written with 1.8 (if you like the extra tools there). There will come a time, however, when newer controllers have features not included in 1.7, and then, yes, you will need to buy a license for a newer Roborun.
As I already said, I have no idea why Roborun is loading your computer so badly. It has never done this here on multiple laptops with WinXP, Win7 or Win10 (x64 Pro). Have you used Task Manager or other windows tools to try to figure out what's actually happening? The only bug I've ever experienced is that Roborun may occasionally exit with an unhandled exception while shutting down, and sometimes it doesn't restore when reduced to the task bar and I have to use "Switch To" in Task Manager to get it back up on the screen. No, it's not perfect, and I've suggested various improvements, but it is mostly bug free and quite useful.
So i can program the controller to drive to certain hallsensor positions , right? In case of a turn i can program only one wheel to go 10 positions further while the other wheel stands still and that will be the corner, or do i missunderstand something?
My motors count 90 numbers for a full turn of 1 wheel. So a corner will be 45 numbers or so for one motor...if i let the other motor turn reverse for 45 hallcountings (or numbers) it will make a sharp corner i assume.
What is the difference in your opinion between speed mode and speed/position mode? I'm missing something i guess.
I thought speed mode only controlls the speed and speed/position also controlls the position of the hallsensorcounters.
What i want is a controller who can go exactly to a hallcounter-number by program...for each motor (or wheel in my case) separate and straight forward is both motors going to a certain hallcounter-number.
So you are thinking that what i want is not possible with only this fbl2360? In that case i need the arduino to control..as long as it can get the info from the hallsensors for each wheel.
Closed loop speed mode compares commanded RPM with Hall-sensor measured RPM and adjusts commanded RPM with a PID algorithm to minimize the difference. Works well for controlling speed at higher RPM.
Closed loop speed-position mode predicts rotor position after time t at commanded RPM with actual position at time t and adjusts commanded RPM with a PID algorithm to minimize the difference between predicted and actual rotor position. Position in this case refers to change in the angle of the rotor inside the motor after a very short time. This works better for controlling speed at low RPM.
Closed loop position mode(s) compares the accumulated counts from a given position at time t (either absolute or relative) with the counts you want to reach at that time and adjusts motor behavior to minimize that difference. Position in these modes often refers to multiple complete rotations of the motor.
Oh i see, well in that case i would need the position mode but that mode can't control the speed? Or not as precise as the speed-position mode?
Then what would be the solution to use both modes? Set the roboteq at closed loop speed position and use another controller to count the hallcountings?
Can the roboteq export the hallcountings to another controller? Or can i write software for that in microbasic?
This question was also asked by another user on this forum and he didn't get any reply. He used the CAN protocol and wanted the hallcountings exported to his controller (Arduino i thought). Is that possible? The fact that he didn't get any reply in 2 weeks tells me it's not possible...Well in that case i'll have to ask it on the Arduino forum.
The other user used separate encounters though, not the hallsensors.
So maybe i also have to install separate encounters on my wheels to let them count and send the info to an Arduino direct?
I have to think about a workaround, might use some help to solve this i guess. There must be a way to get it working.
Truthfully, I think you need to spend a lot more time with the Roboteq user's manual. All of the things you've asked about are in there, though not always in a way that's crystal clear. However, if you haven't been able to pull these things out of the manual I wonder whether you have missed other things in other sections that might be safety-critical. I tend to speak very bluntly, but I really think that you should be spending many hours with the user manual. No, you don't need to read stuff about AC motors, or CANOpen or RoboCan if you're not going to use them, but for every section that has any relevance to what you are doing you have to be very, very sure that you have understood what's there, even to the point of understanding every sentence and every diagram. If not, at worst you may create a dangerous situation, but even failing that you may destroy a motor or controller - and that can get pretty expensive.
There's no need to use closed loop speed or closed loop speed-position unless maintaining a very constant speed is of great importance. You could then use a closed loop position mode and just send ordinary open loop speed and turn commands. If you want something approaching near constant speed in open loop, you can use the MotorCompensation routine in my script. But note, MotorCompensation won't hold constant speed with varying load at very low speeds because you can't use current sensors with brushless motors, but I really don't see why that's important to you. What matters for what you seem to want to do is to get to a specific position, and not that you get there at a very constant speed.
If you want to use closed loop speed (or speed-position) AND control where to turn using the Hall counter, you need to retrieve the value of the counter for each motor with Counter = GetValue(_BLCOUNTER) (or the equivalent serial command). That can then be used within the script or sent to another microcomputer by serial or CAN if you should so wish. It will be up to you to write the code to figure out where you were, where you are now, when you get to where you want to be and what to do when you get there. That's a fair amount of code to write.
Thanks a lot LRobbins, this gives me hope...so it is possible with this controller , that's all i wanted to know...so it's worth spending (much) time studying how to program this controller.
When i started this project there was no information about the different closed loop modes online (1 year ago) and what i read/learned of the manual was full of bugs, mistypes and other faults. The whole manual was a big mess. Now there's even a new manual i believe so i'll have a look at it and read it all many times again. That's all great so i'll go for it.
I didn't read the manual for a year, got so frustrated from them and the fact that i had the software causing my motors going erratic in closed loop modes, i didn't know the software could be wrong and thought it was my fault all the time or EMI or anything else on my side. Now the controller is fixed and the robot has been rebuilt several times, it's all perfect now so i'll go for it and start studying.
Blowing up the controller or motor isn't my main concern, of course i don't want it to happen but this robot has to be driving/mowing/sweeping along very expensive cars, i really don't want it to have strange behaviour. So i'll test it a lot before delivering at my customers (who are my brothers in Singapore). This robot has to be a showitem for them and they even want it to cut their companyname/logo in the lawn every day (they have a law firm).
I have never tried the position mode, also get confused about which settings are important for that and which aren't or which are not needed at all for this mode..I'll try them all out since my robot has not shown any erratic behaviour since the new software was given to me. Except when i used version 1.8 last month, then the erratic behaviour was back and also the controller changed the motorchannels by itself when i went into closed loop . So i installed 1.7 again and it worked flawless again. That's why i won't use 1.8...i test it in a livingroom and don't want erratic motors, this robot is heavy and can easy drive through windows.
I don't know how important the constant speed is for lawnmowing or sweeping, will test it out tomorrow. It will be perfect if i can use the relative position mode for lawnmowing. It just has to drive slow over the lawn (which is not perfectly flat). The sweeper works at many speeds but not too fast.
Now i can't wait to start learning Microbasic and all in's and out's of this controller. It's all possible at the hardware side it seems. After that i'll install the 3d camera and the rest of the gimmicks , i prepared everything for it already but still didn't know if it all was possible with this controller or not.
If the code that i'm going to write is too large for this controller i can always go to the Udoo and do it there. First i'm going to play with the relativ position-mode and see what that can do.