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]

Originally Posted by 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

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]

Originally Posted by kamocat

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]

Originally Posted by Mark McLeod

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]

Originally Posted by 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?).

No, it is one device.

Originally Posted by kamocat

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.

Originally Posted by kamocat

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?

Originally Posted by kamocat

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]

Originally Posted by Mike Copioli

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]

Originally Posted by Radical Pi

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)