VEXpro motor speed tests

Following on to the testing recently done on the cortex comparing control value to motor speed, I though I would do the same test on a VEXpro.

The original data had been posted in this thread and specifically this post.

I tested a VEXpro in more or less the same way as before, a the cortex was used to measure rpm using an IME and speeds were set manually on the VEXpro via a GUI I’m developing for WiFI control.

Here are the results as compared to the previous test. VEXpro control values were normalized to be the same as the cortex.

[ATTACH]6136[/ATTACH]

Much better ! The VEXpro 2 wire ports control the motors (unloaded) in a much more linear fashion with excellent slow speed control.

The VEXpro is controlling the motor H-Bridge in a different way to the cortex and motor controller 29. The cortex seems to place positive voltage on one motor terminal and then switch the other to 0V at a varying rate, this is seen here.

https://vexforum.com/attachment.php?attachmentid=6133&d=1337549564

The VEXpro on the other hand reverses this control. One motor input is at 0V while the other is pulsed to a positive voltage, this can be seen here.

[ATTACH]6139[/ATTACH]

This also shows where the VEXpro makes it’s back emf measurement which occurs every 12 pwm pulses. This can be seen a bit better in this scope trace which also shows both motor inputs.

[ATTACH]6142[/ATTACH]

I’m not sure if this simple change in drive scheme is the reason for the VEXpro linear response (I doub’t it actually), only being able to see schematics would answer that. I want to take a look at the current flow into the motor for both cortex and VEXpro next week (have a rather nice high speed current probe at work), perhaps that would give some more clues.

There is a good explanation of different H-Bridge drive techniques here, it can get pretty complicated.

.
motor_control_speed_vexpro.jpg
VEXpro_speed_60.jpg
VEXpro_bemf_measure.jpg

1 Like

What did you use for ground reference?
Did you check for common reference of CW vs CCW for positive control value?

Vexpro port 16 has Built-in closed-loop speed control!?
If its using back EMF to close the loop, why didn’t the resistor load confuse it into changing PWM width?

Can you try adjusting the load (just drag your thumb on a wheel or something) and watch the scope for change in PWM, or listen to a change in pitch of the gear train whine?

1 Like

I was using a bench supply for these tests and used it’s ground. At one point I did look at the differential voltage across the motor but it wasn’t adding much to my findings.

When direction reverses the waveforms on the motor terminals swap.

Using back EMF to close the loop would be done in software, pretty sure libqwerk is not doing that and it is left up to the user.

Well, I would but I don’t have much in the way of structure/wheels etc. at home, everything is at school, I will try and pick up some parts to use over the summer.

1 Like

How did you start the motors on the vex pro. cqemotortraj or cqemotoruser

    // get motor reference
    CQEMotorUser &motor = CQEMotorUser::GetRef();

then later

    motor.SetPWM( axis, speed );

The code was trivial, receive speed via UDP over the network then send to the motor. There are some issues I have not looked into yet, I don’t like the delay in opening the connection to /dev/qemot but so far I’ve not had any time to really dig into this product.

1 Like

I have seen some real smooth ramping with motortraj calls.

Great data… very nicely laid out. Thank you!

Jason

P.S. I gotta get me one of them VexPro thingies! :slight_smile:

1 Like

IFI hasn’t released schematics, but part of the Qwerk schematic is available here. Sadly, this doesn’t appear to include the I/O board portion, though this is better than nothing. I’ve found that the VEXpro doesn’t vary much from these schematics unless necessary (e.g, the Ethernet port is gone). You can see that the CPU board layout is very similar by comparing the photos here.

Since the VEXpro supports multiple processes, libqwerk has to ensure exclusive access to each hardware unit. This is done using a singleton design that boils down to a shared semaphore (see <singleton.h> and <sys/sem.h> for details). Perhaps that is source of the open delay?

Cheers,

  • Dean
1 Like

Yes, I’ve seen that, not a schematic style I’m particularly fond of, lets just label everything on the Xilinx P0 through P72 and assign functionality later. Unfortunately, this trend was also used in the verilog code, all the IO is labeled in a generic way but does not match the schematic. For example, on the schematic P0 is pin 2, in the ucf file P0 is (apparently) pin 143.

Without the IO board schematic I don’t find it very useful, again as an example, there are three control lines for each of the motors that go to the 100 pin header, after that its anyones guess.

Yes, I don’t really like this way of doing things either, if I were ever to do anything serious with the VEXpro I would probably just rewrite the whole library first. There again, I’ve never liked linux as an OS in a real time embedded environment, there are far better options IMHO.

Edit: I didn’t mean to go off on a rant, it’s just that even with open source software there’s still so much reverse engineering to be done. The code is not particularly well documented and any system having code that interacts with hardware needs some details of the hardware to be available to be understood. I was trying, for example, to use current measurement - it does not work and is not available as far as I can tell, I find things like this in the code.

#if Q1
  mot_reg_mcurrent_measurement = (volatile unsigned short *)addr + 256;
  mot_reg_bemf_measurement = (volatile short *)addr + 256 + QEMOT_NUM_MOTORS*MOT_MCURRENT_MEASUREMENTS;
#else
  mot_reg_bemf_measurement = (volatile unsigned short *)addr + 256;
#endif

So what is “Q1”, was that the original qwerk hardware or perhaps a prototype. If the schematics were available some of this guesswork could be avoided.

1 Like

I completely agree. I’m old-school when it comes to schematics - they should be expressive of the design and the way the components relate to each other. Nowadays, schematics are mostly a parts list and a way to associate pins with nets.

True, though reverse engineering one of the motor ports starting from those three signals is much less work than starting from zero. It is pretty far down on my rather long “to do” list, but at least it shouldn’t be too hard.

Agreed - source code (in all forms) should be expressive. Otherwise you loose much of the advantage of a high-level language.

I think libqwerk is actually a pretty good fit given the linux OS - it does a reasonable job of juggling flexible and simple. It isn’t really any harder to program than Cortex, and since you can dig through all the source (short of the schematic) you can get a very clear picture of what is going on under your code.

I do agree that a real embedded OS with a more formal I/O model would be an interesting option. I’d love to see the power of OO put to use to allow sensor/motor class polymorphism, with common data-stream filters implemented as stackable objects.

Fair point. I’m willing to overlook challenges like this since it is a 1.0 release. My hope/assumption is that these oversights will be cleaned up as TerkOS/libqwerk matures.

Cheers,

  • Dean
1 Like

No, it’s this function.

void CQEMotorUser::HandleOffset()

offset calculation for the bemf code, it’s called after /dev/qemot is opened and several other parameters are set.

takes a few seconds, don’t ever call release otherwise it happens all over again the next time you call GetRef.

I need to figure out to recompile the library as this can be turned off if running open loop.

1 Like