Message transfer between bbb and arduino


#1

Last week my friend gave me an OpenROV v2.8 as a present.I wanted to add a new function that typing a command line on the cockpit and robot would move automatically.But I don’t understand how the message transfer between browser and BBB.I also confuse that how message transfer between bbb and arduino.anyone could help?

forgive my bad English


#2

@badevguru sorry to bother you. could you give me some idea :cry:


#3

If you look in the Master repo we have a serial plugin that allows you to type commands that get sent to the Arduino. Tracing it should show the flow. Generally the commands are sent from cockpit to the bbb via socket.io. When the bbb gets the message, it re-emits the message to the rov using an eventemitter that the hardware.js class is listening to. That hardware.js class then serializes the message and delivers it over the serial port.


#4

I also come up with this problem. very useful !


#5

My lack of JS knowledge prevents me from further understanding the process of transfer.could you give me a example? Lights ,or Motor.


#6

@Trinh @Golden

I’ve put together this chart that roughly documents the flow of commands from the browser to the Arduino. I left the commands generic, but this should show you where to look and how plugins in the browser ultimately get commands to the arduino. The flow is typically:

Browser plugin (HTML+JS, pluginName/public/pluginName.js) -> Server Plugin (plugin/index.js) -> Lib/OpenROVController -> Lib/Hardware -> Arduino -> Device


#7

I’ve also put together a chart for my current proposal for a new architecture that simplifies the pipeline and creates an explicit API for the MCU defined at the MCU interface daemon. It should also improve system performance, reduce latency, and create a direct interface for programs running on the CPU written in any language. Open to feedback and suggestions! (Current diagram included for side-by-side comparison)


#8

I like your proposed architecture Charles, and I think such a change would greatly facilitate development & hacking of other software atop OpenROV hardware, while cleaning up messaging in general. Such a change would also allow cockpit.js being shutdown (greatly freeing up CPU, potentially for other exciting things), while maintaining controllability of the vehicle.

Somewhat related: regardless of what architecture y’all converge on, I hope it would maintain the ability at the ZeroMQ level to command the individual motors (e.g. currently possible via deps.rov.send('port(x)') ). I don’t see any reason why this would change, but wanted to throw it out there as I think cockpit sends thrust/yaw msgs, with thruster allocation math done on the MCU.


#9

Hi,charlesdc, this flow chart really helped to understand the process better.but i came up with another question.
this function in NcommanManager.cpp get current command from BBB but literally the arduino may process the string and send it to the coressponding modeul of the ROV. I am now confused about this process. For example, how the NCommManger “knows” that it should sent the command string to the CThruster2x1 but not the Clight if the command does for the motor.(somehow like an identification check).I don’t know wheather my undrstanding is proper.
Thanks a lot.


#10

@Golden

Sorry, that is likely because of how I drew the arduino side of the chart. As you have found, that function in the comm manager basically parses in a command from the serial line (or attempts to) on each update loop. Once it has a complete message, it switches that commandAvailable flag to true. The comm manager is available to all other modules in the code, so after the comm manager finishes it’s update loop, the update loops for all of the CModule-derived classes get called and if they are listening for messages, they will check to see if a message was available and, if so, whether or not the command name matches one they are interested in. The comm manager never sends the thruster messages, but rather it serves as a shared mailbox that all of the modules can check during one update loop cycle. It’s a bit inefficient as each module is doing a string comparison to see if the message is for them, and also the comm manager is spending a lot of time trying to parse strings as well, but that is what I hope to address with using a binary serialization like mavlink. With mavlink, parsing will become more of a “check the message type ID and destructure into a c struct” process, so everything should become integer comparisons as opposed to full string comparisons. This also should buy back cpu cycles on the BBB.

Also, the reasons for why we use the shared mailbox approach are that the mcu is generally running fast enough to only have one complete command buffered at any time, so we can just process it and be done with it, and there is limited SRAM available on these mcus, so we have to be careful how much memory we allocate to making copies of messages. In our case, there is no need to send copies of messages to each module that is interested when we can just signal them to look at the one we parsed exactly where it resides in memory.


#11

Thanks for such a detail reply. As for the updateloop you have mentioned, is it done by this part in the MoudelManager ?


if it is then the whole route makes sense to me now.
For the array m_pModules[i], I am now having troubles in understanding the correspondence between the elements and the modeuls. i did find a part that seems like doing the resitration but i am not sure about how it works. For example, if i want to register the Clight Modeul as m_pModeuls[0], what measure shall i take.

I am going to make the OpenRov autonomous and this part may be a key part for me,
Many thanks
Golden


#12

the problem has been solved. ignore my last reply
thanks so much


#13

helpful diagram and enlighten me. :grinning:
I still confuse that how the message send to BBB from browse.For example,I push “up” and the robot would go straight. But I don’t know architecture and work flow. could you give me some idea:cry: