Developing a new controller, Papywizard compatible

[panoguy]

by panoguy » Sat Feb 13, 2010 11:24 am

Hi Frédéric
what is the difference between this two commands?
F<axis> Check axis
f<axis> Get status

If there is not real additional benefit to use both commands,
I would drop the F<axis> command from the Gigapanbot plugin.

[fma38]

by fma38 » Sat Feb 13, 2010 12:42 pm

In fact, I don't really know what the 'F' command does. Someone said that it is to check the axis controller presence. It returns nothing, so I don't know what is the goal (just using 'L' command is enough: if the axis does not work, the command will fail and that's it).

I think we could remove it.

[fma38]

by fma38 » Sat Feb 13, 2010 1:30 pm

I<axis><speed> Set motor speed, 3 possible HEX values, "0AA" "022" "011", low value=high speed

What is the length of the speed value? Is it also a 6 chars hex? Or only 3 chars?

I would prefer 6 chars, as for other values...

Last edited by fma38 on Sat Feb 13, 2010 1:38 pm, edited 1 time in total.

[panoguy]

by panoguy » Sat Feb 13, 2010 3:23 pm

I<axis><speed> Set motor speed, 3 possible HEX values, "0AA" "022" "011", low value=high speed

What is the length of the speed value? Is it also a 6 chars hex? Or only 3 chars?

I would prefer 6 chars, as for other values...

Some background to my firmware:
1. Goto function
I have defined 3 speed values which defines the maximum speed of the motor during the goto function.
On top of that I'm using a ramp function to accelerate and decelerate the motor during the goto function.
In practice you want to goto position as fast as possible, therefore you only need a well defined ramp function and you can ignore the parameters to limit the maximum speed.
Due to the ramp function the head does not accelerate to a high speed if the goto position is very small.
This means the speed limit does only limit the motor speed when I request to goto a far position (lets say 60°)
My head turns a full 360° turn in
7 sec when speed is set to high
12 sec speed set to medium
17 sec when speed is set to low

2. Manual move with the buttons on my device
I have 4 buttons to move the head around, same as you have.
When I press one of the move buttons, the head starts to move very slowly and then constantly increasing the speed up to a maximum speed. When I release the button it stops moving.
In this case I do not use the speed limit parameter.

Conclusion: I do not really use the 3 different speed limits as it is not needed.

For controlling the head remotely the speed parameter is used when you move the head manually to a new position, right?
If we want to make it easy, we can use 1 char only and send only 1,2 or 3 where each number represents one speed. Even this would allow us to set 9 speed values in dec, or even 15 values if we use HEX.
If it is easier for you to use 6 char, HEX, it's fine for me too. It only needs to be documented.

[fma38]

by fma38 » Sat Feb 13, 2010 4:01 pm

Using only 1 digit is fine for me.

So, you are saying I don't need to implement the manual speed function (which is set using the home/begin PC keyboard buttons, or +- Nokia buttons)?

Do you think it is interesting to add the speed limit param in the plugin, for the goto function? Or just always use the highest one?

[panoguy]

by panoguy » Sat Feb 13, 2010 5:00 pm

Using only 1 digit is fine for me.

So, you are saying I don't need to implement the manual speed function (which is set using the home/begin PC keyboard buttons, or +- Nokia buttons)?

Do you think it is interesting to add the speed limit param in the plugin, for the goto function? Or just always use the highest one?

For the manual move function it could be useful to have the option to set different speeds, therefore I would not remove it for now.

For the goto function it could be a 'nice to have feature'.
But the goto function could use the same speed parameter (of the move function), so there is no need to add an additional parameter.
So this is just a matter of how you implement the controller firmware, if you use the parameter for both functions or if you just ignore it.
If one is developing a high speed head, it may be useful sometimes to limit the speed.

[fma38]

by fma38 » Sat Feb 13, 2010 5:14 pm

Let's say that the 'I' function is only the manual speed, and you always use the fastest speed for the goto function. We'll see later if we need an additional param for the goto speed...

Is 1=slow, 2=normal, 3=fast ok for you?

[panoguy]

by panoguy » Sat Feb 13, 2010 9:36 pm

Let's say that the 'I' function is only the manual speed, and you always use the fastest speed for the goto function. We'll see later if we need an additional param for the goto speed...

Is 1=slow, 2=normal, 3=fast ok for you?

I would prefer the other way around,
0=fast
2=medium
4=slow
this would corespond to my current speed settigs used by the goto function.

[fma38]

by fma38 » Sat Feb 13, 2010 10:35 pm

No problem!

[panoguy]

by panoguy » Mon Feb 15, 2010 3:15 pm

In fact, I don't really know what the 'F' command does. Someone said that it is to check the axis controller presence. It returns nothing, so I don't know what is the goal (just using 'L' command is enough: if the axis does not work, the command will fail and that's it).

I think we could remove it.

Hi Frédéric,
coming back to this not used F command...
I wanted to display on my controller when the connection has been established byPapywizard, and when the connection has been dropped again. I tried different ways but non of them is really reliable.
We could use this command to acknowledge the controller that the connection by Papywizard was successful.
After sending all initial startup commands and successful acknowledgment, Papywizard would send
F:<axis> 1=connection successful (or 0=connection not successful)
The controller would respond with the standard response '=\r' and display by flashing blue LED or whatever that the connection with Papywizard was successful
At disconnect Papywizard would send
F:<axis> 0=connection terminated
and the controller would respond again with standard response '=\r' and disable the blue LED.
Is is possible to use F in this way in the plugin, always as the last command after connect/disconnect?

[fma38]

by fma38 » Mon Feb 15, 2010 3:41 pm

Ok, I can add it again, using your way (I removed it from 2.1.16 release). I will send you the plugin when it's done.

[fma38]

by fma38 » Mon Feb 15, 2010 3:51 pm

Don't forget that all plugins (yawAxis, pitchAxis, shutter) are independant, so you will receive twice F11 and F10, as the shutter also uses axis 1... Is it OK?

You may need to keep track how many times an axis has been connected/disconnected.

[panoguy]

by panoguy » Mon Feb 15, 2010 5:37 pm

Don't forget that all plugins (yawAxis, pitchAxis, shutter) are independant, so you will receive twice F11 and F10, as the shutter also uses axis 1... Is it OK?

You may need to keep track how many times an axis has been connected/disconnected.

Thank you!
Yes this should work, usually all used axis are either connected or disconnected.

[panoguy]

by panoguy » Sat Feb 20, 2010 10:08 pm

Finally I implemented the firmware as additional function into the original Gigapanbot. So I can still use it without the Nokia and Papywizard.
In addition to that I build a new board with minimal features and only one motor driver.
This combo can be used nicely for pole panoramas or any other places which can benefit of wireless control.
I uploaded a short video there you can see in the first part the second version with one motor and in the second part the original Gigapanbot.
Here is the link to the video:
http://www.youtube.com/watch?v=5Thj1YMPczw

[Greg Nuspel]

by Greg Nuspel » Sat Feb 20, 2010 10:14 pm

Your video comes up as private so I can't view it.

[claudevh]

by claudevh » Sat Feb 20, 2010 10:56 pm

"Private Video" this is the same for me ....

[panoguy]

by panoguy » Sat Feb 20, 2010 11:00 pm

Sorry, try again ...
http://www.youtube.com/watch?v=5Thj1YMPczw

[claudevh]

by claudevh » Sat Feb 20, 2010 11:04 pm

That's OK now ! Thanks

[fma38]

by fma38 » Sun Feb 21, 2010 11:51 am

Nice!

[panoguy]

by panoguy » Mon Apr 19, 2010 11:17 am

Short update on my latest video:
I got a camera crane for the Gigapanbot
http://www.youtube.com/watch?v=_a-cTWveBcY

[Paul]

by Paul » Mon Apr 19, 2010 12:08 pm

The bigger the boys, the bigger the toys.

What about adding this gear to Kolor shop special deals? ;-)

[Greg Nuspel]

by Greg Nuspel » Mon Apr 19, 2010 12:28 pm

I think you have to work on the portability of the unit

[fma38]

by fma38 » Mon Apr 19, 2010 1:25 pm

Amazing!

[Gordon]

by Gordon » Mon Apr 19, 2010 2:46 pm

Skilled Crane operator ;0

[shutterdrone]

by shutterdrone » Wed Apr 21, 2010 5:37 pm

Panoguy, did you ever figure out how to do the async motor control on the AVR? I couldn't tell from the posts. I wouldn't use something like that "pseudo-threading" library, as the overhead is unneeded for a fairly simple activity.

FWIW, I'm doing the same thing currently, and while I don't have (yet, at least not here at the office here's some p
pseudo-code showing how I'm doing it:

(This assumes single-axis for demonstration)

Code: Select all

 #define DRIVER_PULSE_MIN 30 // 30uS minimum pulse time to register

 set_timer1_interrupt(cur_step_delay);
 set_timer1_isr(move_motors);

 volatile bool which = false;
 
 void move_motors() {

   if( ! which ) {
     PORTD |= B1; // 2 cpu instructions, can drive up to 8 step pins with this instruction
     set_timer1_interrupt(DRIVER_PULSE_MIN);
   }
   else {
     PORTD &= B01111111;
     set_timer1_interrupt( cur_step_delay );
   }
 
 which = !which;
}

This works beautifully, it's not hard to add linear velocity ramps - I've been able to get > 10kHz step rate in actuality like this.

!c