justincinmd / ruby-ev3 Goto Github PK

Hi @jcnnghm,

I came across your ruby-ev3 repository today, and am interested in helping out. I've been able to fire up the console, connect to a brick via bluetooth, and do the basics (beep & spin a motor). I'd love to help move this forward if you're interested.

I'm also interested in seeing if I can get his working with another project I work on ruboto (JRuby on Android):

https://github.com/ruboto/ruboto

Thanks,
Scott

I'm working on expanding on the initial input (button pressed) to cover more inputs (e.g., ports). In doing this, I rethinking the 1 command per class route for a few reasons: 1) there is a lot of overhead (in lines of code needed to maintain the module/class structure and to override methods); 2) we're going to need a large number of commands to cover all of the functionality; and 3) batching of commands will be common (e.g., read all of the button states at once) requiring more classes to cover those options.

I'm thinking that we could get away with:

1. One class to handle each call (e.g., Command or Message). It would get set up to be either System or Direct, with or without a reply. It would be responsible for constructing the header and possibly handling the response. It would manage one or more sub commands (getting the bytes to send and assigning the appropriate parts of any response).

2. A subcommand class or hierarchy of classes. Each sub command needs:

• A subcommand type
• Some parameters (data type followed by data)
• Information for creating space for reply data (one or more type) so it can create indices for the replies and process them

I don't think we'll need one class per subcommand. It seems like it might be enough to pair up physical object with a class used for getting and setting its information (motor, port, button, ui), and perhaps some extra classes for more batch commands (reading all the ports at once, or starting two motors at the same time).

I think the subcommand should be responsible for querying the necessary information from the object (e.g., port id, layer, mode) and then assigning information returned (raw_value = X).

3. The "Model" object in this case would be responsible for creating the command, holding values, and firing of any procedures based on changes detected.

Thoughts?

I checked some code into a motors branch in my fork. It implements most of the output commands. In doing this I have a few thoughts:

1. We need a Motor object that can manage two motors at once. Most of the output commands can support this, and the sync calls require it. We can get this easily by adding a constant (AD = A | D) and calling brick.motor_ad, but we do get some problems from interacting with the two motors (go forward) and then interacting with a single motor (reverse). The problem is that initializing the single motor automatically sends it stop.

2. The need to set the speed before calling start (or the motor gets into a weird state) is problematic. Maybe we can check the speed (using motor.read) before setting the speed to zero. If it's already running, there is no need to initialize it.

3. It might make sense to have a motor subclass for controlling more than one motor (or a base and two subclasses). There are only a few methods that can only be called in one or the other, so it might be ok to just throw an error if a method is called at the wrong time.

4. Keeping state information in the Motor object (e.g., the speed) is problematic. Once we have the other methods, there are too many ways to start the motor that will invalidate the state information (e.g., power=). I think we need to ditch this state information and use motor.read to retrieve the speed if it is needed.

Wifi is now up to date (i.e., can perform_read).

I can try USB now. After further investigation, I agree that hidapi is the way to go. You mentioned that you had some code you started on that you could share. I also came across a 3-year-old repository:

https://github.com/ozone1015/ruby-hidapi

I've pushed some code a new branch in my repository to add support for Ports. This builds off of the rethinking_commands branch (for ease of expanding). The main purpose is to get device types, modes, and values (based on mode). The ports are :one, :two, :three, :four, and (to handle input from motors) :a, :b, :c, and :d. I also created a method on Brick to report the devices attached. This now handles input in the form of strings and arrays of bytes (to support several of the input calls).

The next step would be to begin to set up callbacks based on port changes (device and values).