PDA

View Full Version : Renard protocol... what does it look like?



John in WI
01-03-2012, 09:22 PM
I've been searching these forums and I'm sure it's here somewhere, ( I can't find it) ... exactly what does a renard packet look like?

I'm setting up my own pic software and need to know what data is being sent with each "tick" of vixen. I can't use the pre- programmed .asm files posted here. I'm using a 40 pin 18F pic and need to write my own code.I prefer C, BASIC or JAL to assembly. Much more readable. I suspect most will be non pwm outputs, but that's OK.... I think there are something like 36 outputs on this cheap microcontroller. I'm using the internal oscillator, but these newer chips internal oscillator are really accurate & fast (16-64 MHz +-1%) and have used moderately fast serial with success in the past.

Does the pad byte get sent every "tick"? The sync byte? How is the packet information formatted? How and in what order are the channels and levels identified?

Long story, but in a nutshell, I'm teaching a robotics class for kids that the Vixen sequencer will work really well for. Each "team" gets a 40 pin pic board with a load of LEDS, resistors, wires, bluetooth serial, a couple servo motors and a base , then builds a "performing", moving light-up robot. I just need to figure out how to communicate with the pic!

thanks! -John in WI

jklingert
01-03-2012, 09:24 PM
http://www.doityourselfchristmas.com/wiki/index.php?title=Renard#Protocol

frankv
01-04-2012, 03:10 AM
C source code attached. This is for Linux, sending to a Ren24 board. So it's the opposite of what you're after, sorry. But you should be able to see how it works easily enough.

And you can do away with Vixen and get your kids to program the controller in C too. :)

Frank

LabRat
01-04-2012, 06:37 AM
FYI the "Simple REN24" and/or "Simple REN32" are PIC18F series, and would already have the REN parsing code in place.
That being said, the term "robot" is often equated with "autonimous" thus I wonder why you would be looking to something like Vixen to begin with?
There's no feedback mechanism in place there, so how would you create software that could react to say.. walking into a wall?

You might consider looking at something more like the following robot controller (18F series):
http://www.ottawarobotics.org/igore.shtml

John in WI
01-04-2012, 01:42 PM
We've been down the traditional robot controller route many times.... robot games & competitions, etc. All successful enough, but fail to add any real artistic creativity into the process. In one robotics summer camp I held, the robots competed and we crowned a winner... we had some time left and asked the kids to make their robot dance to music of their choice. I was overwhelmed with the positive response I got from this "desperation" activity. Some that seemed bored with the process otherwise came alive and enthusiastically participated. Our robotics leadership group has decided to take this to the next level and hold a robotics competition similar to American Idol, etc. We see it as an avenue to interest those that might not otherwise be interested (girls) in robotics.

That is part of the reason I want to write my own PIC code. I want to use a "wide" 40 pin PIC. Then there is the option of including a sensor or 2, which of course, Vixen will not accommodate. We need to write the sensors or what ever into the PIC code.

It is very difficult to write an effective musical sequence in C or other scripted languages. The graphical approach that Vixen takes is ideal for sequencing a robot to music, especially for kids.

As far as I can tell, at each "tick" of vixen, it sends a 0x7d(pad) then a 0x7E (sync) then a 0x80 (address byte) then a sequence of one byte dimmer values for each channel that has been set up.
am I on the right track?

If I was real ambitious, I would grab the sequence data from the Vixen xml file and use it my own robot control software but time is tight. For now, controlling from Vixen will suffice.
Thanks
-John in WI

mmulvenna
01-04-2012, 02:49 PM
We've been down the traditional robot controller route many times.... robot games & competitions, etc. All successful enough, but fail to add any real artistic creativity into the process. In one robotics summer camp I held, the robots competed and we crowned a winner... we had some time left and asked the kids to make their robot dance to music of their choice. I was overwhelmed with the positive response I got from this "desperation" activity. Some that seemed bored with the process otherwise came alive and enthusiastically participated. Our robotics leadership group has decided to take this to the next level and hold a robotics competition similar to American Idol, etc. We see it as an avenue to interest those that might not otherwise be interested (girls) in robotics.

That is part of the reason I want to write my own PIC code. I want to use a "wide" 40 pin PIC. Then there is the option of including a sensor or 2, which of course, Vixen will not accommodate. We need to write the sensors or what ever into the PIC code.

It is very difficult to write an effective musical sequence in C or other scripted languages. The graphical approach that Vixen takes is ideal for sequencing a robot to music, especially for kids.

As far as I can tell, at each "tick" of vixen, it sends a 0x7d(pad) then a 0x7E (sync) then a 0x80 (address byte) then a sequence of one byte dimmer values for each channel that has been set up.
am I on the right track?

If I was real ambitious, I would grab the sequence data from the Vixen xml file and use it my own robot control software but time is tight. For now, controlling from Vixen will suffice.
Thanks
-John in WI


You might want to run port monitor while commands are being sent from VIXEN and you will see the data being sent to the renard device. That should help clarify what is being sent and how it know what channel is what.

P. Short
01-04-2012, 03:19 PM
It shouldn't be sending the PAD before the 0x7E, unless the channel count is one of a few specific values. Other than that, yes.

The PAD byte is a character that is sent once every 100 bytes, or so, and is discarded by the first controller without being forwarded. This allows gaps in the data string after that point so that controllers with a slow clock can have a breather and not overflow their output transmitter.

P. Short
01-04-2012, 03:28 PM
BTW, maybe I'm being dense, but will the 40-pin PIC that you described be sending a Renard data stream or receiving it?

LabRat
01-04-2012, 03:58 PM
Rx .. (at least.. I'm pretty sure that's what 's being described)

John in WI
01-04-2012, 09:03 PM
Thanks for all the replies....

Yes, the PIC will receive the data. All we're gonna do is turn on an output to light an LED at a certain time. Communication will be via Bluetooth serial.

So, I should ignore the pad byte when it arrives? It is not sent at any regular interval?
If so, I think I'm ready to right some code. I will post my results here. I really like a language called JAL for pic programming. Some really great easily usable libraries available... kind of like the mass of libraries for Arduino, only for PIC. JAL is likely what I will use.

Any other insights on Renard protocol are welcome. I will not be daisy chaining micro controllers for this project.


Once I get the lights working, I will modify my code & send PWM servo control to 2 or 3 of the outputs to move some servos based on dimmer values received from Vixen.

Materdaddy
01-05-2012, 10:21 AM
So, I should ignore the pad byte when it arrives?

Yes


It is not sent at any regular interval?

Every 100 bytes.