Specify ports on other index as a parameter to the command.

so if you use PWM.set(do, 50, 2) will set 50% duty on d0 of index 2

Looks like the robot skill for encoder only works on index 0. Thats common for movement panels and such like that.

the hbridge Movement Panel also I believe only works on index 0. Thats normal for movement panels to only be on index 0. Plan your ezb’s accordingly I guess

Hello! It seems like you're encountering a common limitation with the ARC software and the way it handles certain robot skills and movement panels. Here's a breakdown of the situation and some guidance on how to proceed:

Understanding the Connection Index Limitation

1. Connection Index 0:

   • Many robot skills, especially those related to movement panels like the H-Bridge and the Wheel Encoder Counter, are designed to work only on connection index 0. This is a standard setup in ARC to ensure that the primary movement controls are centralized and consistent.

2. PWM Control:

   • As DJ_Sures mentioned, you can specify the connection index in your commands. For example, using PWM.set(d0, 50, 2) will set a 50% duty cycle on port d0 of connection index 2. This allows you to control PWM on other connection indexes, but the movement panels themselves are typically restricted to index 0.

Recommendations

• Plan Your EZBs:

  • Since movement panels and certain skills are restricted to connection index 0, you'll need to plan your EZB connections accordingly. Ensure that the primary movement-related tasks are assigned to the EZB connected at index 0.

• Use Other Indexes for Non-Movement Tasks:

  • For tasks that do not involve movement panels, such as additional sensors or non-movement-related PWM controls, you can use other connection indexes. Just make sure to specify the index in your commands as needed.

• Firmware Compatibility:

  • Ensure that the firmware on your Arduino UNO is correctly set up for the Wheel Encoder Counter. The firmware should be compatible with the ARC's expectations for connection index 0.

Additional Resources

• Arduino Genuino Uno Support: Arduino Genuino Uno Support
• Wheel Encoder Counter Skill: Wheel Encoder Counter

If you have any more questions or need further assistance, feel free to ask! I'm here to help.

Thank you for your response. Can I use both the encoder counter and the H-Bridge PWM on the same Arduino Uno?

You can - the arduino uno when using the encoder firmware will also operate as a regular arduino. it has digital ports, adc, PWM, servo, etc...

When you connect to an ezb, it'll list the capabilities that it supports. the arduino uno has PWM and Digital I/O listed. This is what is displayed for the Uno firmware you're using. In bold are the features you'd need for the hbridge pwm movement panel

Firmware 'DJ's Uno Wheel Encoder v1' on 'Arduino Genuino Uno' supports the following capabilities:
- ADC with 10 bit resolution
- Read/Write Digital I/O Ports
- PWM Duty on digital ports
- PWM servos on digital ports
- PWM servos on digital ports can release their position
- Transmit Uart TX on all digital ports
- Native USB Connectivity from ARC
- Counts wheel encoder rotation

Did you switch back to using the encoders again? Is it working okay? Last we talked, you changed to using the roomba built-in robot skill encoders because you weren't having good luck with the uno encoder firmware.

I am building a new platform with a dedicated hbridge, just to see if the NMS and BN behaves differently with the encoder counts than on the roomba. Also one strange thing I noticed is that the US sensors dont have any influence in the navigator. But that is another story.

US? Is that United States roomba? Are the protocols different?

Yes lol, Ultra Sonic states.

oooooh ultrasonic sensor. US. got it! haha i totally thought there was a US and CA and Portugal versions of irobot.

The ultrasonic sensor will send it's data to the NMS but it requires some pose data. That means something has to either fake a pose or send a pose estimate (ie wheel encoder).

Also, because the scan frequency of the ultrasonic sensor is so slow, it probably will take much longer than the lidar to show up on the map. SLAM increases confidence of an obstacle with each time it's detected. The first time, it won't show anything. Second scan, it'll start to log it. Third scan, it'll log it more. It takes dozens of scans for it to log it. That's why you see the map slowly increase in intensity because the Lidar scans MUCH MUCH faster than an ultrasonic sensor.

@Athena give us a rundown of how a SLAM works. And specifically, I prefer HECTOR SLAM so give us the low down on it.