You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This might not be the good place to post, but I haven't found any other suitable forum/maillist.
I've been playing with ros_arduino_bridge a little bit and I've found it useful.
Though I'd like to share a few ideas which might improve it, they mainly consider the project
on functional/logical structure but don't specify the implementation.
I like the way you can configure sensors as ANALOG/DIGITAL. But for other components (motors/servos) you prefer to have it's own 'driver' uploaded to the arduino. This is logical, as sending PWM/PPM signals over a serial connection might be overkill if you can avoid it. But I don't like the fact that for each component, you need it's 'driver' uploaded on arduino alongside the ROSArduinoBridge and specify separate commands (in commands.h) if you wish to use it.
It could be a good idea to link pins to signal types instead of components.
Examples of signal types could be PWM, PPM, AC, DIGITAL(slow changing digital signal),
ANALOG, ADC (Analog signal converted to digital on arduino).
The methods to process each signal type are also uploaded to the arduino.
The signal processing on the arduino depends only on the signal type.
There is shared configuration file for ros_arduino_python (used for creating ros node) and ROSArduinoBridge (upload code depending on config),
there are currently already 2 configuration sites (arduino_params and the #DEFINE statements in ROSArduinoBridge), configuring each pin to own it's own signal type could allow to unite these.
commands.h goes away. Instead there are fixed commands which are related to function which influence the characteristics of each signal type,
thus: instead of " m (motor speed) 9(on pin 9) ", you define that a pin typed by a PWM signal has certain functions which relate to it's characteristics (period, frequency, duty cycle). Having a more generic code uploaded to the arduino would mean that you'd have to implement the PID control in ROS.
The ROSArduinoBridge uploaded to arduino contains a few generic methods unrelated to signal types. One of these methods is configurePin(pin, type), which would allow the signal on the pin to be processed on a different way.
The end result would be a more generic code uploaded to the arduino, which only has to be uploaded once and can be dynamically configured. This would be a bit of a mix between ros_arduino_bridge and rosserial.
This is merely a concept and I have no idea on how realizable this concept is. The backbone of it thus consists of linking pins to signal types (with generic libraries) instead of components (with specific 'drivers'/libraries).
Any thoughts would be appreciated.
If you know a better place to post this message, let me know.
kind regards,
Dieter
The text was updated successfully, but these errors were encountered:
Thanks for your suggestions. I don't have the experience to program at the signal level on the Arduino but you are more than welcome to fork a branch of the code and have at it. As for discussing the idea further, you might try the Trossen Robotics forums over at http://forums.trossenrobotics.com/forum.php as I think there is a fair bit of cross-talk between Arduino and ROS users over there. The other place might be the HBRC Google Group (https://groups.google.com/forum/?fromgroups#!forum/hbrobotics) where we have a ton of people who are real experts on using the Arduino.
pryme
pushed a commit
to pryme/ros_arduino_bridge
that referenced
this issue
Aug 5, 2016
Hello,
This might not be the good place to post, but I haven't found any other suitable forum/maillist.
I've been playing with ros_arduino_bridge a little bit and I've found it useful.
Though I'd like to share a few ideas which might improve it, they mainly consider the project
on functional/logical structure but don't specify the implementation.
I like the way you can configure sensors as ANALOG/DIGITAL. But for other components (motors/servos) you prefer to have it's own 'driver' uploaded to the arduino. This is logical, as sending PWM/PPM signals over a serial connection might be overkill if you can avoid it. But I don't like the fact that for each component, you need it's 'driver' uploaded on arduino alongside the ROSArduinoBridge and specify separate commands (in commands.h) if you wish to use it.
It could be a good idea to link pins to signal types instead of components.
Examples of signal types could be PWM, PPM, AC, DIGITAL(slow changing digital signal),
ANALOG, ADC (Analog signal converted to digital on arduino).
there are currently already 2 configuration sites (arduino_params and the #DEFINE statements in ROSArduinoBridge), configuring each pin to own it's own signal type could allow to unite these.
thus: instead of " m (motor speed) 9(on pin 9) ", you define that a pin typed by a PWM signal has certain functions which relate to it's characteristics (period, frequency, duty cycle). Having a more generic code uploaded to the arduino would mean that you'd have to implement the PID control in ROS.
The end result would be a more generic code uploaded to the arduino, which only has to be uploaded once and can be dynamically configured. This would be a bit of a mix between ros_arduino_bridge and rosserial.
This is merely a concept and I have no idea on how realizable this concept is. The backbone of it thus consists of linking pins to signal types (with generic libraries) instead of components (with specific 'drivers'/libraries).
Any thoughts would be appreciated.
If you know a better place to post this message, let me know.
kind regards,
Dieter
The text was updated successfully, but these errors were encountered: