CAN Nerf Robot

[Mike Copioli]

For those of you who were not at IRI here is a link to a video of the Nerf Robot. The control system is CAN based and uses the 2CAN along with our new CANipede RCM(robotic control module) which will be released this fall.

http://www.crosstheroadelectronics.com

[EricVanWyk]

For those of you who were not at IRI here is a link to a video of the Nerf Robot. The control system is CAN based and uses the 2CAN along with our new CANipede RCM(robotic control module) which will be released this fall.

http://www.crosstheroadelectronics.com

Dearest Mike

I love it.

Enviously,
Eric

[Mike Copioli]

Thanks Eric.

[kamocat]

So far I've seen the packaging advantage of CAN to be that you can place your controller directly by your actuator, and have your sensors bundled right in, to make a modular actuator which is easily manufacturable and replacable. (Say, an arm module, or a wheel module for the drivetrain)
Are you interested in creating something like your CANipede on a smaller scale for FIRST use? Here's what I would be interested in:

A relay module with a limit switch in each direction. Fusing, an LED indicator, reverse-voltage protection, socketed relays, and pluggable power connectors would be nice too.
A PWM-based servo controller with just two or three outputs for the camera gimble. You could even put the 5v camera power right there, and provide an extra-flexible ethernet ribbon cable for the camera.

[Mike Copioli]

I am not sure what you mean by smaller scale. Quantity or physical size? The CANipede is almost all of what you requested. The only thing missing is the on board relays. That is in the works as well. However there are some legality issues with FIRST when it comes to output devices. As it stands now the CANipede is not legal for FIRST use when used to generate PWM signals our to control relays. A smaller version of the CANipede that has only inputs (Analog, Digital) is planned. It will most likely be bus powered making wiring simpler and clean.

[kamocat]

My impression was that the CANipede had these all on a single device, much like a central controller. I'm proposing small units which would be dedicated to an actuator, to supplement the Jaguars.
Did I misinterpret the description? Is the CANipede actually several devices?

Personally I don't see the utility of putting sensors into ADCs on a CAN bus when we have a cRIO. IMHO I think the CAN bus should only be used for actuators that have their own feedback. If the Jaguars didn't have PID and encoder inputs, I wouldn't bother. However, since they do, it's theoretically less processing that the cRIO has to do, and the processor time can then be used on other (presumably higher-level) tasks. Likewise, putting too many things on the CAN bus can create a chokepoint there, and reduce the performance of the system. For example, the gyro and accelerometer are sensors that require high sampling rates in order to be useful. Thankfully we have an FPGA to integrate the gyro, but if we want to know something with the accelerometer like "how hard did we hit that wall?" or "what was the impact coming off that bump", we must poll that analog input very rapidly. Such an action on a CAN bus would be either sporadic, or block out all other communication (including the messages that keep the Jaguars enabled).

[Alan Anderson]

Personally I don't see the utility of putting sensors into ADCs on a CAN bus when we have a cRIO.

Using something like a CANipede, you can do without a cRIO. All the computing can be done on a wirelessly-connected laptop computer. You need that computer anyway if you want remote control via joystick or gamepad.

[Mark McLeod]

It's a much cheaper way to keep old robots operational without having the expense of purchasing a new cRIO, modules, breakouts, PD every year. It makes it cheaper to build concept or practice robots too.

[kamocat]

It's a much cheaper way to keep old robots operational without having the expense of purchasing a new cRIO, modules, breakouts every year. It makes it cheaper to build concept or practice robots too.
Ah, I see what you're saying. An inexpensive control system that can be programmed in any language, for the purposes of resurrecting old robots for demonstrations, and for mechanical proof-of-concept.

I guess, then, the answer to my questions is a "no", because that's not the market CrossTheRoad Electronics is focussing on.
Thanks!

[Mike Copioli]

My impression was that the CANipede had these all on a single device, much like a central controller. I'm proposing small units which would be dedicated to an actuator, to supplement the Jaguars.
Did I misinterpret the description? Is the CANipede actually several devices?).

No, it is one device.

Personally I don't see the utility of putting sensors into ADCs on a CAN bus when we have a cRIO.

The ADC CAN node does not need to return just raw analog data. The node itself could perform the math functions needed for a particular sensor. The application could then request the resultant data when ready. In the case of the Victor, the canipede generates the PWM signal and reads the encoder making it a closed loop speed controller. The application simply sets a position or velocity over CAN the CANipede takes care of the rest. It also normalizes the output of the Victor so that it becomes linear.

For example, the gyro and accelerometer are sensors that require high sampling rates in order to be useful. Thankfully we have an FPGA to integrate the gyro, .

An FPGA is a digital device, by itself it is unable to perform analog sampling. It could be used to perform the integration math but it is not necessary since gyros and accelerometers do not require high frequency sampling. Is this what you meant?

we must poll that analog input very rapidly. Such an action on a CAN bus would be either sporadic, or block out all other communication (including the messages that keep the Jaguars enabled

This is not the case when CAN is implemented correctly. The FRC implementation is not the most efficient way. The current approach sends every CAN message over Ethernet/serial from the cRIO. The CAN device then must send an ACK back over Ethernet/serial to the cRIO. If I remember correctly the function is also blocking. A better way would be to allow the gateway device (2CAN or Black JAG) to perform all of the CAN "hand shaking" and have the application simply make requests for position, speed or current... The reason for the current implementation is to allow teams to create their own CAN gateways without having knowledge of the Tokenization protocol used by the Jags.

[kamocat]

Thank you for your detailed response. That clears a lot of things up, and gives me more insight as to why I'm seeing such poor performance on the FRC CAN system. (It's because there's a lot of handshaking and token messages going on in "trusted" mode, and I don't have a specification for them, so I can't quantify them and take them into consideration when I make estimations.)

So with the exception of the enumeration command, the message throughput on the CAN bus in FRC directly relies on the rate of communication between the cRIO and the master CAN device? There isn't much overhead in the CAN plugin on the cRIO, or in translating the message from RS232/ethernet to CAN?

[Radical Pi]

This is not the case when CAN is implemented correctly. The FRC implementation is not the most efficient way. The current approach sends every CAN message over Ethernet/serial from the cRIO. The CAN device then must send an ACK back over Ethernet/serial to the cRIO. If I remember correctly the function is also blocking. A better way would be to allow the gateway device (2CAN or Black JAG) to perform all of the CAN "hand shaking" and have the application simply make requests for position, speed or current... The reason for the current implementation is to allow teams to create their own CAN gateways without having knowledge of the Tokenization protocol used by the Jags.

That's not quite true. On things like Set(), there is a message then an ACK, but on things like GetCurrent(), there is no ack, just the data. And only the sending portion of the message is blocking, the received messages can arrive out of order and do not block other receiving messages.

The current system also doesn't send entire CAN messages over the (Black Jag) bridge device. Only the minimal data is sent (MessageID, size, extra data) over the serial connection, the rest is filled in by the CAN driver on the jag. The only "Hand Shaking" that the cRIO sees is ACK replys from send messages (like Set()), and the data from requesting messages acts as the ACK. The cRIO never sends ACKs to the jaguars. The only thing that could potentially be removed from communications in the ACK from the jaguar, which would mean no error messages could be seen about a lost jaguar unless a requesting message was sent.

[Mike Copioli]

The only thing that could potentially be removed from communications in the ACK from the jaguar, which would mean no error messages could be seen about a lost jaguar unless a requesting message was sent.

Removing the ACK would not be advisable and would further abstract the current implementation from the correct CAN implementation. All of the CAN transactions should be handled by the CAN nodes independently of the cRIO application. For example:

lets say we want to send set throttle to 8 Jags.

Current implementation

-set jag 1
-crio waits for ack
-set jag 2
-crio waits for ack
-set jag 3
-crio waits for ack
-set jag 4
-crio waits for ack

.......

All of this takes place over serial or Ethernet. Lets say each set command takes about 1 mS. Setting 8 Jags would take 8 mS.


Better approach:

Application sets all 8 throttles via gateway. Gateway sets Jag 1, Jag 2, Jag 3while application continues performing other tasks, ACKs are received by Gateway in or out of order. Time to set all 8 Jags less than 1 mS. The whole thing could be handled by one process CAN call. In this same approach requests could be made for current, position, and velocity. Application makes requests for Current, Position and Velocity from all 8 speed controllers. CAN gateway handles requests while application continues. No ack is needed for these types of requests because the response from the Jag is confirmation that the request was received. As you stated this is similar to how requests are made now. What really needs to change is the set throttle interface. The current configuration is more comparable to master slave rather than a true CAN bus where all nodes have the ability to communicate with each other.

[Radical Pi]

Ahh, that makes more sense now. So Set messages become Asynchronous and don't wait for the ack. Honestly, I don't see too much of a problem in the speed of the current implementation. The only troubles come from when a jag is lost and it waits 50 ms before timeout, which eventually slows down code enough to hit watchdogs. This solution does fix that though, and I can't really see any downsides to it.

Request messages would still be blocking, right? Having some sort of asynchronous request system would be IMO an annoyance for programming and would just confuse people trying to use CAN in their code.

[kamocat]

One way to do it might be to schedule periodic status updates, so that the "get" VIs just get the last data that was acquired by the bridge. You could have an option on every function: request new data or retrieve current data. That way you could avoid the awkwardness of sending a message in one place and retrieving data in another.
It's true that error messages would have to be put somewhere else, but they should be anyways, shouldn't they? The errors are to tell you that something isn't working with that Jaguar, not to slow down your code or prevent things from executing. With the current implementation, the errors show up on your driver station, but all they do in code is keep data from being sent to that controller. Say one of the motor controllers for you drivetrain isn't working. You don't just drive normally like it isn't happening; you try to counteract the issue of your robot skewing to one side. With PWM, unfortunately, the robot controller can't detect that the motor isn't running how it should (other than "hey, that wheel isn't moving"). With CAN, the problem is very apparent, and the robot controller is very capable of dealing with that if you have two motors per side. (make the fully functional side go slower)
More centralized error handling would help this, because you could look up the controller in a registry and see what its current state was, and deal with it accordingly. (This is what my CAN Manager attempted to do, but it had very poor performance due to the current implementation of CAN)

[Mike Copioli]

Request messages would still be blocking, right? Having some sort of asynchronous request system would be IMO an annoyance for programming and would just confuse people trying to use CAN in their code.

Requests do not have to be blocking. The gateway device could simply dump the result of the request, say current from JAG 1, 2, 3, 4... into a buffer over TCP/IP/UDP or serial. A buffer would have to exist on the application side that holds the data. A ring buffer(fifo) would work fine for this task. Basically the application requests current from the Jags, then proceeds to the next task, when the data is available a flag is set notifying the application that new data is available. The application then pops the data from the FIFO. This is probably not even necessary though. The blocking time would not be very long for even a dozen requests, sub mS. The whole process could be run on it's own thread anyway. The point is to let the CAN BUSS do all the dirty work.

Imagine this scenario:

-CAN GYRO
-CAN ADC
-CAN QUAD ENCODER
-CAN SPEED CONTROLLER

-CAN gyro node performs all of the integration math for calculating angular position.

-CAN ADC performs all of the ADC sampling and averaging and could provide position, velocity or raw analog value.

-CAN quad encoder node decodes all quadrature encoder data and provides position and velocity.

The CAN nodes will now have the functionality of sending traffic to and from each other instead of back and forth to/from the application. I want to servo speed controller 1 to the position returned by the ADC or Quadrature module. You get the idea.

[Mike Copioli]

Request messages would still be blocking, right? Having some sort of asynchronous request system would be IMO an annoyance for programming and would just confuse people trying to use CAN in their code.

Requests do not have to be blocking. The gateway device could simply dump the result of the request, say current from JAG 1, 2, 3, 4... into a buffer over TCP/IP/UDP or serial. A buffer would have to exist on the application side that holds the data. A ring buffer(fifo) would work fine for this task. Basically the application requests current from the Jags, then proceeds to the next task, when the data is available a flag is set notifying the application that new data is available. The application then pops the data from the FIFO. This is probably not even necessary though. The blocking time would not be very long for even a dozen requests, sub mS. The whole process could be run on it's own thread anyway. The point is to let the CAN BUSS do all the dirty work.

Imagine this scenario:

-CAN GYRO
-CAN ADC
-CAN QUAD ENCODER
-CAN SPEED CONTROLLER

-CAN gyro node performs all of the integration math for calculating angular position.

-CAN ADC performs all of the ADC sampling and averaging and could provide position, velocity or raw analog value.

-CAN quad encoder node decodes all quadrature encoder data and provides position and velocity.

The CAN nodes will now have the functionality of sending traffic to and from each other instead of back and forth to/from the application. I want to servo speed controller 1 to the position returned by the ADC or Quadrature module. You get the idea.

[kamocat]

It's an interesting concept, making each node partially reprogrammable for interaction between CAN devices.

[taichichuan]

When is the CANipede slated to be available? This is the one that's based on an Arduino? Any estimated cost?

TIA,

Mike

[Mike Copioli]

The CANipede is not based on the Arduino. An Arduino may be used to communicate with the CANipede via the CAN shield. The Arduino by itself is not powerful enough for this kind of control system. It also lacks the necessary hardware to operate in a harsh electrical environment like a robot. (over current protection, ESD protection, ...). However if one wishes to use the Arduino as a Logic Node to provide high level instructions over CAN, they may. One does not need intimate knowledge of CAN in order to leverage the control systems features. The point of the control system is to allow any processing platform to be used via a simple, standard interface. The CANipede will be available this Fall around October. Target price is about $199.99.

[B.Johnston]

The Canipede is here!!!

http://crosstheroadelectronics.com/RCM.html

[Abrakadabra]

The Canipede is here!!!

http://crosstheroadelectronics.com/RCM.html

Any word on actual availability date? Price? I would love to be able to build a CAN practice bot with one of these before the season starts.

I assume the CANipede will be available separately, for those of us who already have the 2CAN, correct?

[taichichuan]

Any word on whether the CANipede will be approved for use on FRC robots? I know the sensors can be used. But, what about the control features?

TIA,

Mike

[Alan Anderson]

Any word on whether the CANipede will be approved for use on FRC robots? I know the sensors can be used. But, what about the control features?

I would be very surprised if any non-Kit-of-Parts components were permitted to control robot actuators.

[taichichuan]

I would be very surprised if any non-Kit-of-Parts components were permitted to control robot actuators.

But, wasn't the 2CAN approved last year? As a gateway between Ethernet and the CAN, wasn't it in the control path? I guess it depends on how you define "control"?

Mike

[Mike Copioli]

But, wasn't the 2CAN approved last year? As a gateway between Ethernet and the CAN, wasn't it in the control path? I guess it depends on how you define "control"?

Mike

The 2CAN was not specifically allowed last year. The rules allowed any team to make a device that provides a gateway between the cRIO and CAN using either the serial port or Ethernet port #2 of the cRIO. The tokenization algorithm between the Jaguars and the cRIO prevents anyone other than the cRIO from setting any throttles.

On another note the new web-site is up and running. Please take a look and provide feedback. Both positive and constructive feedback is welcome. New firmware has been posted for both the CANipede and the 2CAN. Also take at the Cross-link Control System. All of the above are available for purchase. The open source RCS(robot control software) files will be posted soon. The RCS installer is available now and is a free download.